Android NAT-T keepalive API'si sıradan uygulamaların VPN lockdown dışına paket göndermesine izin veriyor

VPN lockdown'unun uygulama düzeyinde aşıılması

Bir güvenlik araştırmacısı, kullanıcı Always-on VPN ve "VPN olmadan bağlantıları engelle" (lockdown) ayarını etkinleştirmiş olsa bile, sıradan bir Android uygulamasının trafiği cihazın fiziksel ağı üzerinden dışarı çıkarabileceğini gösterdi. 12 Eylül 2026'da Hacker News ana sayfasına ulaşan Armin Šupuk imzalı bir makaleye göre bu yol, NAT geçişi (NAT-traversal) keepalive'ları için herkese açık bir platform API'sinden geçiyor ve yarattığı açık, Android 12 veya sonraki sürümleri çalıştıran cihazların çoğunu etkiliyor.

Bu iki ayar, kapsam altındaki uygulamaların geri düşmek yerine durdurulmasını amaçlıyor: tünel kullanılamadığında trafiği temeldeki Wi-Fi veya hücresel ağı kullanmamalı ve cihazın gerçek ağ adresi tünelin dışındaki hiçbir şeyden gizli kalmalıdır. Šupuk'un bulgusu, özel ayrıcalıkları olmayan normal bir uygulamanın her iki sözü de ihlal edebildiğidir.

Aşama nasıl çalışıyor

Bu yol iki herkese açık API kullanıyor. Bir uygulama bir IpSecManager.UdpEncapsulationSocket açıyor, ardından ConnectivityManager.createSocketKeepalive çağrısıyla bir NAT eşlemesinin korunmasını istiyor. İstek, framework'ün bağlantı servisindeki startNattKeepaliveWithFd fonksiyonuna dahili olarak iletiliyor, keepalive takipçisi ve aktif ağ ajanından geçiyor ve Wi-Fi donanım soyutlama katmanı ile yonga seti donanım yazılımında sonlanıyor; burada fiziksel bağlantı üzerinden 4500 numaralı portta UDP paketleri iletiliyor.

Makaleye göre bu durumu sorun haline getiren iki özellik var. Paket iletimi normal socket katmanının altına devredildiği (offload) için, paketler uygulamanın yeni bir socket yazması olmadan çıkıyor — ve lockdown'un normalde uyguladığı UID başına yönlendirme, fwmark ve firewall denetimlerinin dışında kalıyor. Ayrıca platform paketin biçimini sabitlerken, çağıran taraf API'nin yönlendirme kısıtları çerçevesinde hedefi seçebiliyor.

Šupuk kök nedeni aşınan bir güven modeline bağlıyor: Bir zamanlar ayrıcalıklı bir raw file descriptor kabul eden keepalive giriş noktası, herkese açık UdpEncapsulationSocket yoluna genişletildi; IpSec kaynağı için bir doğrulama adımı eklendi ve sonra geri alındı; bugün kabul süreci ne file descriptor ile kaynak kimliğinin birlikte ait olduğunu kanıtlıyor ne de devretmeden önce çağıran uygulamanın güncel VPN politikasını denetliyor.

Neler ölçüldü

Çalışma zamanı kanıtları, üç üreticinin Android 16'daki cihazlarını kapsıyor:

• Pixel 8 Pro'da (derleme CP1A.260505.005), erişim noktasında alınan bir yakalama, Always-on VPN ve lockdown'un her ikisi de açıkken UDP/4500 paketlerinin herkese açık olan en küçük aralık olan on saniyede geldiğini kaydetti. Makale ayrıca bu davranışı arka plana alma, ekran kilidi, Doze, pil tasarrufu, kısıtlı standby bucket ve Binder freezer durumlarında ve force-stop, kaldırma, ağ kaybı ve yeniden başlatma sınırlarında da haritalandırıyor.
• Samsung SM-F966B'de aynı herkese açık yol, bir aktif Wi-Fi keepalive slotunu ortaya çıkardı. Makaledeki VPN Leak Guard kurulumu fiziksel IPv4 varsayılan ağ geçidini seçti, aktif geri çağırmayı gözlemledi ve 24 saat 32 dakika süren, yönlendiriciye yönelik kesintisiz bir slot kirası kaydetti.
• Nothing A059'da uygulama benzer şekilde fiziksel ağ geçidini seçti ve bir aktif Wi-Fi slotu buldu. Šupuk, bu cihaz için bağımsız bir paket yakalama veya süre ölçümü yapılmadığını not ediyor; dolayısıyla bu, tam bir tekrar değil, üçüncü bir üreticide kabul yolunun doğrulanması niteliğinde.

Donanım yazılımı tarafında makale, tahmini Android kaynaklı sevkiyatların yüzde 91,24'ünü temsil eden yedi WLAN ailesi sayıyor; kalan yüzde 8,76'sı çözümlenemedi — Android 12+ cihazlar hakkındaki sınıf geneli sonuç da buna dayanıyor.

Ekosistem taraması ve önceki sinyaller

Šupuk ayrıca F-Droid ve IzzyOnDroid'deki 4.679 farklı depolanmış Git origin'i taradı ve Android'in framework IPsec, IKE veya NAT-T API'lerinin kullanımını tespit etmedi; manuel bir denetimde 73 uygulamanın VpnService kullandığı görüldü. Makalenin sunduğu tabloyla, sıradan meşru hiçbir uygulama bu belirli keepalive yoluna bağımlı görünmüyor.

Alan tamamen incelenmemiş de değil: makale, ilgili bir keepalive API'sinin PACKET_KEEPALIVE_OFFLOAD iznini gerektirirken fd tabanlı varyantın gerektirmediği bir izin tutarsızlığına dikkat çeken önceki Android Automotive erişim denetimi çalışmasına atıf yapıyor. Šupuk'a göre o araştırma tutarsızlığı bildirdi, ancak bunu herkese açık UdpEncapsulationSocket güven açığına veya lockdown altındaki fiziksel Wi-Fi iletimine kadar izlemedi.

Neden önemli

VPN lockdown, hem gizlilik odaklı kullanıcılar hem de kurumsal politika tarafından sert bir sınır olarak görülüyor. Bu araştırma, bunun uygulama socket katmanında uygulanırken, daha alt düzeyde ve devredilmiş bir iletim yolunun kurulu herhangi bir uygulama tarafından hâlâ erişilebilir kaldığını gösteriyor. Sızan paketler sabit bir yük taşıyor, ancak kullanıcının tünel dışındaki trafiği açıkça yasaklamasından sonra, cihazın fiziksel kaynak adresini ve zamanlamasını uygulamanın seçtiği bir hedefe tekrar tekrar ifşa ediyor.

Etkilenme alanı durumu daha da ağırlaştırıyor: makalenin donanım yazılımı rakamlarına göre birden çok üreticinin Android 12+ cihazlarının çoğu açıkta ve devri framework'ün kendisi verdiği için davranış, sorunlu bir uygulamanın alışılmış ağ düzeyi belirtilerini taşımıyor. Teşhis ayrıca düzeltmenin nereye ait olduğunu da gösteriyor: file descriptor ve IpSec kaynak çifti üzerinde sahiplik denetimlerinin geri getirilmesi ve herhangi bir keepalive donanıma devredilmeden önce çağıran tarafın geçerli VPN politikasının dikkate alınması gerekiyor.