TunnelCrack mot TunnelVision: hva hver av dem egentlig bryter

To forskningsnavn brukes om hverandre for all VPN-trafikk som forlater tunnelen, men mekanismene bak dem er ikke de samme. TunnelCrack beskriver to familier av rutingunntak; TunnelVision beskriver en rute som DHCP leverer på endepunktet. Ingen av dem bryter krypteringen, og ingen av dem forteller deg hva en bestemt klientversjon gjør i dag. Fem kontroller skiller mekanismene fra overskriften.

Første trinn: navngi mekanismen du gjennomgår

TunnelCrack-avsløringen fra august 2023 beskriver to angrepsfamilier. I tilfellet med det lokale nettverket får trafikk som klienten anser å høre til det lokale nettverket, et lokalt tilgangsunntak og forlater tunnelen. I tilfellet med serveradressen ligger ruten klienten trenger for å nå selve VPN-serveren, utenfor tunnelen, og en motstander som kontrollerer den adressen, kan utnytte unntaket.

TunnelVision er en egen rapport om klasseløse statiske ruter som leveres av DHCP. En ondsinnet DHCP-server kan gi endepunktet ruter som endrer hvilken vei trafikken tar, inkludert veien mot VPN-serveren. Rapporten anerkjenner tidligere arbeid om beslektede rutingeffekter, noe som minner om at den underliggende mekanismen er eldre enn navnet.

Hold navnene knyttet til mekanismene sine. Å bruke en rettelse for den ene fordi den andre er i nyhetene, er måten en gjennomgang skaper bevegelse uten dekning.

Andre trinn: se på unntaket for lokal tilgang

De fleste klienter unntar trafikk på det lokale nettverket slik at skrivere, kasting og fildeling fortsatt virker mens tunnelen er oppe. Det unntaket er en policybeslutning med en sikkerhetskostnad: en motstander på samme nettverk kan presentere seg som lokal vert, og trafikken som når den, har aldri vært inne i tunnelen.

Spør om den utrullede profilen i det hele tatt trenger unntaket. En fjernarbeidsstyrke som aldri bruker lokal oppdagelse, kan ofte slå det av, og de gjenværende lokale tjenestene kan nås via en dokumentert vei. Der unntaket er nødvendig, oppgi hvilke destinasjoner det dekker i stedet for å beskrive det som lokal trafikk.

Kontrollen er et konfigurasjonsspørsmål, ikke en pakkefangst. Les profilinnstillingen og klientdokumentasjonen for versjonen du ruller ut, fordi standardverdien er forskjellig mellom produkter og mellom versjoner av samme produkt. Skriv svaret ved siden av profilen, slik at neste gjennomgåer ikke må utlede det fra atferd. Et unntak ingen har dokumentert, er et unntak ingen gjennomgår.

Tredje trinn: se på hvordan serveradressen læres

Klienten må nå VPN-serveren før noen tunnel finnes, så den destinasjonen rutes utenfor tunnelen av design. Hvis adressen læres fra et navn, er oppslaget en del av tillitsveien, og en motstander som kan svare på den forespørselen, kan peke klienten mot en vert den kontrollerer.

Å feste adressen, bruke et verifisert sertifikat med riktig navn og nekte å falle tilbake til en uverifisert server reduserer alle eksponeringen. Ingen av dem fjerner behovet for å nå serveren utenfor tunnelen; de endrer hvem som kan svare for den adressen.

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

Ruteoppslaget viser grensesnittet klienten ville brukt for serveradressen, og det er unntaket i konkret form. Hvis oppslaget returnerer tunnelgrensesnittet, kan klienten ikke engang etablere tunnelen, så en ytre rute er forventet, og spørsmålet er bare hvordan dens destinasjon velges.

Fjerde trinn: se på rutene som DHCP leverer

Klasseløse statiske ruter lar en DHCP-server dele ut oppføringer i rutingtabellen, og endepunktet godtar dem vanligvis uten å spørre. På et nettverk der en motstander kan svare på DHCP raskere enn den legitime serveren, kan disse oppføringene omdirigere trafikk som brukeren tror er inne i tunnelen.

Sammenlign rutene på endepunktet med rutene du forventer. En standardrute eller et bredt prefiks som peker mot den lokale gatewayen mens tunnelen er oppe, er signaturen som er verdt å undersøke, og den er synlig uten noen angrepstrafikk.

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

Den siste innstillingen er styringen på endepunktsiden som mange klienter og plattformer eksponerer i en eller annen form: ignorer ruter som nettverket leverer. Å slå av automatisk ruteaksept er en avveining, fordi det også slår av legitim delt ruting fra en bedrifts-DHCP-server, så avgjør det per nettverksklasse og ikke globalt.

Femte trinn: skil varselet fra gjeldende versjon

Et publisert angrep beskriver atferd observert på bestemte klientversjoner på et bestemt tidspunkt. Det fastslår ikke at laptopen foran deg er påvirket, og det fastslår ikke at den er rettet. Begge påstandene krever det faktiske build-nummeret og leverandørens gjeldende varsel.

Noter klientversjonen, plattformen, profilinnstillingene som styrer unntakene ovenfor, og datoen du kontrollerte. Den registreringen eldes ærlig, mens et notat om at VPN-en ble lappet mot TunnelCrack, ikke gjør det. Les det på nytt hver gang klienten oppdateres, fordi en profilstandard kan endres under en versjon du ikke har rørt.

Når du faktisk validerer, bruk en godkjent plan mot ditt eget endepunkt og en ufarlig destinasjon. Å gjenskape angrepet mot andre brukere på et delt nettverk er ikke en test, og å slå av peer-verifisering eller applikasjonskryptering for å gjøre en observasjon enklere, fjerner beskyttelsen du prøvde å måle.

Til slutt, hold beskyttelse på applikasjonsnivå i bildet. Et rutingunntak kan eksponere trafikk som tunnelen ville båret, og TLS i applikasjonen beskytter fortsatt den trafikken ende til ende. De to lagene feiler uavhengig, og derfor er en tilkoblet kontrollkanal ikke bevis for at hver strøm tok den tiltenkte veien.