Kemungkinan kebocoran lalu lintas DNS ke luar terowongan VPN di Android

 (mullvad.net)
2 poin oleh GN⁺ 2024-05-04 | 1 komentar | Bagikan ke WhatsApp
  • Pada sebagian kombinasi aplikasi dan status di Android, kueri DNS dapat keluar dari terowongan VPN, dan Mullvad menilai penyebabnya adalah bug Android OS, bukan aplikasi VPN
  • Kebocoran dapat terjadi pada fase transisi singkat seperti saat VPN aktif tetapi server DNS kosong, konfigurasi ulang terowongan, atau aplikasi VPN dihentikan paksa/terjadi crash
  • Dampaknya terutama terkonsentrasi pada aplikasi yang memanggil getaddrinfo secara langsung, sementara kebocoran tidak ditemukan pada aplikasi yang hanya memakai API Android DnsResolver
  • Mengaktifkan Always-on VPN dan “Block connections without VPN” pun tidak sepenuhnya mencegah masalah ini, dan telah dikonfirmasi di beberapa versi termasuk Android 14
  • Mullvad sementara akan menetapkan server DNS palsu untuk meredakan sebagian situasi, tetapi kebocoran saat penyambungan ulang sulit diblokir sepenuhnya tanpa perbaikan OS

Kondisi kebocoran DNS yang terjadi di Android

  • Mullvad mengonfirmasi melalui laporan pengguna Reddit pada 22 April bahwa kebocoran DNS dapat terjadi saat VPN dimatikan lalu dinyalakan kembali dalam kondisi “Block connections without VPN” aktif
  • Dalam investigasi internal, ditemukan lebih banyak skenario ketika Android OS dapat mengirim lalu lintas DNS ke luar VPN
    • VPN aktif tetapi server DNS tidak dikonfigurasi
    • Saat aplikasi VPN mengonfigurasi ulang terowongan
    • Dalam waktu singkat ketika aplikasi VPN dihentikan paksa atau crash
  • Perilaku ini bukan perilaku yang diharapkan dari Android OS, dan harus diperbaiki di level OS yang lebih tinggi

Aplikasi yang terdampak dan jalur resolusi nama

  • Kebocoran tampaknya terjadi pada aplikasi yang secara langsung memanggil fungsi C getaddrinfo untuk resolusi nama domain
  • Kebocoran tidak ditemukan pada aplikasi yang hanya menggunakan API Android DnsResolver
  • Browser Chrome adalah contoh aplikasi yang dapat menggunakan getaddrinfo secara langsung
  • Penggunaan getaddrinfo itu sendiri bukanlah hal yang salah, dan untuk melindungi semua pengguna Android diperlukan solusi di tingkat OS

Batasan Always-on VPN dan pengaturan pemblokiran

  • Kebocoran yang telah dikonfirmasi terjadi terlepas dari apakah Always-on VPN dan “Block connections without VPN” diaktifkan atau tidak
  • Jika “Block connections without VPN” aktif, seharusnya tidak ada lalu lintas selain lalu lintas WireGuard terenkripsi yang keluar dari perangkat, tetapi dalam proses reproduksi, DNS teks biasa teramati di router
  • Mullvad menilai pengaturan ini tidak memenuhi nama maupun perilaku yang didokumentasikan, dan memiliki beberapa kelemahan
    • Dalam kondisi di atas, lalu lintas DNS dapat bocor
    • Seperti yang sebelumnya dilaporkan, lalu lintas pemeriksaan koneksi juga masih bocor

Mitigasi sementara aplikasi Mullvad dan masalah yang tersisa

  • Aplikasi Mullvad saat ini tidak menetapkan server DNS dalam status terblokir
    • Jika penyiapan terowongan gagal dengan cara yang tidak dapat dipulihkan, aplikasi masuk ke status terblokir
    • Dalam status ini, lalu lintas dicegah keluar dari perangkat, tetapi karena server DNS kosong, kondisi kebocoran dapat muncul
  • Untuk sementara, Mullvad akan merespons dengan menetapkan server DNS palsu guna mengakali bug OS, dan berencana segera menyediakan rilis yang menyertakan perbaikan ini
  • Kebocoran yang terjadi saat penyambungan ulang terowongan lebih sulit dimitigasi dari sisi aplikasi
    • Mullvad sedang mencari solusi
    • Ada kemungkinan untuk mengurangi jumlah konfigurasi ulang terowongan, tetapi untuk saat ini mereka tidak menilai kebocoran ini dapat dicegah sepenuhnya
  • Mullvad melaporkan masalah dan usulan perbaikan kepada Google

Observasi yang direproduksi dengan WireGuard dan Chrome

  • Skenario kedua, yaitu kebocoran saat perubahan konfigurasi terowongan VPN, dapat direproduksi menggunakan aplikasi WireGuard dan Chrome
    • WireGuard digunakan sebagai contoh acuan implementasi VPN Android
    • Mullvad menilai kemungkinan ini juga dapat direproduksi pada aplikasi VPN Android lain
    • Chrome digunakan sebagai pemicu kebocoran karena telah dikonfirmasi menggunakan getaddrinfo
  • Prosedur reproduksi mencakup elemen berikut
    • Mengunduh spam_get_requests.html
    • Memasang aplikasi WireGuard dan Chrome
    • Mengimpor wg1.conf, wg2.conf ke WireGuard
    • Mengaktifkan terowongan wg1 di WireGuard dan mengizinkan izin VPN
    • Mengaktifkan Always-on VPN dan “Block connections without VPN” untuk WireGuard di pengaturan VPN Android
    • Memulai capture di router dengan tcpdump -i <INTERFACE> host <IP of android device>
    • Membuka WireGuard dan Chrome dalam split screen, menjalankan spam_get_requests.html di Chrome, lalu bergantian beralih antara wg1 dan wg2 di WireGuard
  • Di router, teramati kueri record A dari perangkat Android ke port 53 router OpenWrt serta respons NXDomain
  • Kebocoran DNS dapat digunakan untuk mengetahui perkiraan lokasi pengguna atau situs web/layanan yang dikunjungi, sehingga dapat memiliki dampak privasi yang besar
  • Bergantung pada threat model, untuk penggunaan sensitif mungkin perlu menghindari Android atau menerapkan mitigasi lain untuk mencegah kebocoran
  • Pengguna aplikasi Mullvad harus menjaga aplikasi tetap terbaru karena mitigasi parsial mungkin disertakan

Bacaan terkait

1 komentar

 
GN⁺ 2024-05-04
Opini Hacker News

  • Saya tidak memakai Mullvad, tetapi jadi sangat menghormatinya. Penjelasannya tentang masalah, solusi sementara jangka pendek, solusi potensial yang bisa dipakai orang lain, hingga bagian yang perlu diperbaiki di Android sangat padat informasi dan tersusun rapi

    • Saya memilih Mullvad sebagai layanan VPN karena mereka menerbitkan artikel blog seperti ini, alih-alih melakukan sponsorship YouTube tanpa henti seperti pesaingnya
    • Meski tidak memakai VPN, Mullvad punya layanan DNS gratis. Peningkatan traffic/penggunaan juga bisa menjadi bentuk dukungan, dan dari sudut pandang permintaan DNS mungkin membantu membuat pengguna Mullvad VPN tidak terlalu mencolok
      Kekurangannya, dalam kasus saya waktu ping-nya jauh lebih tinggi daripada quad9 atau cloudflare
      Saya menuliskan cara pemblokiran iklan di tingkat DNS dan informasi terkait cloudflare di thread ini: https://news.ycombinator.com/item?id=40056162
    • Dilihat dari nilai-nilai, cara berpikir, kesetiaan pada keyakinan inti, dan bukti konsisten selama puluhan tahun mempertahankan motonya, menurut saya ini VPN terbaik
    • Sebagai pengguna Mullvad, saya sangat puas. Suatu kali saya mengirim email ke tim dukungan untuk pertanyaan terkait pembayaran, sambil menambahkan pertanyaan kecil tentang iptables untuk masalah yang sedang saya alami
      Masalah pembayaran diselesaikan dengan cepat, dan untuk iptables pun saya mendapat jawaban terperinci yang mencakup kelebihan dan kekurangan beberapa solusi. Singkatnya, luar biasa
    • Kalau memakai VPN, saya penasaran Anda memakai yang mana

  • Saya pengembang rethinkdns
    Terkait pernyataan “masalah-masalah ini harus diselesaikan di OS untuk melindungi semua pengguna Android, apa pun aplikasi yang mereka gunakan”, jaringan paranoid Android selalu memberi pengecualian untuk aplikasi sistem dan aplikasi OEM, termasuk aplikasi Google
    Kemungkinan besar sebagian besar perbaikan bug seperti ini pun tidak akan mengubah asumsi inti tersebut. Lihat kode terkait: https://github.com/celzero/rethink-app/issues/224
    Untuk bagian “kebocoran saat penyambungan ulang tunnel lebih sulit dimitigasi di aplikasi. Kami masih mencari solusi”, Android mendukung peralihan mulus antara dua perangkat TUN saat konfigurasi ulang. Sulit diimplementasikan dengan benar, tetapi memungkinkan

    • Bahkan izin internet aplikasi senter saja tidak bisa dimatikan, dan itu masuk akal kalau mengingat OS ini dijalankan oleh perusahaan iklan internet

  • Ini masalah yang sudah lama ada di Android. Meski ingin hanya menggunakan server DNS internal, Android akan beralih ke seluler dan memakai DNS itu jika merasa perlu atau menginginkannya
    Baru-baru ini saya mengamati debug adb untuk melihat mengapa/kapan koneksi nirkabel terputus, dan pada akhirnya jika Android tidak melihat atau tidak bisa menafsirkan sesuatu dalam proses pengecekan konektivitas, ia menyalakan data seluler lalu mencobanya
    Ini sangat menyebalkan saat memakai catatan DNS yang hanya ada secara internal, karena ponsel bekerja secara acak. Perangkat terhubung ke Wi-Fi yang menyediakan server DNS internal berisi catatan tersebut, tetapi karena suatu alasan Android menyelesaikannya dari luar
    Saya tidak tahu bagaimana Apple melakukannya, tetapi melihat bahwa mereka pada dasarnya mencoba mem-proxy DNS melalui DoH lewat VPN “privacy” mereka, sulit membayangkan kondisinya lebih baik saat memakai sesuatu yang bisa dianggap produk pesaing, dan kita juga tahu bagaimana Apple memperlakukan produk seperti itu

    • Perlu dicek apakah “beralih ke seluler dan memakainya saat perlu atau ingin” itu karena Wi-Fi Assist aktif. Fitur itu memang secara eksplisit dirancang untuk beralih ke seluler saat sinyal Wi-Fi buruk
    • Apple atau iOS memiliki cara bawaan yang cukup solid untuk memfilter dan memblokir traffic menggunakan configuration profile. Saya tidak yakin apakah bisa diatur per aplikasi, tetapi allowlist/blocklist nama host jelas bisa dikonfigurasi
      Contoh nyatanya bisa dilihat pada pemblokir iklan seluruh sistem ini: https://myxxdev.github.io/depictions/MYbloXXforiOS/MYbloXXfo...
    • iOS sama sekali tidak memakai Private Relay secara default. Meski termasuk dalam langganan, Anda harus menyalakannya sendiri secara eksplisit
    • Saya penasaran apakah Anda sudah mencoba mematikan “Mobile data always active” di Developer options
    • Saya pernah membangun AOSP dari source. Seharusnya itu sesuatu yang tidak punya persyaratan khusus Google, dan saya memblokir sebanyak mungkin server Google di file hosts agar tidak diam-diam terhubung ke Google
      Satu-satunya masalah yang saya alami adalah perangkat menampilkan bahwa tidak ada internet meski terhubung ke AP nirkabel yang berfungsi normal. Sebenarnya koneksinya berjalan, tetapi tampaknya untuk ikon status bar dan tujuan kode sistem internal lainnya, Android mengecek apakah internet berfungsi lewat server Google
      Kalau Anda mengutamakan privasi, sebaiknya jauhi Android, dan mungkin teknologi secara umum juga perlu diwaspadai

  • Beberapa tahun lalu saat menguji beberapa konfigurasi VPN untuk sebuah proyek, saya biasa menaruh perangkat firewall MikroTik di antara komputer dan router utama. Tujuannya hanya memblokir semua traffic yang tujuannya bukan alamat IP server VPN yang ingin dihubungi PC
    Cara ini bekerja sangat baik untuk memastikan traffic tidak bocor keluar dari jalur PC ke server VPN. Alamat IP server VPN yang digunakan hampir tidak pernah berubah, dan kalau berubah pun mudah diganti di firewall MikroTik
    Jika tidak tahu IP servernya atau IP itu berubah, ada juga cara memblokir semua traffic yang bukan pasangan port/protokol yang dipakai server VPN. Misalnya, tergantung jenis VPN, membuang traffic yang tujuannya bukan UDP 1194
    Router MikroTik juga punya alat kecil bernama torch untuk melihat traffic dengan cepat dan mudah, serta mendukung packet capture. Harganya bervariasi dari 30 dolar hingga 3000 dolar, tidak ada lisensi perangkat lunak, dan jika Anda tahu cara menggunakannya, perangkat ini sangat kuat dan mumpuni

    • Perangkat semacam ini disebut network slug, dan itu ide yang sangat bagus
      Secara ketat, slug sejati adalah firewall layer 2 transparan tanpa alamat IP yang didefinisikan, tetapi tidak perlu memperdebatkan detail itu di sini
      https://john.kozubik.com/pub/NetworkSlug/tip.html

  • Pemfilteran keluar berdasarkan alamat serta port sumber/tujuan adalah konsep dasar firewall dan konfigurasi standar di semua platform firewall-routing. Policy-based routing yang memfilter berdasarkan gateway juga berada dalam konteks yang sama: https://en.wikipedia.org/wiki/Policy-based_routing
    Umumnya, hanya produk konsumen atau semi-profesional yang secara default mengizinkan semua trafik keluar. Dalam konfigurasi ini, saya penasaran apa yang dimaksud dengan “router utama”. Apakah perangkat yang disediakan ISP?

    • Sekalian merekomendasikan, saya juga penasaran apakah ada router firewall layer 7 yang murah dan cukup bagus
      Akan menyenangkan kalau kita juga bisa menyisipkan firewall di antara aplikasi ponsel dan modem

  • Masalah DNS di Android adalah platform ini tidak memungkinkan kita menetapkan server DNS IPv6 sendiri. Setiap kali ada perubahan pada Wi-Fi, pengaturannya berubah lagi
    Bahkan di Android yang sudah di-root, tidak ada aplikasi yang bisa mencegah sistem operasi mengubahnya
    Kalau Anda memakai router yang selalu mendistribusikan alamat IPv6 dan dibuat tidak bisa dimatikan, praktis Anda akan mentok
    Saya juga tidak tahu apakah bisa memasang perangkat firewall di belakang router itu untuk menghapus server DNS IPv6 yang diiklankan router

    • Alih-alih menetapkan alamat IP server DNS, bagaimana kalau memakai dukungan DNS-over-TLS tingkat sistem? Karena itu pengaturan global, seharusnya berlaku di jaringan mana pun Anda berada dan apa pun yang terjadi di jaringan tersebut
      Kalau Anda peduli soal kebocoran permintaan DNS, bagaimanapun Anda memang harus memakai DoT atau DoH
    • Bukankah rethink bisa mengubah DNS IPv6?
    • Sepertinya maksudnya ini terjadi ketika ponsel menjadi antarmuka utama
      Saya penasaran apakah hal yang sama terjadi pada tethering Wi-Fi. Jika memakai VPN di laptop yang terhubung melalui Wi-Fi ponsel, apakah bocornya juga dengan cara yang sama?

  • Konfigurasi paling aman tampaknya adalah mematikan data seluler di ponsel dan membawa hotspot OpenWRT yang menangani VPN di hulu ponsel

    • Benar. Di iOS, ini mimpi buruk yang lebih besar
      “VPN yang selalu aktif” hanya bisa diatur pada perangkat berstatus “supervised” melalui solusi MDM dari organisasi yang disetujui Apple. Perlu pengajuan terdokumentasi dan panggilan telepon dengan karyawan saat ini
      Atau, hanya dengan memakai aplikasi Apple Configurator di Mac, Anda bisa membuat profil konfigurasi yang berisi kunci “always-on VPN”
    • Dulu saya pernah mencoba cara ini selama berbulan-bulan dengan GL.inet E750 dan iPhone tanpa SIM, tetapi operator GSM di AS sering sangat membatasi trafik UDP pada port yang tidak biasa. Kadang turun sampai 64–128 kbps, atau sekitar 0,1 Mbps
      Notifikasi juga sering tertunda
    • Jika memakai Wi-Fi publik atau jaringan seluler, itu solusi terbaik. Jika seseorang mengoperasikan BTS sendiri, ponsel bisa tersambung ke sana
      Kalau bukan jaringan saya sendiri, sebaiknya jangan tersambung langsung tanpa router seluler
    • Karena orang lain mengatakan Android diam-diam menyalakan kembali data seluler dalam berbagai kondisi, metode ini juga bukan solusi yang pasti
      The Grugq membuat alat untuk tujuan seperti ini 10 tahun lalu. Sayangnya sekarang tidak lagi dipelihara: https://github.com/grugq/portal
      Itu bagian dari presentasi keamanan operasional untuk peretas, dan layak ditonton jika Anda tertarik pada kasus beberapa peretas terkenal atau tersohor buruk yang mengira diri mereka aman tetapi akhirnya tertangkap: https://www.youtube.com/watch?v=9XaYdCdwiWU

  • Sistem tanpa akses root secara definisi tidak aman. Android dan iOS itu menggelikan

    • Bisa juga dikatakan bahwa sistem yang memiliki konsep akses root secara definisi tidak aman. Siapa pun bisa membuat pernyataan absolut seperti ini
    • Kalau saja ponsel tidak menggantikan desktop/laptop bagi sebagian besar orang, kita mungkin bisa menertawakannya saja
      Saya merasa kasihan pada anak-anak yang tumbuh, atau akan tumbuh, dengan satu-satunya komputer yang mereka miliki berupa perangkat yang terutama dirancang untuk konsumsi media dan pengumpulan data pribadi
    • Para pengembang GrapheneOS sangat menentang root. Saya penasaran apa pendapat Anda tentang itu
    • Poinnya jelas dan sesuai dengan topik. Karena itu, proyek perangkat seluler open-source, baik software maupun hardware, mau tidak mau akan terus bertambah
      https://en.wikipedia.org/wiki/PinePhone_Pro
    • Dengan definisi itu, cukup banyak sistem terpenting saya berarti “tidak aman”
      Kalau Anda bisa mengambil salinan kunci privat SSH saya dari perangkat semacam itu, saya akan memberi uang tunai 100 ribu dolar tanpa banyak tanya
      Definisi itu tidak bermakna, dan tidak berguna untuk penalaran maupun komunikasi

  • “Blokir koneksi tanpa VPN” ternyata sama tidak dapat dipercayanya seperti kemampuan saya menahan diri di prasmanan. Kalau saya tidak salah, kebocoran DNS semacam ini bisa cukup banyak mengungkap situs yang dikunjungi dan bahkan lokasi, sehingga menggagalkan tujuan VPN itu sendiri
    Android bisa membocorkan informasi DNS meski VPN aktif, jadi jika Anda benar-benar sensitif soal privasi, lebih baik berpikir melampaui penggunaan Android itu sendiri atau memindahkan aktivitas sensitif dari ponsel

  • Kadang saya curiga “bug” seperti ini bukan tidak sengaja ditempatkan dengan rapi. Apalagi mengingat perusahaan teknologi besar memang pernah bekerja sama dengan berbagai badan intelijen
    Ini juga bukan pertama kalinya saya mendengar bug semacam ini di Android, jadi saya semakin sulit percaya bahwa sebanyak ini bug masuk “tanpa sengaja”

    • “Sekali itu kebetulan, dua kali itu coincidence, tiga kali itu tindakan musuh.” —Ian Fleming, Goldfinger

  • Sejak dulu saya sudah agak curiga hal ini akan terjadi. Di Android, meski VPN aktif, MMS dan Visual Voicemail tetap berfungsi
    Keduanya kadang membutuhkan akses seluler langsung atau akan ditolak. Bisa saja hanya tersedia di jaringan seluler, atau ditolak jika permintaan tidak berasal dari dalam jaringan seluler. Saya menduga VoLTE juga sama. Jika ada VPN, fitur-fitur seperti ini bisa kacau
    Di Mobile Linux, hal ini ketahuan karena semua fitur tersebut rusak ketika VPN diaktifkan
    Tidak terlihat ada cara yang jelas untuk memperbaiki ini di Android tanpa merusak banyak fungsi yang diharapkan

    • Ironisnya, SMS/MMS dan VVS adalah sedikit dari tugas/fitur yang memang bisa dibenarkan untuk di-hardcode ke koneksi operator. Pembaruan sistem mungkin juga termasuk

Saya pernah bergulat dengan tim dukungan lanjutan AT&T soal masalah VVS di iOS dengan VPN aktif, jadi bisa dipastikan bahwa masalah ini tidak terbatas pada Android saja

  • VoLTE menggunakan dedicated bearer di stack LTE, yaitu antarmuka jaringan terpisah. Bukan antarmuka untuk data
    Bearer yang berbeda dapat memiliki prioritas/QCI yang berbeda, yakni kualitas layanan. Pada jaringan LTE yang padat, VoLTE seharusnya memberikan pengalaman yang lebih baik dibanding VOIP pada bearer berprioritas rendah