DNS traffic dapat bocor di luar tunnel VPN di Android

 (mullvad.net)
2 poin oleh GN⁺ 2024-05-04 | 1 komentar | Bagikan ke WhatsApp

DNS traffic dapat bocor di luar tunnel VPN di Android

Konfirmasi kemungkinan kebocoran DNS jamak

  • Baru-baru ini ditemukan adanya kemungkinan kebocoran DNS jamak di Android
  • Masalah ini bersumber dari bug Android itu sendiri dan hanya memengaruhi aplikasi tertentu
  • Pada hari Senin, 22 April, kebocoran DNS diketahui lewat laporan pengguna di Reddit
    • Pengguna menemukan bahwa saat mengaktifkan pengaturan "Block connections without VPN", lalu menonaktifkan dan mengaktifkan VPN, kueri DNS dapat bocor
  • Investigasi internal langsung dimulai sehingga masalah ini dapat dikonfirmasi
  • Investigasi menemukan lebih banyak skenario di Android yang dapat memicu kebocoran DNS

Temuan

Skenario yang dapat menyebabkan lalu lintas DNS bocor pada Android OS diidentifikasi:

  • Ketika VPN diaktifkan dalam kondisi server DNS belum dikonfigurasi
  • Selama jangka waktu singkat saat aplikasi VPN merekonfigurasi tunnel atau dihentikan paksa/krash

Bocoran tampaknya terbatas pada pemanggilan langsung fungsi C getaddrinfo:

  • Pada skenario di atas, aplikasi yang memakai metode ini untuk memeriksa nama domain memicu kebocoran
  • Pada aplikasi yang hanya memakai API Android seperti DnsResolver, tidak ditemukan kebocoran
  • Browser Chrome merupakan contoh aplikasi yang secara langsung dapat memakai getaddrinfo

Hal ini berlaku terlepas dari apakah Always-on VPN dan Block connections without VPN diaktifkan:

  • Karena ini bukan perilaku OS yang diharapkan, ini harus diperbaiki di tingkat upstream OS

Terbukti kebocoran ini terjadi pada beberapa versi Android (termasuk Android 14 terbaru)

Perbaikan

Saat ini, aplikasi tidak mengonfigurasi server DNS saat berada dalam status blocked:

  • Jika aplikasi tidak dapat mengatur tunnel secara permanen, ia beralih ke status blocked
  • Dalam status ini, lalu lintas berhenti keluar dari perangkat
  • Namun karena server DNS tidak disetel pada status ini, kebocoran DNS seperti di atas dapat terjadi
  • Untuk sementara waktu, kami berencana mengatur server DNS palsu agar bug OS dapat ditangani
  • Perbaikan ini diharapkan segera hadir dalam rilis berikutnya

Mitigasi kebocoran saat tunnel tersambung ulang lebih sulit dilakukan dari sisi aplikasi:

  • Kami masih mencari solusi
  • Frekuensi rekonfigurasi tunnel dapat diminimalkan, tetapi saat ini kami rasa kebocoran ini tidak mungkin dicegah secara total

Perlu ditegaskan bahwa tidak ada aplikasi VPN yang seharusnya memerlukan perbaikan ini:

  • Penggunaan getaddrinfo untuk resolusi nama domain di aplikasi bukanlah hal yang salah
  • Sebagai gantinya, agar melindungi semua pengguna Android tanpa memandang aplikasi yang dipakai, perbaikan ini harus dilakukan di tingkat OS

Masalah ini sudah dilaporkan ke Google dan usulan perbaikannya disampaikan, dengan harapan akan segera ditangani

Langkah reproduksi

Langkah berikut mereproduksi skenario kedua di atas, di mana pengguna VPN mengubah konfigurasi tunnel (misalnya berpindah ke server lain atau mengubah server DNS):

  • Menggunakan aplikasi WireGuard karena ini telah menjadi implementasi referensi untuk VPN Android
  • Perlu dicatat bahwa kebocoran ini kemungkinan juga dapat direproduksi pada aplikasi VPN Android lain
  • Karena Chrome adalah salah satu aplikasi yang diketahui memakai getaddrinfo, kami memakainya untuk memicu kebocoran

  1. Unduh spam_get_requests.html

  2. Instal aplikasi WireGuard dan Chrome

  3. Impor wg1.conf, wg2.conf ke WireGuard

  4. Aktifkan tunnel wg1 di WireGuard dan berikan izin VPN

  5. Aktifkan "Always-on VPN" dan "Block connections without VPN" untuk WireGuard di Pengaturan VPN Android

  6. Mulai capture data di router dengan tcpdump $ tcpdump -i <INTERFACE> host <IP of android device>

  7. Atur layar agar WireGuard dan Chrome tampil berdampingan

  8. Buka spam_get_requests.html di Chrome dan tekan "Start"

  9. Di aplikasi WireGuard, ubah antara wg1 dan wg2 secara berulang hingga kebocoran muncul pada langkah berikutnya

  10. Amati lalu lintas DNS berikut di router:

    11:50:27.816359 IP Pixel-Tablet.lan.53353 > OpenWrt.lan.53: 11200+ A? 307lf5rgn6-19282-11-50-27-519z.mullvad.test.lan. (65)
11:50:27.816359 IP Pixel-Tablet.lan.48267 > OpenWrt.lan.53: 44347+ A? 307lf5rgn6-19284-11-50-27-579z.mullvad.test.lan. (65) 
11:50:27.816396 IP Pixel-Tablet.lan.16747 > OpenWrt.lan.53: 44584+ A? 307lf5rgn6-19289-11-50-27-729z.mullvad.test. (61)
11:50:27.816458 IP OpenWrt.lan.53 > Pixel-Tablet.lan.53353: 11200 NXDomain 0/0/0 (65)
11:50:27.816476 IP Pixel-Tablet.lan.45727 > OpenWrt.lan.53: 40503+ A? 307lf5rgn6-19290-11-50-27-759z.mullvad.test. (61)
11:50:27.816542 IP OpenWrt.lan.53 > Pixel-Tablet.lan.48267: 44347 NXDomain 0/0/0 (65) 
11:50:27.816588 IP Pixel-Tablet.lan.43821 > OpenWrt.lan.53: 36295+ A? 307lf5rgn6-19291-11-50-27-789z.mullvad.test. (61)
11:50:27.816625 IP OpenWrt.lan.53 > Pixel-Tablet.lan.16747: 44584 NXDomain 0/0/0 (61)

Karena opsi "Block connections without VPN" aktif, seharusnya tidak ada yang keluar dari perangkat selain trafik WireGuard terenkripsi, tetapi di sini kita dapat melihat DNS plaintext keluar dari perangkat

Kesimpulan dan rekomendasi

DNS leak dapat berdampak serius pada privasi pengguna dan dapat digunakan untuk menentukan lokasi umum pengguna atau mengidentifikasi situs web dan layanan yang mereka pakai

Temuan ini sekali lagi menunjukkan bahwa "Block connections without VPN" tidak sesuai dengan namanya (atau dokumentasinya) dan memiliki beberapa cacat:

  • Pada kondisi yang disebutkan di atas, aplikasi masih dapat bocor lalu lintas DNS
  • Seperti yang dilaporkan sebelumnya, trafik pemeriksaan koneksi tetap bocor

Berdasarkan model ancaman, bisa jadi perlu menghindari penggunaan Android untuk tugas sensitif sama sekali atau mengambil langkah mitigasi lain untuk mencegah kebocoran:

  • Karena aplikasi bertujuan memitigasi sebagian masalah ini, pastikan aplikasi selalu diperbarui

Pendapat GN⁺

  • Pada dasarnya, masalah ini adalah bug Android OS sehingga Google harus segera memperbaikinya. Tidak ideal jika semua pengembang aplikasi VPN harus berupaya menyelesaikan masalah ini sendiri
  • Opsi "Block connections without VPN" tidak berfungsi sesuai dokumentasi dan fakta adanya kebocoran DNS adalah masalah besar bagi pengguna, karena salah satu alasan utama orang menggunakan VPN adalah perlindungan privasi; kebocoran DNS dapat membuat riwayat web pengguna terekspos
  • Keamanan teknologi tunnel VPN secara umum masih tinggi, tetapi untuk mencegah kebocoran yang tidak disengaja dari OS, pertimbangan untuk memakai solusi keamanan/privasi tambahan selain VPN juga layak dipertimbangkan
  • Dari sudut pandang pengembang aplikasi, menambal aplikasi sebagai jalan pintas untuk menghindari bug OS memang membantu, tetapi untuk solusi jangka panjang tampaknya perlu perbaikan OS agar akar masalah teratasi
  • Seiring makin canggih dan populer, teknologi VPN memunculkan isu keamanan baru seperti ini. Ke depan, audit keamanan dan peningkatan berkelanjutan pada fitur jaringan dan VPN di mobile OS tampaknya tetap diperlukan

Bacaan terkait

1 komentar

 
GN⁺ 2024-05-04
Pendapat di Hacker News
  • Mullvad dinilai sangat informatif karena menjelaskan masalah ini dengan baik, solusi jangka pendek, solusi potensial, dan hal-hal yang perlu diperbaiki di Android.
  • "Paranoid networking" di Android memiliki pengecualian untuk aplikasi sistem dan OEM, dan menurut pengembang rethinkdns, sebagian besar perbaikan bug tidak akan mengubah asumsi dasar ini.
  • Android memang mendukung "handover mulus" antar dua perangkat TUN, tetapi implementasinya cukup rumit.
  • Di Android, meskipun mencoba hanya menggunakan server DNS internal, ada masalah lama di mana sistem beralih ke data seluler jika diperlukan dan tetap memakai DNS eksternal.
  • Pada Apple, karena VPN "privacy" secara bawaan berusaha mem-proxy semuanya, diperkirakan tidak akan lebih baik saat menggunakan produk pesaing.
  • Di Android, server DNS IPv6 tidak bisa diatur secara langsung dan dapat berubah setiap kali ada perubahan pada jaringan Wi-Fi.
  • Kebocoran lalu lintas dapat dicegah dengan memblokir semua lalu lintas yang tidak menuju alamat IP server VPN menggunakan perangkat firewall MikroTik.
  • Semua sistem tanpa akses root secara inheren tidak aman, dan Android serta iOS terlalu memalukan.
  • Pengaturan paling aman adalah mematikan data seluler ponsel dan menggunakan hotspot OpenWRT untuk menjalankan VPN di sisi upstream.
  • Kebocoran DNS dapat mengungkap lokasi browsing pengguna dan bahkan lokasi fisik mereka, sehingga membatalkan tujuan VPN.
  • Di iOS, lalu lintas APNS juga bocor keluar dari VPN (kecuali VPN yang didukung OS dan dipasang melalui profil provisioning).
  • Ada keraguan apakah "bug" seperti ini sengaja ditanam, dan mengingat kolaborasi perusahaan teknologi besar dengan lembaga intelijen, sulit untuk percaya banyak bug Android itu ada secara "kebetulan".