TunnelCrack versus TunnelVision: co každý z nich skutečně rozbíjí

Dvě výzkumná jména se používají zaměnitelně pro jakýkoli provoz VPN, který opustí tunel, ale mechanismy za nimi nejsou stejné. TunnelCrack popisuje dvě rodiny výjimek ve směrování; TunnelVision popisuje trasu dodanou přes DHCP na koncovém zařízení. Ani jedno nerozbíjí šifrování a ani jedno vám neřekne, co konkrétní verze klienta dělá dnes. Pět kontrol odděluje mechanismy od titulků.

První krok: pojmenujte mechanismus, který prověřujete

Zveřejnění TunnelCrack ze srpna 2023 popisuje dvě rodiny útoků. V případě místní sítě provoz, který klient považuje za součást místní sítě, dostane výjimku pro místní přístup a opustí tunel. V případě adresy serveru je trasa, kterou klient potřebuje k dosažení samotného serveru VPN, mimo tunel, a protivník, který tuto adresu ovládá, může výjimku zneužít.

TunnelVision je samostatná zpráva o beztřídních statických trasách dodávaných přes DHCP. Zlomyslný server DHCP může koncovému zařízení přidělit trasy, které mění cestu provozu, včetně cesty k serveru VPN. Zpráva uznává dřívější práci o souvisejících efektech směrování, což připomíná, že základní mechanismus je starší než jméno.

Držte jména připoutaná k jejich mechanismům. Použití opravy pro jedno proto, že to druhé je ve zprávách, je způsob, jakým prověrka vytváří pohyb bez pokrytí.

Druhý krok: podívejte se na výjimku pro místní přístup

Většina klientů vyjímá provoz místní sítě, aby tiskárny, přenos obrazu a sdílení souborů fungovaly, dokud je tunel aktivní. Tato výjimka je politické rozhodnutí s cenou za bezpečnost: protivník ve stejné síti se může vydávat za místního hostitele a provoz, který k němu dorazí, nikdy nevstoupil do tunelu.

Ptejte se, zda nasazený profil výjimku vůbec potřebuje. Vzdálená pracovní síla, která nikdy nepoužívá místní objevování, ji často může vypnout, a zbývajících místních služeb lze dosáhnout dokumentovanou cestou. Tam, kde je výjimka nutná, uveďte, které cíle pokrývá, místo abyste ji popisovali jako místní provoz.

Kontrola je otázka konfigurace, ne zachytávání paketů. Přečtěte si nastavení profilu a dokumentaci klienta pro verzi, kterou nasazujete, protože výchozí hodnota se liší mezi produkty a mezi verzemi téhož produktu. Napište odpověď vedle profilu, aby ji další kontrolor nemusel odvozovat z chování. Výjimka, kterou nikdo nedokumentoval, je výjimka, kterou nikdo neprověřuje.

Třetí krok: podívejte se, jak se adresa serveru zjišťuje

Klient musí dosáhnout serveru VPN dřív, než existuje jakýkoli tunel, takže tento cíl je ze záměru směrován mimo tunel. Pokud se adresa učí z názvu, krok překladu je součástí cesty důvěry a protivník, který dokáže odpovědět na tento dotaz, může klienta nasměrovat na hostitele, který ovládá.

Připnutí adresy, použití ověřeného certifikátu se správným názvem a odmítnutí spadnout na neověřený server, to vše snižuje expozici. Žádné z nich neodstraňuje potřebu dosáhnout serveru mimo tunel; mění, kdo může za tuto adresu odpovídat.

resolvectl query vpn.lab.example
ip route get 198.51.100.24
ip rule show

Vyhledání trasy ukáže rozhraní, které by klient použil pro adresu serveru, což je výjimka v konkrétní podobě. Pokud toto vyhledání vrátí rozhraní tunelu, klient vůbec nemůže tunel navázat, takže vnější trasa se očekává a otázkou je jen, jak se volí její cíl.

Čtvrtý krok: podívejte se na trasy dodávané přes DHCP

Beztřídní statické trasy umožňují serveru DHCP rozdávat záznamy směrovací tabulky a koncové zařízení je obvykle přijímá bez ptaní. V síti, kde protivník dokáže odpovědět na DHCP rychleji než legitimní server, mohou tyto záznamy přesměrovat provoz, o kterém si uživatel myslí, že je uvnitř tunelu.

Porovnejte trasy na koncovém zařízení s trasami, které očekáváte. Výchozí trasa nebo široký prefix ukazující na místní bránu, zatímco je tunel aktivní, je podpis, který stojí za vyšetření, a je viditelný bez jakéhokoli útočného provozu.

ip route show table all
ip route get 203.0.113.55
nmcli -g ipv4.ignore-auto-routes con show "Wired connection 1"

Poslední nastavení je řízení na straně koncového zařízení, které mnoho klientů a platforem v nějaké podobě nabízí: ignorovat trasy dodané sítí. Vypnutí automatického přijímání tras je kompromis, protože vypíná i legitimní rozdělené směrování od podnikového serveru DHCP, takže o něm rozhodujte podle třídy sítě, ne globálně.

Pátý krok: oddělte sdělení od současné verze

Zveřejněný útok popisuje chování pozorované u určitých verzí klienta v určité době. Nedokazuje, že notebook před vámi je zasažen, a nedokazuje, že je opraven. Obě tvrzení potřebují skutečné číslo sestavení a aktuální sdělení výrobce.

Zaznamenejte verzi klienta, platformu, nastavení profilu, která řídí výjimky výše, a datum, kdy jste to zkontrolovali. Tento záznam stárne poctivě, kdežto poznámka, že VPN byla záplatována kvůli TunnelCracku, nikoli. Znovu si ho přečtěte při každé aktualizaci klienta, protože výchozí hodnota profilu se může změnit pod verzí, které jste se nedotkli.

Když opravdu ověřujete, použijte schválený plán proti vlastnímu koncovému zařízení a neškodnému cíli. Reprodukovat útok proti jiným uživatelům ve sdílené síti není test a vypnutí ověřování protějšku nebo šifrování aplikace, abyste si usnadnili pozorování, odstraňuje ochranu, kterou jste se snažili měřit.

Nakonec držte v obraze ochranu na úrovni aplikace. Výjimka ve směrování může odhalit provoz, který by tunel nesl, a TLS v aplikaci tento provoz stále chrání od konce ke konci. Obě vrstvy selhávají nezávisle, proto připojený řídicí kanál není důkazem, že každý tok šel zamýšlenou cestou.