TunnelCrack mod TunnelVision: hvad hver af dem egentlig bryder

To forskningsnavne bruges i flæng om enhver VPN-trafik, der forlader tunnelen, og mekanismerne bag dem er ikke de samme. TunnelCrack beskriver to familier af routingundtagelser; TunnelVision beskriver en rute, som DHCP leverer på endpointet. Ingen af dem bryder krypteringen, og ingen af dem fortæller dig, hvad en bestemt klientversion gør i dag. Fem kontroller skiller mekanismerne fra overskriften.

Første trin: navngiv den mekanisme, du gennemgår

TunnelCrack-afsløringen fra august 2023 beskriver to angrebsfamilier. I tilfældet med det lokale netværk får trafik, som klienten opfatter som hørende til det lokale netværk, en lokal adgangsundtagelse og forlader tunnelen. I tilfældet med serveradressen ligger den rute, klienten skal bruge for at nå selve VPN-serveren, uden for tunnelen, og en modstander, der kontrollerer den adresse, kan udnytte undtagelsen.

TunnelVision er en separat rapport om klasseløse statiske ruter, som leveres via DHCP. En ondsindet DHCP-server kan give endpointet ruter, der ændrer, hvilken vej trafikken tager, inklusive vejen mod VPN-serveren. Rapporten anerkender tidligere arbejde om beslægtede routingeffekter, hvilket minder om, at den underliggende mekanisme er ældre end navnet.

Hold navnene knyttet til deres mekanismer. At anvende en rettelse for den ene, fordi den anden er i nyhederne, er måden, hvorpå en gennemgang skaber bevægelse uden dækning.

Andet trin: se på undtagelsen for lokal adgang

De fleste klienter undtager trafik på det lokale netværk, så printere, casting og fildeling fortsat virker, mens tunnelen er oppe. Den undtagelse er en politikbeslutning med en sikkerhedsomkostning: en modstander på samme netværk kan optræde som lokal vært, og den trafik, der når den, har aldrig været inde i tunnelen.

Spørg, om den udrullede profil overhovedet har brug for undtagelsen. En fjernarbejdsstyrke, der aldrig bruger lokal opdagelse, kan ofte slå den fra, og de resterende lokale tjenester kan nås ad en dokumenteret vej. Hvor undtagelsen er nødvendig, angiv hvilke destinationer den dækker, i stedet for at beskrive den som lokal trafik.

Kontrollen er et konfigurationsspørgsmål, ikke en pakkefangst. Læs profilindstillingen og klientdokumentationen for den version, du udruller, fordi standarden er forskellig mellem produkter og mellem versioner af samme produkt. Skriv svaret ved siden af profilen, så den næste gennemgåer ikke skal udlede det af adfærd. En undtagelse, som ingen har dokumenteret, er en undtagelse, som ingen gennemgår.

Tredje trin: se på, hvordan serveradressen læres

Klienten skal nå VPN-serveren, før der findes en tunnel, så den destination routes uden for tunnelen efter design. Hvis adressen læres fra et navn, er opløsningstrinnet en del af tillidsstien, og en modstander, der kan besvare den forespørgsel, kan pege klienten mod en vært, vedkommende kontrollerer.

Fastgørelse af adressen, brug af et verificeret certifikat med det korrekte navn og afvisning af at falde tilbage til en uverificeret server reducerer alle eksponeringen. Ingen af dem fjerner behovet for at nå serveren uden for tunnelen; de ændrer, hvem der kan svare for den adresse.

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

Ruteopslaget viser den grænseflade, klienten ville bruge til serveradressen, hvilket er undtagelsen i konkret form. Hvis opslaget returnerer tunnelgrænsefladen, kan klienten slet ikke etablere tunnelen, så en ydre rute er forventet, og spørgsmålet er kun, hvordan dens destination vælges.

Fjerde trin: se på ruter, som DHCP leverer

Klasseløse statiske ruter lader en DHCP-server udlevere poster i routingtabellen, og endpointet accepterer dem normalt uden at spørge. På et netværk, hvor en modstander kan svare på DHCP hurtigere end den legitime server, kan disse poster omdirigere trafik, som brugeren tror er inde i tunnelen.

Sammenlign ruterne på endpointet med de ruter, du forventer. En standardrute eller et bredt præfiks, der peger mod den lokale gateway, mens tunnelen er oppe, er det signatur, der er værd at undersøge, og det er synligt uden nogen angrebstrafik.

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

Den sidste indstilling er styringen på endpoint-siden, som mange klienter og platforme udstiller i en eller anden form: ignorer ruter, som netværket leverer. At slå automatisk ruteaccept fra er en afvejning, fordi det også slår legitim delt routing fra en virksomheds DHCP-server fra, så afgør det per netværksklasse og ikke globalt.

Femte trin: adskil meddelelsen fra den aktuelle version

Et offentliggjort angreb beskriver adfærd observeret på bestemte klientversioner på et bestemt tidspunkt. Det fastslår ikke, at computeren foran dig er påvirket, og det fastslår ikke, at den er rettet. Begge påstande kræver det faktiske buildnummer og leverandørens aktuelle meddelelse.

Noter klientversionen, platformen, de profilindstillinger, der styrer undtagelserne ovenfor, og den dato, du kontrollerede. Den registrering ældes ærligt, mens en note om, at VPN’en blev lappet mod TunnelCrack, ikke gør. Læs den igen, hver gang klienten opdateres, fordi en profilstandard kan ændre sig under en version, du ikke har rørt.

Når du faktisk validerer, brug en godkendt plan mod dit eget endpoint og en harmløs destination. At genskabe angrebet mod andre brugere på et delt netværk er ikke en test, og at slå peer-verifikation eller applikationskryptering fra for at gøre en observation lettere fjerner den beskyttelse, du forsøgte at måle.

Endelig, hold beskyttelse på applikationsniveau i billedet. En routingundtagelse kan blotlægge trafik, som tunnelen ville have båret, og TLS i applikationen beskytter stadig den trafik ende til ende. De to lag fejler uafhængigt, og derfor er en forbundet kontrolkanal ikke bevis for, at hver strøm tog den tilsigtede vej.