Saldırganlar, yönlendirme tabanlı VPN açığa çıkarması yapabiliyor

 (leviathansecurity.com)
3 puan yazan GN⁺ 2024-05-07 | 1 yorum | WhatsApp'ta paylaş
  • TunnelVision (CVE-2024-3661), DHCP’nin mevcut bir özelliğini kötüye kullanarak kullanıcının trafiğini VPN tünelinin dışına saptırıyor; bu sırada paketler VPN ile şifrelenmiyor
  • Saldırgan, DHCP option 121 ile daha spesifik rotalar enjekte ederek VPN sanal arayüzünden daha yüksek önceliğe sahip yollar oluşturabiliyor ve trafiği fiziksel arayüze gönderebiliyor
  • Hedef saldırganın kontrol ettiği DHCP kiralamasını kabul eder ve istemci option 121’i uygularsa saldırı mümkün; testlerde Windows, Linux, iOS ve macOS etkilenirken Android hariç tutuldu
  • VPN kontrol kanalı çalışmaya devam ettiği için kullanıcı bağlantıyı aktif görmeye devam ediyor; gözlemlenen örneklerde kill switch bile trafik sızıntısını engelleyemedi
  • Linux’taki network namespace güçlü bir çözüm olabilir, ancak güvenlik duvarı tabanlı azaltmalar seçici hizmet reddi ve trafik hedefi çıkarımı için yan kanal oluşturabilir

TunnelVision’ın oluşturduğu VPN decloaking

  • TunnelVision, VPN kapsüllemeyi atlayarak kullanıcının trafiğini tünel dışına zorla gönderen bir ağ tekniğidir
  • Saldırgan, DHCP (Dynamic Host Configuration Protocol) kullanarak hedef paketlerin VPN ile şifrelenmeden iletilmesini sağlayabilir
  • VPN kontrol kanalı korunduğu için kullanıcı VPN’e bağlı görünmeye devam eder; bu etkiye decloaking denir
  • Bu teknik 2002’ye kadar uzanıyor olabilir ve açıklanmasının ardından DHCP option 121 ile VPN etkisine dair önceki araştırmaların en az 2015’ten beri var olduğu doğrulandı

VPN yönlendirmesi neden bir saldırı yüzeyi oluyor

  • VPN, ana cihaz ile başka bir ağdaki sunucu arasında trafik için bir tünel oluşturur ve VPN istemcisi sanal ağ arayüzünde trafiği şifreleyip çözer
  • Tüm trafiği VPN’e gönderen yapılandırmaya full-tunnel VPN, yerel ağ gibi istisnalar içeren yapılandırmaya ise split-tunnel VPN denir
  • VPN, sunucuyla bağlantıyı sürdürmek zorunda olduğundan, VPN sunucusunun IP’sine giden trafiği fiziksel arayüze gönderen istisna rotalara ihtiyaç duyar
  • Yönlendirme tablosu trafiğin yolunu hedefe göre belirler ve çoğu ağ yığınında daha spesifik CIDR prefix length daha yüksek önceliğe sahiptir
    • /32 rotası, /24 veya /0 rotasından önce gelir
    • Birçok full-tunnel VPN, trafiği VPN arayüzüne göndermek için 0.0.0.0/0 veya iki adet /1 rota kullanır

DHCP option 121 ile rota enjeksiyonu

  • DHCP, yerel ağ cihazlarına IP adresi kiralamasını dinamik olarak sağlar ve options üzerinden varsayılan ağ geçidi ile DNS sunucusu gibi ayarları da iletir
  • Tipik akışta istemci DHCPDISCOVER yayını yapar, sunucu ise süre sınırlı bir kiralama önermek için DHCPOFFER ile yanıt verir
  • RFC 3442 ile gelen DHCP option 121, classless static routes işleviyle DHCP sunucusunun istemcinin yönlendirme tablosuna statik rotalar eklemesine olanak tanır
  • option 121, DHCP sunucusunun kurulacak rotanın ağ arayüzü aygıtını doğrudan belirtmesine izin vermez
    • DHCP sunucusu CIDR aralığını ve yönlendiriciyi belirtir
    • İstemci, DHCP sunucusuyla iletişim kurduğu arayüzü bu rotanın arayüzü olarak örtük biçimde seçer
  • Bu davranış nedeniyle enjekte edilen rotalardaki trafik, VPN sanal arayüzü yerine DHCP sunucusuyla iletişim kuran fiziksel ağ arayüzünden çıkabilir

Saldırı koşulları ve uygulanış şekli

  • TunnelVision saldırısı için iki koşul gerekir
    • Hedef ana bilgisayar saldırganın kontrol ettiği DHCP sunucusundan kiralamayı kabul etmelidir
    • Hedef ana bilgisayardaki DHCP istemcisi DHCP option 121 desteğine sahip olmalıdır
  • Aynı ağdaki bir saldırgan çeşitli yollarla hedefin DHCP sunucusu olabilir
    • Gerçek DHCP sunucusuna DHCP starvation saldırısı yapıp ardından yeni istemcilere yanıt vererek
    • DHCPDISCOVER yayınına daha hızlı yanıt verip DHCP istemcisinin first-offer seçim davranışını kötüye kullanarak
    • ARP spoofing ile gerçek DHCP sunucusu ve istemci arasındaki trafiği ele geçirip kiralama yenilemesini bekleyerek
  • Saldırgan, hedef VPN kullanıcısıyla aynı ağda DHCP sunucusu çalıştırır ve kendisini ağ geçidi olarak ayarlar
  • Ardından DHCP option 121 ile VPN kullanıcısının yönlendirme tablosuna keyfi rotalar ekler ve VPN’in /0 rotasından daha spesifik rotaları yerleştirerek bunların VPN sanal arayüzünden daha yüksek öncelikli olmasını sağlar
    • Birden fazla /1 rota ayarlayarak çoğu VPN’in kullandığı 0.0.0.0/0 tüm trafik kuralı yeniden üretilebilir
    • Saldırgan, hangi IP adreslerinin VPN tüneline gideceğini ve hangilerinin saldırganın DHCP sunucusuyla iletişim kuran arayüze gideceğini seçebilir
  • Bu yöntem halihazırda kurulmuş VPN bağlantılarına da uygulanabilir; DHCP kiralama süresi kısa ayarlanırsa yönlendirme tablosunun daha sık güncellenmesi tetiklenebilir

PoC ve deney senaryoları

Etkilenen işletim sistemleri ve VPN’ler

  • Testlerde, RFC spesifikasyonuna uygun DHCP istemcisi uygulayan ve DHCP option 121 rotalarını destekleyen işletim sistemlerinin etkilendiği görüldü
    • Etki gözlendi: Windows, Linux, iOS, macOS
    • İstisna: Android, DHCP option 121 desteği olmadığı için etkilenmiyor
  • Ana cihaz trafiğini korumak için yalnızca yönlendirme kurallarına dayanan VPN’ler savunmasızdır
  • Kendi VPN sunucusunu işleten sistem yöneticileri de VPN istemci yapılandırmasını sıkılaştırmadılarsa savunmasız olabilir
  • Şifreleme algoritmalarının gücü bu durumdan etkilenmez
    • TunnelVision, WireGuard, OpenVPN, IPsec gibi VPN protokollerini doğrudan kırmaz
    • Bunun yerine işletim sisteminin ağ yığınındaki yönlendirme yapılandırmasını değiştirerek kullanıcının VPN tünelini kullanmamasını sağlar

Düzeltmeler ve azaltma yöntemleri

  • Linux’taki network namespace bu davranışı tamamen düzeltebilir
    • WireGuard belgeleri, VPN kullanması gereken uygulama trafiğinin ayrı bir namespace içinde işlenip ardından fiziksel arayüzün bulunduğu başka bir namespace’e gönderilmesini gösteriyor
    • Windows, macOS ve diğer işletim sistemlerinde aynı derecede sağlam bir çözüm olup olmadığı net değil
  • Bazı VPN sağlayıcıları, fiziksel arayüz üzerindeki tüm gelen ve giden trafiği güvenlik duvarı kurallarıyla engelleyen azaltmalar kullanıyor
    • LAN ve VPN sunucusu bağlantısını korumak için DHCP ve VPN sunucusu IP’si istisnaları gerekir
    • Derin paket inceleme ile yalnızca DHCP ve VPN protokollerine izin vermek de mümkün olabilir, ancak bunun performans cezası yaratma ihtimali vardır
  • Güvenlik duvarı tabanlı azaltmalar, DHCP rotalarını kullanan trafikte seçici hizmet reddi oluşturur ve ek yan kanallar yaratır
    • Saldırgan, VPN ile şifrelenmiş trafik hacmindeki değişiklikleri analiz ederek hedef kullanıcının belirli bir hedefe trafik gönderip göndermediğini istatistiksel olarak kanıtlayabilir
    • Önceden tanımlı listelerle karşılaştırma yapabilir, sansür mekanizması olarak seçici engelleme uygulayabilir veya IP alanı engellemeyi ikili arama benzeri bir yöntemle kullanarak mevcut bağlantıyı logaritmik sürede bulabilir
  • VPN kullanımı sırasında option 121’i yok saymak da mümkündür, ancak bu özellik meşru ağ bağlantıları için gerekli olabileceğinden bağlantı sorunları yaratabilir
    • Bu azaltma isteğe bağlıysa saldırgan ağ erişimini engelleyerek VPN’i veya kullanıcıyı option 121’i yeniden açmaya zorlayabilir
  • Hotspot’lar veya VM’ler de yardımcı olabilir
    • Hücresel cihazın kontrol ettiği parola korumalı LAN, saldırganın yerel ağa erişmesini engellemeye yardımcı olabilir
    • VM, ağ adaptörü bridged mode’da değilse benzer şekilde davranabilir

Kullanıcılar ve operatörler için gerekli adımlar

  • Hassas trafik için güvenilmeyen ağlardan kaçınılmalı; bu mümkün değilse TunnelVision’a karşı etkili azaltmalara sahip bir VPN sağlayıcısı kullanılmalı
  • VPN decloak gerçekleşse bile HTTPS web sitelerine erişiliyorsa çoğu kullanıcı verisi yerel ağdaki saldırgan tarafından görülemez, ancak hedef ve protokol açığa çıkabilir
  • Kurumsal VPN’ler kafe, otel, havaalanı gibi yerlerde kullanılıyorsa ağ yöneticileri risk konusunda uyarıda bulunmalı ve mümkün olduğunca bundan kaçınılmasını önermelidir
    • Bu pratik değilse, azaltma veya düzeltme uygulanmış VPN’lerin kullanımı yönlendirilmelidir
    • Güvenilir bir hotspot kullanıp ardından VPN’e bağlanmak ya da VPN’i sanal DHCP sunucusundan kiralama alan bir VM içinde çalıştırmak da mümkündür
  • Kendi ağını veya site-to-site VPN işleten şirketler anahtarları denetlemeli ve DHCP snooping ile ARP koruması gibi Layer 2 korumalarını etkinleştirmelidir
    • Bu korumalar rogue DHCP sunucularını azaltmaya yardımcı olur, ancak kötü niyetli yönetici senaryosunu ortadan kaldırmaz
    • İç kaynaklarda HTTPS veya başka şifreli protokollerin uygulanması, güvenilmeyen ağlardan bağlanan VPN kullanıcılarının veri sızıntısını önlemeye yardımcı olur
  • VPN sağlayıcıları, ağ arayüzüne giden giden paketleri engelleyen güvenlik duvarı özelliklerini istemcilerine ekleyebilir; ancak bu durumda kullanıcılar yerel ağ kaynaklarıyla etkileşim kuramaz
  • Linux için full-tunnel VPN istemcileri, network namespace kullanan izolasyonu değerlendirmelidir
  • İşletim sistemi bakımcıları, Linux dışındaki sistemlerde network namespace ile ilgili özelliklerin eklenmesini veya güçlendirilmesini değerlendirmelidir
  • LAN güvenliği araştırmaları ve gerçek saldırı gösterimleri için ArcaneTrickster adlı bir adversarial infrastructure kütüphanesi geliştiriliyor ve daha sonra yayımlanması planlanıyor

İlgili okumalar

1 yorum

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

  • Bu, 2016’da Samy Kamkar’ın PoisonTap saldırısının hafifçe değiştirilmiş bir versiyonu. USB/Thunderbolt ağ adaptörüyle aynı işi yapıyor; kurban cihaza takıp 0.0.0.0/1 ve 128.0.0.0/1 gibi daha spesifik iki rota ilan ederseniz, arayüz sırasından bağımsız olarak diğer sistem arayüzlerinin önüne geçip tüm trafiği üzerine alabilir: https://github.com/samyk/poisontap
    Muhtemelen başka önceki örnekler de vardır ama bu oldukça iyi bilinen bir örnek. Yazının başlığı tüm VPN istemcilerinin etkilendiğini söylüyor ama metnin de kabul ettiği gibi, birçok VPN istemcisi fiziksel arayüze gidip gelen trafiği engelleyen güvenlik duvarı kuralları koyuyor
    Kimlik gizliliği vaat eden ya da bu gizliliğin önemli olduğu VPN’ler genelde bunu uygular. Varsayılan olarak açık olmayan çok ayar vardır ama büyük bireysel/ticari/kurumsal VPN çözümlerinin yüzde kaçının bunu varsayılan olarak açtığını belgelemiş olsalardı daha faydalı olurdu
    Genel okur için açıklama iyi ama bu tür güvenlik duvarı kurallarıyla çoğu veri sızıntısını engelleyen çok sayıda istemci varken ve bu alandaki önceki örnekler de anılmıyorken, başlık biraz abartılı görünüyor

    • Güzel yakalanmış. Temel güvenlik duvarı kuralları bile olmadığı için zaten bolca sızdırıyor olması muhtemel VPN’ler dışında, pek de önemli bir açık değil
      “Yan kanal saldırısı” ifadesini görünce az kalsın içtiğimi püskürtüyordum
      Düzeltme: Görünüşe göre NordVPN, en azından macOS’ta, böyle varsayılan güvenlik duvarı kurallarına sahip değil; bu yüzden bu saldırıya açık gibi duruyor

  • Bu yazının neden bu kadar uzun olduğunu anlamadım
    DHCP Option 121, DHCP sunucusunun belirli CIDR aralıkları için yönlendirme kuralları ayarlamasını sağlar ve daha uzun önek olduğu için varsayılan 0.0.0.0/0 kuralından daha yüksek öncelik alır

    • Yazının yazarlarından biriyim. Teknik olmayan geçmişe sahip okurların da geleceğini düşündüğümüz için ilgili konuları önce açıklamak istedik
      İnternetteki VPN bilgilerinin yarısı VPN sağlayıcıları tarafından yazılıyor ve bunlar gerçekte nasıl çalıştıklarını açıklamak için ya hatalı ya da yeterince teknik değil
      Girişe “bunları zaten biliyorsanız POC bölümüne atlayın” diye bağlantılı bir cümle koymayı planlıyordum, daha görünür olacak şekilde güncelleyeceğim
    • Ayrıca saldırganın bu saldırıyı tetikleyebilmesi için kurbanla aynı katman 2 ağı üzerinde olması gerekiyor
      Yazıyı okumadan, sadece yukarıdaki yoruma bakarak yaptığım bir tahmin bu

  • Bu saldırıyı daha önce başka bir yazardan okuduğumu sandım, o yüzden aradım; arama sonuçlarına doluşan VPN şirketi spamlerini aştıktan sonra önceki çalışmayı [1] buldum
    Bu yazı, kusurun nasıl istismar edileceğini daha derin ele alıyor ve kavram kanıtına yardımcı olacak kod da içeriyor
    1: https://www.usenix.org/conference/usenixsecurity23/presentat...

    • O makaleye ekte referans veriliyor
      Ancak 2023 Ağustos tarihli makaledeki iki tekniğin hiçbiri DHCP option 121 ile rota itmekten yararlanmıyordu. DHCP üzerinden rota itmek, saldırganın aynı konumdan çok daha büyük etki yaratmasını sağlıyor. Örneğin RFC1918 dışı aralıklardan IP kiralamaları dağıtabildiği ya da DNS yanıtlarını sahteleyebildiği bir konumda
    • Bu “saldırı” yaygın olarak biliniyor ve OpenVPN istemcisinin bir ayar seçeneği olan redirect-gateway def1 ile de kullanılıyor

  • Tehdit modeli, rastgele bir saldırganın bir şekilde benim LAN’ımda DHCP sunucusu olabilmesi üzerine kurulu; düşük olasılık ama imkansız değil
    Öte yandan ISP’nin verdiği ağ geçidi cihazını kullanıyorsanız durum farklı

    • “Rastgele bir saldırganın benim LAN’ımda DHCP sunucusu olması” düşük olasılık ama imkansız değil diyorsanız, kafe Wi‑Fi tam olarak böyle bir durum değil mi?
      Çoğu VPN ürününün bir numaralı satış argümanı da bu
      Bu durumda doğru tepki 4G/5G bağlantısı kullanmak ve güvenmediğiniz şüpheli ağlara bağlanmamak olur
    • “O DHCP sunucusu” ifadesi, ağ içinde ayrıcalıklı özel bir cihaz olduğu varsayımını ima ediyor ama bu varsayım yanlış. DHCP bir broadcast protokolüdür ve cihaz ilk teklifi kabul eder
      Sıradan evlerde DHCP’nin yönlendirici tarafından verilmesi ve bu yüzden genelde ilk onun yanıt vermesi ikincil bir ayrıntı. Ağdaki kötü niyetli herhangi bir cihaz bu zafiyeti kullanabilir
    • VPN’in büyük kullanım senaryolarından biri, bağlandığım ağa güvenemediğim durumlar değil mi?
    • Ya da bağlandığım üçüncü taraf Wi‑Fi’da DHCP sunucusu olma durumu
    • Güvenilmeyen Wi‑Fi ağlarında koruma sağlamak, VPN’lerin sıkça reklamını yaptığı şeylerden biri

  • Linux’ta VPN arayüzünü VRF içine koyarak da hafifletme sağlanabilir. Örneğin systemd-networkd bunu varsayılan olarak destekliyor
    Dikkat edilmesi gereken nokta şu: VRF açıldığında l3mdev için ip rule girdisi 1000 olurken yerel trafik kuralı 0 oluyor. Yerel kuralı 1000 veya üzerine taşımanız gerekiyor

    • Artık uygulamaları belirli bir VRF içinde çalıştırmanın bir yolu var mı?

  • Bu “saldırı”, DHCP option 121’in akıllıca kullanılmış halinden ibaret. Ciddi biçimde bozuk istemci yapılandırmalarına karşı geçerli bir saldırı
    Varsayılan rotayı değiştirmek ya da bunu iki /1 rotayla ezip VPN uç noktasına giden host rotasını eklemek güvenli değil. Kapsüllenmiş trafiği alt ağdan düzgün biçimde yalıtmak için politika tabanlı yönlendirme kullanmanız gerekir. Örneğin Linux ağ ad alanları, FreeBSD vnet, OpenBSD rdomains gibi
    Paket filtresiyle kullanıcı alanı “kill switch” çözümlerini zorla bir araya getirmeye çalışmak, tasarım gereği kırık bir yaklaşım ve yaygın VPN barındırma şirketlerinin kendi temel uzmanlık alanlarını bile ne kadar az anladığını ya da umursadığını gösteriyor. Yine eski bir “kötü şeyleri sıralama” problemiyle karşı karşıyayız

  • Bu da yeni bir şey değil
    Sistemde IPv6 açıkken yalnızca IPv4 destekleyen VPN hizmeti kullanan insanlar için daha çok endişeleniyorum
    Bu gerçekten çok ters gidebilir

  • İstemci cihazda VPN’i atlatmanın çok fazla yolu var. Bu yüzden VPN gerektiğinde, istemci ile internet arasına VPN tünelini sonlandıran ve başka rota bulunmayan bir yönlendirici koymayı tercih ederim
    Bu tür seyahat yönlendiricileri çok kolay yapılandırılabiliyor, her yere taşınabiliyor ve ben de gerçekten bunu yapıyorum

    • Evde ise, her bir yönlendiricinin kendi Wi‑Fi ağına sahip olduğu özel VPN yönlendiricilerini güçlü biçimde tavsiye ederim. Bence bu, her cihazda VPN yazılımını yerel olarak çalıştırmaktan daha kolay bağlanır ve daha kararlıdır
      Örneğin iş intranetine VPN bağlantısını sürekli açık tutan bir “work” Wi‑Fi yönlendiricisi, Avustralya TV’si izlemek istediğimde Avustralya sunucusuna VPN bağlanan bir “Australia” Wi‑Fi’si ve son olarak normal ev interneti Wi‑Fi’si olabilir
      Birkaç eski Wi‑Fi yönlendiriciyle bunu yapmak çok kolay; bugünlerde ucuz ev tipi yönlendiriciler bile bir dereceye kadar VPN desteği sunuyor gibi görünüyor. VPN yapılandırmasını merkezileştirip hata payını azaltmanın yanı sıra, hangi cihaz olursa olsun ilgili Wi‑Fi’ye bağlanır bağlanmaz VPN kullanabilmesi de büyük bir avantaj
      Bunu birkaç eski yönlendiriciyle yapıyorum ama aslında tek bir ev yönlendiricisinin dünyanın farklı konumlarına VPN kurup konuma göre farklı Wi‑Fi ağları sunduğu bir ürün pazarı da olmalı gibi geliyor. Amaç, TV/Roku/iPad’in kolayca farklı bir bölgeden bağlanıyormuş gibi görünmesini sağlamak
    • Bu saldırı yalnızca yerel LAN’da güvenilmeyen bir cihaz varsa mümkün. Zaten VPN’i açık bir ağ geçidini doğrudan yanında taşıyorsan, güvenilmeyen LAN cihazları çok büyük bir endişe olmayabilir
      Yine de LAN’da güvenilmeyen bir cihaz varsa ve DHCP kullanılıyorsa, o cihaz bu teknikle şifrelenmemiş* trafiği gözetleyebilir. Ancak ağ geçidi gizlediği için gerçek IP’yi yine de bulamaz
      Bu saldırının en gerçekçi olduğu yer kafe Wi‑Fi’si gibi ortamlar. Böyle yerlere kendi yönlendiricini götürme ihtimali düşüktür
      Buradaki “şifrelenmemiş trafik”, VPN sağlayıcısına gönderilmek üzere kapsüllenmemiş trafik anlamına gelir. Günümüzde çoğu şey HTTPS olduğundan, bu trafiğin içeriği muhtemelen hâlâ şifreli olacaktır
    • İşe yarar birkaç donanım ve yazılım seçeneğini sıralamak zahmeti azaltabilir gibi görünüyor
    • Çoğu seyahat yönlendiricisi de muhtemelen hâlâ bu soruna açıktır

  • Teknik kişiler için oldukça bariz olması gereken bir şeydi, ama ağ ve VPN’e giriş açıklaması olarak iyi. Birkaç kez Linux VPN ağ geçidi VM’i kurdum; yalnızca yönlendirme tablosuna güvenen bir yapı bana hep kırılgan gelmiştir, özellikle de o bağlantıyı kullanan aynı makinede çalıştığında
    Ağ namespace’leri ve fiziksel VPN ağ geçidi yönlendiricilerine ek olarak, VM tabanlı mimari de bu sorunu çözebilir. Kendi homelab ortamımda güvenlik duvarı, VPN ağ geçidi VM’inden çıkan beklenmedik trafiği engelliyor. VPN VLAN’indeki cihazlar dışarıya doğrudan bağlanamıyor, ağ geçidi VM’i ise dış bağlantı için ayrı bir VLAN’a sahip
    Kişisel çözüm olarak QubesOS da benzer bir yapıyı oldukça az sürtüşmeyle kurmayı sağlıyor, ama yine de genel amaçlı işletim sistemlerinden daha fazla teknik bilgi gerektiriyor

  • “Android, DHCP option 121 desteğini uygulamadığı için etkilenmeyen tek sistemdi” kısmı ilginç
    Bunun, Google’ın bu sorunun farkında olarak bilerek aldığı bir karar mı yoksa tamamen tesadüf mü olduğunu merak ediyorum

    • https://issuetracker.google.com/issues/117544989 bağlantısına bakılırsa Google bu özellik talebini herhangi bir gerekçe sunmadan büyük ölçüde görmezden gelmiş gibi duruyor. Ben de aynı şeyi merak ediyorum. Google içinde Buganizer’a erişimi olan çalışanlar daha fazlasını biliyor olabilir
      Tahminimce Android ağ ekibi IPv6’ya oldukça sıcak bakıyor. IPv4’ün eksik köşe özelliklerine pek ilgi duymuyor gibiler. IPv6 için de nasıl kullanılması gerektiğine dair belirli bir vizyonları var; bunun sonucu olarak stateful DHCPv6 gibi özellikleri bilerek desteklemiyorlar
    • DHCP seçeneği çok fazla; dolayısıyla Android gibi bir sistem için önce yalnızca asgari desteği sunup, belirli bir seçeneğe talep geldikçe ek desteği açma stratejisi mantıklı
      Bu DHCP seçeneği yaygın kullanılmadığından, böyle bir strateji izleniyorsa güvenlik kaygılarından bağımsız olarak desteklenmemiş olma ihtimali yüksek
    • Android, 21 yıl önce ilk tanımlanan daha yeni DHCP sürümünü bile uygulamadı: https://www.rfc-editor.org/rfc/rfc3315
      O yüzden çok da şaşırtıcı değil