Android'de DNS trafiğinin VPN tüneli dışına sızma ihtimali

 (mullvad.net)
2 puan yazan GN⁺ 2024-05-04 | 1 yorum | WhatsApp'ta paylaş
  • Android'de bazı uygulama·durum kombinasyonlarında DNS sorguları VPN tüneli dışına çıkabiliyor; Mullvad, nedenin VPN uygulamasından çok Android OS hatası olduğunu düşünüyor
  • Sızıntı, VPN açık olsa bile DNS sunucusunun boş olduğu durumlarda, tünel yeniden yapılandırılırken, VPN uygulaması zorla kapatıldığında veya çöktüğünde oluşan kısa geçiş aralıklarında meydana gelebiliyor
  • Etki, getaddrinfo'yu doğrudan çağıran uygulamalarda yoğunlaşıyor; Android API'si olan DnsResolver'ı kullanan uygulamalarda sızıntı tespit edilmedi
  • Always-on VPN ve “Block connections without VPN” açık olsa da sorun tamamen engellenmiyor; Android 14 dahil birden çok sürümde doğrulandı
  • Mullvad, geçici olarak sahte bir DNS sunucusu ayarlayarak bazı durumları hafifletmeyi planlıyor; ancak yeniden bağlantı sırasında oluşan sızıntının OS düzeyinde düzeltme olmadan tamamen engellenmesi zor

Android'de DNS sızıntısının ortaya çıktığı koşullar

  • Mullvad, 22 Nisan'da bir Reddit kullanıcı raporu üzerinden, “Block connections without VPN” açıkken VPN kapatılıp yeniden açıldığında DNS sızıntısı oluşabileceğini doğruladı
  • İç incelemede, Android OS'nin DNS trafiğini VPN dışına gönderebildiği ek senaryolar da ortaya çıktı
    • VPN etkin ama DNS sunucusu yapılandırılmamışsa
    • VPN uygulaması tüneli yeniden yapılandırırken
    • VPN uygulaması zorla sonlandırıldığında veya çöktüğünde oluşan kısa süre içinde
  • Bu davranış Android OS'nin beklenen davranışı değil ve daha üst OS seviyesinde düzeltilmesi gerekiyor

Etkilenen uygulamalar ve ad çözümleme yolu

  • Sızıntının, alan adı çözümlemesi için C fonksiyonu getaddrinfo'yu doğrudan çağıran uygulamalarda meydana geldiği görülüyor
  • Android API'si olan DnsResolver'ı kullanan uygulamalarda sızıntı tespit edilmedi
  • Chrome tarayıcısı, getaddrinfo'yu doğrudan kullanabilen bir uygulama örneği
  • getaddrinfo kullanımı başlı başına yanlış değil; tüm Android kullanıcılarını korumak için OS düzeyinde bir çözüm gerekiyor

Always-on VPN ve engelleme ayarlarının sınırları

  • Doğrulanan sızıntılar, Always-on VPN ve “Block connections without VPN” etkin olsun ya da olmasın meydana geliyor
  • “Block connections without VPN” açıksa, şifreli WireGuard trafiği dışında hiçbir şeyin cihaz dışına çıkmaması gerekir; ancak yeniden üretim sırasında düz metin DNS trafiği yönlendiricide gözlemlendi
  • Mullvad, bu ayarın adıyla veya belgelenmiş davranışıyla uyumlu olmadığını ve birden fazla kusur içerdiğini değerlendiriyor
    • Yukarıdaki koşullarda DNS trafiği sızabiliyor
    • Daha önce bildirildiği gibi bağlantı kontrol trafiği de hâlâ sızıyor

Mullvad uygulamasındaki geçici azaltma ve kalan sorunlar

  • Mullvad uygulaması şu anda engelleme durumunda DNS sunucusu ayarlamıyor
    • Tünel kurulumu geri döndürülemez biçimde başarısız olursa uygulama engelleme durumuna geçiyor
    • Bu durumda trafik cihaz dışına çıkmıyor, ancak DNS sunucusu boş kaldığı için sızıntı koşulu oluşabiliyor
  • Mullvad, OS hatasını dolaşmak için şimdilik sahte bir DNS sunucusu ayarlayarak yanıt vermeyi planlıyor ve bu düzeltmeyi içeren bir sürümü yakında yayımlamayı hedefliyor
  • Tünelin yeniden bağlanması sırasında oluşan sızıntıyı uygulama tarafında hafifletmek daha zor
    • Mullvad bir çözüm arıyor
    • Tünel yeniden yapılandırma sayısını azaltmak mümkün olabilir, ancak şu aşamada bu sızıntının tamamen önlenebileceğini düşünmüyor
  • Mullvad, sorunu ve iyileştirme önerisini Google'a bildirdi

WireGuard ve Chrome ile yeniden üretilen gözlem

  • İkinci senaryo olan VPN tüneli yapılandırması değişirken yaşanan sızıntı, WireGuard uygulaması ve Chrome kullanılarak yeniden üretilebiliyor
    • WireGuard, Android VPN uygulamasının referans örneği olarak kullanılıyor
    • Mullvad, bunun diğer Android VPN uygulamalarında da yeniden üretilebileceğini düşünüyor
    • Chrome, getaddrinfo kullandığı doğrulanmış bir uygulama olduğu için sızıntıyı tetiklemek amacıyla kullanıldı
  • Yeniden üretim adımları şu unsurları içeriyor
    • spam_get_requests.html dosyasını indirmek
    • WireGuard uygulamasını ve Chrome'u yüklemek
    • wg1.conf ve wg2.conf dosyalarını WireGuard'a içe aktarmak
    • WireGuard'da wg1 tünelini etkinleştirip VPN iznini vermek
    • Android VPN ayarlarında WireGuard için Always-on VPN ve “Block connections without VPN” seçeneklerini etkinleştirmek
    • Yönlendiricide tcpdump -i <INTERFACE> host <IP of android device> ile yakalamayı başlatmak
    • WireGuard ve Chrome'u bölünmüş ekranda açıp, Chrome'da spam_get_requests.html dosyasını çalıştırdıktan sonra WireGuard'da wg1 ve wg2 arasında dönüşümlü geçiş yapmak
  • Yönlendiricide, Android cihazdan OpenWrt yönlendiricisinin 53 numaralı portuna giden A kaydı sorguları ve NXDomain yanıtları gözlemlendi
  • DNS sızıntısı, kullanıcının yaklaşık konumunu veya ziyaret ettiği web siteleri ile servisleri belirlemek için kullanılabileceğinden gizlilik etkisi büyük olabilir
  • Tehdit modeline bağlı olarak hassas kullanım senaryolarında Android'den kaçınmak veya sızıntıyı önlemek için başka azaltma yöntemleri uygulamak gerekebilir
  • Mullvad uygulaması kullanıcıları, kısmi azaltma içerebileceği için uygulamayı güncel tutmalı

İlgili okumalar

1 yorum

 
GN⁺ 2024-05-04
Hacker News görüşleri

  • Mullvad kullanmıyorum ama gerçekten saygı duymaya başladım. Sorunun açıklaması, kısa vadeli geçici çözüm, başkalarının kullanabileceği olası geçici çözümler ve Android’de düzeltilmesi gereken noktalar; hepsi bilgi yoğun ve iyi düzenlenmiş

    • Rakipleri gibi bitmek bilmeyen YouTube sponsorlukları yapmak yerine böyle blog yazıları yayımladığı için VPN hizmeti olarak Mullvad’ı seçtim
    • VPN kullanmasanız bile Mullvad’ın ücretsiz bir DNS hizmeti var. Trafik/kullanım artışı da bir tür destek sayılabilir ve DNS istekleri açısından Mullvad VPN kullanıcılarının daha az göze batmasına da yardımcı olabilir
      Dezavantajı, benim durumumda ping sürelerinin quad9 veya cloudflare’den epey yüksek olması
      Bu başlıkta DNS düzeyinde reklam engelleme yöntemi ve cloudflare ile ilgili bilgileri yazmıştım: https://news.ycombinator.com/item?id=40056162
    • Değerleri, düşünce biçimi, temel inançlarına bağlılığı ve onlarca yıl boyunca sloganını koruduğuna dair istikrarlı kanıtlar düşünüldüğünde, bence en iyi VPN
    • Mullvad kullanıcısı olarak çok memnunum. Bir kez ödeme ile ilgili bir sorum için destek ekibine e-posta göndermiş, ayrıca yaşadığım bir sorun hakkında küçük bir iptables sorusu da eklemiştim
      Ödeme sorununu hızla çözdüler; iptables konusunda da çeşitli çözümlerin artı ve eksilerini içeren ayrıntılı bir yanıt aldım. Tek kelimeyle harika
    • VPN kullanıyorsan hangisini kullandığını merak ediyorum

  • rethinkdns geliştiricisiyim
    “Bu sorunların, hangi uygulama kullanılırsa kullanılsın tüm Android kullanıcılarını korumak için işletim sisteminde çözülmesi gerekir” sözüne gelirsek, Android’in paranoyak ağ yönetimi her zaman sistem uygulamaları ve OEM uygulamaları, yani Google uygulamaları dahil istisnalar barındırdı
    Bu tür hata düzeltmelerinin çoğunun da o temel varsayımı değiştirmesi pek olası değil. İlgili kod için: https://github.com/celzero/rethink-app/issues/224
    “Tünel yeniden bağlanırken oluşan sızıntıyı uygulama içinde hafifletmek daha zor. Hâlâ bir çözüm arıyoruz” kısmına gelince, Android yeniden yapılandırma sırasında iki TUN aygıtı arasında kesintisiz geçişi destekliyor. Doğru uygulaması zor ama mümkün

    • El feneri uygulamasının internet iznini bile kapatmanıza izin vermiyor; işletim sisteminin bir internet reklam şirketi tarafından işletildiğini düşününce mantıklı

  • Android’de çok eskiden beri var olan bir sorun. Yalnızca dahili DNS sunucularını kullanmasını isteseniz bile Android gerekli gördüğünde ya da istediğinde hücresel ağa geçip o DNS’i kullanıyor
    Yakın zamanda kablosuz bağlantının neden/ne zaman koptuğunu görmek için adb debug çıktısını izledim; sonunda canlılık kontrolü sırasında bir şeyi göremez veya yorumlayamazsa hücresel veriyi açıp deniyor
    Yalnızca içeride bulunan DNS kayıtlarını kullanırken telefonda rastgele çalışmaması özellikle sinir bozucu. Cihaz, söz konusu kaydı barındıran dahili DNS sunucusunu sağlayan Wi‑Fi’a bağlı olsa da Android bir nedenle dışarıdan çözümleme yapıyor
    Apple’ın nasıl olduğunu bilmiyorum ama temelde kendi “privacy” VPN’leri üzerinden DNS’i bile DoH ile proxy’lemeye çalıştıklarına bakınca, rakip sayılabilecek bir şey kullanırken daha iyi olacağını hayal etmek zor; Apple’ın bu tür ürünlere nasıl davrandığını da biliyoruz

    • “Hücresel ağa geçip gerekli gördüğünde ya da istediğinde kullanması”nın nedeni Wi‑Fi Assist açık olması olabilir; bunu kontrol etmek gerekir. Bu özellik, Wi‑Fi sinyali kötü olduğunda hücresel ağa geçmek için açıkça tasarlanmış
    • Apple veya iOS’ta yapılandırma profilleriyle trafiği filtrelemek ve engellemek için oldukça sağlam yerleşik bir yöntem var. Uygulama bazında ayar yapılıp yapılamadığından emin değilim ama ana makine adı izin listesi/engelleme listesi kesinlikle ayarlanabiliyor
      Gerçek bir örnek için şu sistem geneli reklam engelleyiciye bakılabilir: https://myxxdev.github.io/depictions/MYbloXXforiOS/MYbloXXfo...
    • iOS varsayılan olarak asla Private Relay kullanmaz. Aboneliğe dahil olsa bile açıkça sizin açmanız gerekir
    • Geliştirici seçeneklerinde “Mobil veri her zaman etkin” ayarını kapatmayı denedin mi, merak ediyorum
    • AOSP’yi kaynaktan derledim. Google’a özgü gereksinimler olmaması gereken bir şeydi ve gizlice Google’a bağlanmasını engellemek için hosts dosyasında mümkün olduğunca çok Google sunucusunu engelledim
      Yaşadığım tek sorun, düzgün çalışan bir kablosuz AP’ye bağlı olmasına rağmen cihazın internet yok göstermesiydi. Aslında çalışıyordu; ancak durum çubuğu simgesi ve diğer dahili sistem kodu amaçları için internetin çalışıp çalışmadığını Google sunucularıyla kontrol ediyor gibiydi
      Gizliliğe önem veriyorsanız Android’den uzak durmak iyi olur; muhtemelen genel olarak teknolojide de dikkatli olmak gerekir

  • Birkaç yıl önce bir proje için çeşitli VPN yapılandırmalarını test ederken, bilgisayar ile ana yönlendirici arasına bir MikroTik güvenlik duvarı cihazı koyardım. Amaç yalnızca PC’nin bağlanmaya çalıştığı VPN sunucusu IP adresi hedef olmayan tüm trafiği engellemekti
    Bu yöntem, PC’den VPN sunucusuna giden yolun dışına trafik sızmamasını garanti etmekte çok iyi çalıştı. Kullandığınız VPN sunucusunun IP adresi neredeyse hiç değişmez; değişse bile MikroTik güvenlik duvarında değiştirmek kolaydır
    Sunucu IP’sini bilmiyorsanız veya değişiyorsa, VPN sunucusunun kullandığı port/protokol çiftinden başka tüm trafiği engellemek de mümkün. Örneğin VPN türüne bağlı olarak hedefi UDP 1194 olmayan trafiği düşürmek gibi
    MikroTik yönlendiricilerde trafiği hızlı ve kolayca görmeyi sağlayan torch adlı küçük bir araç da var ve paket yakalamayı da destekliyor. Fiyatları 30 dolardan 3000 dolara kadar değişiyor; yazılım lisansı yok ve kullanmayı biliyorsanız çok güçlü ve yetenekli

    • Bu tür cihazlara network slug denir ve çok iyi bir fikir
      Kesin konuşmak gerekirse gerçek bir slug, IP adresi tanımlanmamış şeffaf bir katman 2 güvenlik duvarıdır; ama burada bu ayrıntıya takılmaya gerek yok
      https://john.kozubik.com/pub/NetworkSlug/tip.html

  • Kaynak/hedef adresi ve portuna göre çıkış yönlü filtreleme, güvenlik duvarlarının temel kavramı ve tüm güvenlik duvarı-yönlendirme platformlarında standart yapılandırmadır. Ağ geçidine göre filtreleme yapan ilke tabanlı yönlendirme de aynı bağlamdadır: https://en.wikipedia.org/wiki/Policy-based_routing
    Genel olarak varsayılan olarak tüm çıkış trafiğine izin verenler yalnızca tüketici ya da yarı profesyonel ürünlerdir. Bu yapılandırmada “ana yönlendirici”nin ne olduğunu merak ediyorum. ISS’nin sağladığı ekipman mıydı?

    • Önermişken, ucuz ve iyi bir 7. katman güvenlik duvarı yönlendiricisi de var mı merak ediyorum
      Telefon uygulamaları ile modem arasına bir güvenlik duvarı yerleştirebilsek iyi olurdu

  • Android’deki DNS sorunu, bu platformda kendi IPv6 DNS sunucunuzu ayarlayamamanızda. Wi‑Fi’da bir şey değiştiği her seferinde değişip gidiyor
    Root’lu Android’de bile işletim sisteminin bunu değiştirmesini engelleyen bir uygulama yok
    Sürekli IPv6 adresi dağıtan ve bunu kapatmanıza izin vermeyen bir yönlendirici kullanıyorsanız, fiilen engellenmiş oluyorsunuz
    O yönlendiricinin arkasına bir güvenlik duvarı cihazı kurup yönlendiricinin duyurduğu IPv6 DNS sunucusunu kaldırmak mümkün mü, onu da bilmiyorum

    • DNS sunucusu IP adresini ayarlamak yerine sistem düzeyindeki DNS-over-TLS desteğini kullanmak nasıl olur diye düşünüyorum. Küresel bir ayar olduğundan hangi ağda olursanız olun, o ağda ne olursa olsun uygulanması gerekir
      DNS isteklerinin sızmasını önemsiyorsanız zaten DoT ya da DoH kullanmanız gerekir
    • rethink ile IPv6 DNS değiştirilemiyor mu?
    • Bunun, telefon ana arayüz olduğunda gerçekleştiği anlamına geliyor gibi görünüyor
      Wi‑Fi tethering’de de aynı şey oluyor mu merak ediyorum. Telefonun Wi‑Fi’ı üzerinden bağlanan bir dizüstünde VPN kullanırsanız aynı şekilde sızar mı?

  • En güvenli yapılandırma, telefonun mobil verisini kapatıp VPN’i telefonun üst tarafında işleyen bir OpenWRT hotspot taşımak gibi görünüyor

    • Evet. iOS’ta bu daha büyük bir kâbus
      “Her zaman açık VPN” yalnızca Apple’ın onayladığı bir kuruluşun MDM çözümüyle “supervised” durumdaki cihazlarda ayarlanabiliyor. Belgelenmiş bir başvuru ve mevcut bir çalışanla telefon görüşmesi gerekiyor
      Ya da Mac’te Apple Configurator uygulamasını kullanarak “always-on VPN” anahtarını içeren bir yapılandırma profili oluşturmanız gerekiyor
    • Eskiden GL.inet E750 ve SIM’siz bir iPhone ile aylarca bunu denedim; ABD’deki GSM operatörleri garip portlardaki UDP trafiğini sık sık ciddi biçimde kısıtlıyordu. 64~128 kbps, yani 0,1 Mbps seviyesine kadar düşebiliyordu
      Bildirimler de sık sık gecikiyordu
    • Halka açık Wi‑Fi ya da mobil iletişim kullanıyorsanız en iyi çözüm bu. Birisi doğrudan baz istasyonu işletirse telefonunuz ona bağlanabilir
      Kendi ağım değilse mobil yönlendirici olmadan doğrudan bağlanmamak daha iyi
    • Başkaları Android’in çeşitli koşullarda hücresel veriyi sessizce yeniden açtığını söylediğine göre, bu yöntem de kesin bir çözüm değil
      The Grugq 10 yıl önce bu amaçla bir araç yapmıştı. Ne yazık ki artık bakımı yapılmıyor: https://github.com/grugq/portal
      Hacker’lar için operasyon güvenliği sunumunun bir parçasıydı; ünlü ya da kötü şöhretli birçok hacker’ın güvende olduklarını düşündükleri hâlde sonunda yakalandığı örneklerle ilgileniyorsanız izlemeye değer: https://www.youtube.com/watch?v=9XaYdCdwiWU

  • root erişimi olmayan sistemler tanım gereği güvenli değildir. Android ve iOS gülünç durumda

    • Root erişimi diye bir kavramı olan sistemlerin tanım gereği güvenli olmadığı da söylenebilir. Bu tür kesin hükümler herkes tarafından verilebilir
    • Telefonlar çoğu insan için masaüstü/dizüstünün yerini almamış olsaydı gülüp geçilebilirdi
      Bilgisayar olarak yalnızca çoğunlukla medya tüketimi ve özel veri toplama için tasarlanmış cihazlarla büyümüş ya da büyüyecek çocuklara üzülüyorum
    • GrapheneOS geliştiricileri root’a gerçekten çok karşı. Bunun hakkında ne düşündüğünüzü merak ediyorum
    • Nokta gayet net ve konuyla da ilgili. Bu yüzden açık kaynak yazılım ve donanım mobil cihaz projelerinin artmaya devam etmesi kaçınılmaz
      https://en.wikipedia.org/wiki/PinePhone_Pro
    • Bu tanıma göre en önemli sistemlerimin epeyce bir kısmı “güvensiz” sayılıyor
      Böyle bir cihazdaki SSH özel anahtarımın bir kopyasını alabilirseniz, sorgusuz sualsiz nakit 100 bin dolar veririm
      Bu tanım anlamsız; akıl yürütme ya da iletişim için de işe yaramıyor

  • “VPN olmadan bağlantıyı engelle” seçeneğinin, açık büfedeki özdenetimim kadar güvenilmez olduğu ortaya çıkıyor. Yanılmıyorsam bu tür DNS sızıntıları, ziyaret edilen siteleri ve konumu bile epey açığa çıkarabildiği için VPN’in amacını baştan çökertiyor
    Android, VPN açık olsa bile DNS bilgisini sızdırabildiğinden, gizliliğe gerçekten hassassanız Android kullanmanın ötesini düşünmek ya da hassas işleri telefondan çıkarmak daha iyi

  • Bazen bu tür “hata”ların kasıtlı olarak iyi yerleştirilmiş olup olmadığından şüpheleniyorum. Özellikle büyük teknoloji şirketlerinin çeşitli istihbarat kurumlarıyla işbirliği yapmış olduğu gerçeği varken
    Android’de bu tür bir hatayı ilk kez duymuyorum; bu kadar çok hatanın “istemeden” girdiğine artık inanmak zor

    • “Bir kez olursa tesadüf, iki kez olursa coincidence, üç kez olursa düşman eylemidir.” —Ian Fleming, Goldfinger

  • Eskiden beri bunun böyle olabileceğinden bir ölçüde şüpheleniyordum. Android’de VPN’i açsanız bile MMS ve Visual Voicemail hâlâ çalışıyor
    İkisi de doğrudan mobil erişim gerektirebiliyor ya da aksi hâlde reddedilebiliyor. Yalnızca mobil ağdayken çalışabiliyor veya istek mobil ağın içinden gelmiyorsa reddedilebiliyor. VoLTE’nin de aynı şekilde olduğunu sanıyorum. VPN varken bu işlevler karışabilir
    Mobile Linux’ta VPN’i açınca bu işlevlerin hepsinin bozulmasından bunu anlıyorsunuz
    Android’de beklenen birçok işlevi bozmadan bunu düzeltmenin açık bir yolu yok gibi görünüyor

    • İronik biçimde SMS/MMS ve VVS, operatör bağlantısına sabit kodlanması haklı görülebilecek az sayıdaki iş/işlevden. Sistem güncellemeleri de belki öyle olabilir

VPN açıkken iOS’ta AT&T’nin ileri destek ekibiyle VVS sorunu yüzünden uğraşmış biri olarak, bu sorunun yalnızca Android’le sınırlı olmadığını doğrulayabilirim

  • VoLTE, LTE yığınında özel bir bearer, yani ayrı bir ağ arayüzü kullanır. Veri için kullanılan arayüz değildir
    Farklı bearer’lar farklı önceliklere/QCI’ye, yani hizmet kalitesine sahip olabilir. Yoğun bir LTE ağında VoLTE’nin, daha düşük öncelikli bir bearer üzerindeki VOIP’e göre daha iyi bir deneyim sunması gerekir