TunnelCrack mot TunnelVision: vad var och en egentligen bryter

Två forskningsnamn används omväxlande för all VPN-trafik som lämnar tunneln, men mekanismerna bakom dem är inte desamma. TunnelCrack beskriver två familjer av routingundantag; TunnelVision beskriver en väg som DHCP levererar på slutpunkten. Ingen av dem bryter krypteringen, och ingen av dem berättar vad en viss klientversion gör i dag. Fem kontroller skiljer mekanismerna från rubriken.

Första steget: namnge mekanismen du granskar

TunnelCrack-avslöjandet från augusti 2023 beskriver två attackfamiljer. När det gäller det lokala nätverket får trafik som klienten anser höra till det lokala nätverket ett lokalt åtkomständantag och lämnar tunneln. När det gäller serverns adress ligger den väg klienten behöver för att nå själva VPN-servern utanför tunneln, och en motståndare som kontrollerar den adressen kan utnyttja undantaget.

TunnelVision är en separat rapport om klasslösa statiska rutter som DHCP levererar. En illasinnad DHCP-server kan ge slutpunkten rutter som ändrar vilken väg trafiken tar, inklusive vägen mot VPN-servern. Rapporten erkänner tidigare arbete om besläktade routingeffekter, vilket påminner om att den underliggande mekanismen är äldre än namnet.

Håll namnen knutna till sina mekanismer. Att tillämpa en rättelse för den ena eftersom den andra är i nyheterna är hur en granskning skapar rörelse utan täckning.

Andra steget: granska undantaget för lokal åtkomst

De flesta klienter undantar trafik i det lokala nätverket så att skrivare, skärmsändning och fildelning fortsätter fungera medan tunneln är uppe. Det undantaget är ett policybeslut med en säkerhetskostnad: en motståndare i samma nätverk kan presentera sig som lokal värd, och trafiken som når den har aldrig varit inne i tunneln.

Fråga om den utrullade profilen överhuvudtaget behöver undantaget. En distansarbetsstyrka som aldrig använder lokal upptäckt kan ofta stänga av det, och de kvarvarande lokala tjänsterna kan nås via en dokumenterad väg. Där undantaget krävs, ange vilka destinationer det omfattar i stället för att beskriva det som lokal trafik.

Kontrollen är en konfigurationsfråga, inte en paketfångst. Läs profilinställningen och klientdokumentationen för den version du rullar ut, eftersom standardvärdet skiljer sig mellan produkter och mellan versioner av samma produkt. Skriv svaret bredvid profilen, så att nästa granskare inte behöver härleda det från beteendet. Ett undantag som ingen har dokumenterat är ett undantag som ingen granskar.

Tredje steget: granska hur serverns adress lärs in

Klienten måste nå VPN-servern innan någon tunnel finns, så den destinationen routas utanför tunneln av design. Om adressen lärs in från ett namn är uppslaget en del av tillitsbanan, och en motståndare som kan svara på den frågan kan peka klienten mot en värd som den kontrollerar.

Att fästa adressen, använda ett verifierat certifikat med rätt namn och vägra falla tillbaka på en overifierad server minskar alla exponeringen. Ingen av dem tar bort behovet av att nå servern utanför tunneln; de ändrar vem som kan svara för den adressen.

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

Ruttuppslaget visar det gränssnitt som klienten skulle använda för serveradressen, och det är undantaget i konkret form. Om uppslaget returnerar tunnelgränssnittet kan klienten inte ens upprätta tunneln, så en yttre rutt förväntas och frågan är bara hur dess destination väljs.

Fjärde steget: granska rutterna som DHCP levererar

Klasslösa statiska rutter låter en DHCP-server dela ut poster i routingtabellen, och slutpunkten accepterar dem vanligtvis utan att fråga. I ett nätverk där en motståndare kan svara på DHCP snabbare än den legitima servern kan dessa poster omdirigera trafik som användaren tror är inne i tunneln.

Jämför rutterna på slutpunkten med de rutter du förväntar dig. En standardrutt eller ett brett prefix som pekar mot den lokala gatewayen medan tunneln är uppe är signaturen som är värd en undersökning, och den syns utan någon attacktrafik.

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

Den sista inställningen är styrningen på slutpunktssidan som många klienter och plattformar exponerar i någon form: ignorera rutter som nätverket levererar. Att stänga av automatiskt ruttaccepterande är en avvägning, eftersom det också stänger av legitim delad routing från en företags-DHCP-server, så avgör det per nätverksklass och inte globalt.

Femte steget: skilj meddelandet från den aktuella versionen

En publicerad attack beskriver beteende som observerats på vissa klientversioner vid en viss tidpunkt. Den fastställer inte att datorn framför dig är påverkad, och den fastställer inte att den är åtgärdad. Båda påståendena kräver det faktiska buildnumret och leverantörens aktuella besked.

Notera klientversionen, plattformen, de profilinställningar som styr undantagen ovan och datumet du kontrollerade. Den anteckningen åldras ärligt, medan en notering om att VPN:en patchades mot TunnelCrack inte åldras ärligt. Läs den igen varje gång klienten uppdateras, eftersom en profilstandard kan ändras under en version du inte har rört.

När du faktiskt validerar, använd en godkänd plan mot din egen slutpunkt och en ofarlig destination. Att återskapa attacken mot andra användare i ett delat nätverk är inte ett test, och att stänga av peer-verifiering eller applikationskryptering för att göra en observation enklare tar bort det skydd du försökte mäta.

Slutligen, håll skyddet på applikationsnivå i bilden. Ett routingundantag kan exponera trafik som tunneln skulle ha burit, och TLS i applikationen skyddar fortfarande den trafiken från ände till ände. De två lagren misslyckas oberoende av varandra, och därför är en ansluten kontrollkanal inte bevis för att varje flöde tog den avsedda vägen.