Android'de VPN tüneli dışına DNS trafiği sızıntı olasılığı

Android'de VPN tüneli dışına DNS trafiği sızabilir

DNS sızıntısı senaryolarının tespiti

• Son zamanlarda Android'de çoklu DNS sızıntısı olasılığını keşfettik
• Android'e ait bir hatadan kaynaklanıyor ve yalnızca belirli uygulamaları etkiliyor
• 22 Nisan Pazartesi, DNS sızıntısı bir Reddit kullanıcı bildirimiyle fark edildi
  • Kullanıcı, "VPN olmadan bağlantıları engelle" ayarı açıkken VPN'i kapatıp açarak DNS sorgularının sızdığını keşfetti
• İç incelemeyi hemen başlattık ve sorunun doğrulanmasını sağladık
• İnceleme, Android'de DNS sızıntısına neden olabilecek daha fazla senaryonun olduğunu gösterdi

Bulgular

Android OS'de DNS trafiğinin sızabileceği senaryoları belirledik:

• DNS sunucusu yapılandırılmamışken VPN etkinse
• VPN uygulaması tüneli yeniden yapılandırdığı veya zorla durdurulup çökertildiği sırasında kısa süreliğine

Sızıntı, C fonksiyonu getaddrinfo için doğrudan çağrı ile sınırlı görünüyor:

• Yukarıda sıralanan senaryolarda, bu yöntemi kullanarak alan adı çözümlemesi yapan uygulamalar sızıntı yapıyor
• Sadece DnsResolver gibi Android API'lerini kullanan uygulamalarda sızıntı gözlemlenmedi
• Chrome tarayıcısı, getaddrinfoyi doğrudan kullanabilen uygulamalara bir örnektir

Yukarıdaki durumlar, Always-on VPN ve Block connections without VPN etkinleştirilmiş olsun ya da olmasın geçerlidir:

• Bu, beklenen bir OS davranışı değil; işletim sisteminin upstream tarafında düzeltilmesi gerekiyor

Android 14 dâhil olmak üzere farklı Android sürümlerinde bu tür sızıntılar görüldü

İyileştirmeler

Uygulama şu anda blok durumunda DNS sunucusu ayarlamaz:

• Uygulama, geri döndürülemeyecek şekilde tünel kuramazsa blok durumuna geçer
• Bu durumda cihazdan trafik çıkışı durdurulur
• Ancak bu durumda DNS sunucusu ayarlanmadığı için yukarıda anlatılan DNS sızıntısı oluşabilir
• Geçici olarak sahte bir DNS sunucusu ayarlayarak OS hatasını çözmeyi planlıyoruz
• Bu düzeltmeyi içeren bir sürümün yakında yayınlanmasını bekliyoruz

Tünel yeniden bağlanırken sızıntıyı uygulama tarafında hafifletmek daha zordur:

• Hâlâ çözüm arıyoruz
• Tünel yeniden yapılandırmalarını en aza indirebiliriz, ancak şu an için bu sızıntıyı tamamen önleyebileceğimizi düşünmüyoruz

Hiçbir VPN uygulamasının böyle bir düzeltmeye ihtiyaç duymaması gerektiğini netleştirmek gerekir:

• Uygulamaların alan adını çözmek için getaddrinfo kullanması yanlış değildir
• Bunun yerine, hangi uygulama kullanılırsa kullanılsın tüm Android kullanıcılarını korumak için bu sorunun OS tarafında çözülmesi gerekir

Google'a sorunu bildirdik ve iyileştirme önerisinde bulunduk; hızlı bir şekilde ele alınmasını umuyoruz

Yeniden Üretim Adımları

Aşağıdaki adımlar, yukarıdaki ikinci senaryoyu yeniden üretir; burada VPN kullanıcısı tünel yapılandırmasını değiştirir (ör. başka bir sunucuya geçmek veya DNS sunucusunu değiştirmek):

• WireGuard uygulamasını kullanıyoruz çünkü bu, Android VPN için referans bir uygulamadır
• Sızıntının büyük olasılıkla diğer Android VPN uygulamalarıyla da yeniden üretilebileceğini unutmayın
• getaddrinfo kullandığını doğrulanmış uygulamalardan biri olduğundan sızıntıyı tetiklemek için Chrome kullanıyoruz

1. spam_get_requests.html dosyasını indirin

2. WireGuard uygulaması ve Chrome'u yükleyin

3. wg1.conf, wg2.conf dosyalarını WireGuard'a alın

4. WireGuard uygulamasında wg1 tünelini etkinleştirip VPN iznini onaylayın

5. Android VPN ayarlarından WireGuard için "Always-on VPN" ve "Block connections without VPN" seçeneklerini açın

6. Router'da tcpdump ile veri yakalamaya başlayın $ tcpdump -i <INTERFACE> host <IP of android device>

7. WireGuard ve Chrome'u yan yana görebilmek için ekranı bölünmüş moda alın

8. Chrome'da spam_get_requests.html dosyasını açın ve "Start"a tıklayın

9. WireGuard uygulamasında wg1 ve wg2 arasında geçiş yaparak, bir sonraki adımda sızıntı gözlenene kadar bunu tekrar edin

10. Router'da aşağıdaki DNS trafiğini gözlemleyin:

    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)
    

"Block connections without VPN" etkin olsa da, şifrelenmiş WireGuard trafiği dışında cihazdan hiçbir şey çıkmaması gerekirken burada düz metin DNS paketlerinin dışarı gittiği görülüyor

Sonuç ve Öneriler

DNS sızıntısı, kullanıcının gizliliğini ciddi şekilde etkileyebilir; kullanıcının yaklaşık konumunu, kullandığı web sitelerini ve hizmetleri ortaya çıkarmak için kullanılabilir

Bu bulgular, "Block connections without VPN" etiketinin (veya belgesinin) yetersiz olduğunu ve birden fazla sorunu bir kez daha gösteriyor:

• Yukarıda belirtilen koşullarda, uygulamalar hâlâ DNS trafiği sızdırabiliyor
• Daha önce bildirilen bağlantı doğrulama trafiği sızıntısı hala devam ediyor

Tehdit modelinize göre hassas görevler için Android'i tamamen kullanmamayı ya da sızıntıyı engellemek amacıyla farklı azaltıcı önlemler almayı düşünebilirsiniz:

• Uygulamanın bu sorunu kısmi olarak hafifletmeyi hedeflediği için, uygulamayı güncel tutmanız gerekir

GN⁺ Görüşleri

• Sorunun temelde Android OS hatasından kaynaklandığı açık; bu nedenle Google'ın yakın zamanda düzeltmesi gerekiyor. VPN uygulaması yapan tüm geliştiricilerin bu sorunu tek tek çözmeye çalışması doğru değildir
• "Block connections without VPN" seçeneğinin belgelendiği gibi çalışmaması ve DNS sızıntısının olması kullanıcılar için büyük bir sorundur. VPN'in ana kullanım amaçlarından biri gizlilik korumasıdır; DNS sızıntısı nedeniyle kullanıcıların web kullanımı gibi verileri açığa çıkabilir
• VPN tünel güvenliği hâlâ yüksek sayılabilir, ancak işletim sisteminin istem dışı sızıntı üretmesini önlemek için VPN dışında ek güvenlik/gizlilik çözümlerini birlikte kullanmak da düşünülmelidir
• Uygulama geliştiricileri açıktır, OS hatasını atlatmak için uygulamada geçici tamamlama girişimleri yapmakta; ancak uzun vadede kök nedeni gidermek üzere OS iyileştirilmesi gerektiği görülmektedir
• VPN teknolojisi gelişip yaygınlaştıkça bu tür güvenlik meseleleri öne çıkıyor. Gelecekte de mobil OS'lerin ağ ve VPN işlevlerine yönelik güvenlik denetimi ve sürekli iyileştirme gerekecektir

[GN⁺]

Hacker News yorumları

• Mullvad'ın konuyla ilgili zengin bilgisi, sorunun açıklaması, kısa vadeli çözümleri, olası kalıcı çözümleri ve Android'de düzeltilmesi gereken konular konusunda net şekilde açıklama yapması takdir toplamış.
• Android'deki "paranoid networking" sistem ve OEM uygulamalarına özel istisnalar içeriyor; rethinkdns geliştiricisine göre çoğu hata düzeltmesi bu temel varsayımı değiştirmeyecek.
• Android, iki TUN arayüzü arasında "sorunsuz el değiştirmeyi" desteklese de bunu hayata geçirmek zor.
• Android, yalnızca dahili DNS sunucularını kullanmak istese bile, gerektiğinde dış DNS'ye geçmek için hücresel veriye geçme sorununu uzun zamandır barındırıyor.
• Apple varsayılan olarak her şeyi bir "Privacy" VPN'iyle proxylemeye çalıştığı için, alternatif ürünlerde durumun daha iyi olmasını beklemek pek mümkün görünmüyor.
• Android'de IPv6 DNS sunucusu doğrudan ayarlanamıyor ve Wi-Fi her değiştiğinde bu ayar da değişiyor.
• VPN sunucusunun IP adresine gitmeyen tüm trafiği engellemek için bir MikroTik firewall cihazı kullanarak sızıntılar önlenebilir.
• Kök erişimi olmayan hiçbir sistem temelde güvenli değil ve Android ile iOS, bu açıdan gülünç birer örnek.
• En güvenli kurulum, telefondaki mobil veriyi kapatıp OpenWRT hotspot ile üst akışta VPN çalıştırmak.
• DNS sızıntısı, kullanıcının gezinme konumunu hatta gerçek konumunu bile ortaya çıkarabildiği için VPN'in amacını boşa çıkarır.
• iOS'ta da APNS trafiği VPN dışına sızıyor (provisioning profiliyle kurulan OS destekli VPN hariç).
• Bu tür bir "hata"nın kasıtlı olarak yerleştirilmiş olabileceği soruluyor; büyük teknoloji şirketlerinin istihbarat kurumlarıyla işbirliği yapabildiği gerçeği düşünüldüğünde Android'deki bu kadar çok hatanın yalnızca "tesadüfen" ortaya çıktığına inanmak zor.