TunnelCrack gegen TunnelVision: Was jede der beiden Schwachstellen tatsächlich bricht

Zwei Forschungsnamen werden für jeden VPN-Verkehr, der den Tunnel verlässt, synonym verwendet, doch die Mechanismen dahinter sind nicht dieselben. TunnelCrack beschreibt zwei Familien von Routing-Ausnahmen; TunnelVision beschreibt eine per DHCP gelieferte Route auf dem Endpunkt. Keine von beiden bricht die Verschlüsselung, und keine von beiden sagt Ihnen, was ein bestimmter Client-Build heute tut. Fünf Prüfungen trennen die Mechanismen von der Schlagzeile.

Schritt eins: Benennen Sie den Mechanismus, den Sie prüfen

Die Offenlegung von TunnelCrack aus August 2023 beschreibt zwei Angriffsfamilien. Im Fall des lokalen Netzes nimmt Verkehr, den der Client dem lokalen Netz zuordnet, eine Local-Access-Ausnahme und verlässt den Tunnel. Im Fall der Serveradresse liegt die Route, die der Client zum Erreichen des VPN-Servers selbst braucht, außerhalb des Tunnels, und ein Angreifer, der diese Adresse kontrolliert, kann die Ausnahme ausnutzen.

TunnelVision ist ein separater Bericht über klassenlose statische Routen, die per DHCP geliefert werden. Ein böswilliger DHCP-Server kann dem Endpunkt Routen aushändigen, die den Weg des Verkehrs ändern, einschließlich des Wegs zum VPN-Server. Der Bericht erkennt frühere Arbeiten zu verwandten Routing-Effekten an, was daran erinnert, dass der zugrunde liegende Mechanismus älter ist als der Name.

Halten Sie die Namen an ihre Mechanismen gebunden. Eine Korrektur für den einen anzuwenden, weil der andere in den Nachrichten ist, ist die Art, wie eine Prüfung Bewegung ohne Abdeckung erzeugt.

Schritt zwei: Sehen Sie sich die Local-Access-Ausnahme an

Die meisten Clients nehmen lokalen Netzwerkverkehr aus, damit Drucker, Casting und Dateifreigabe weiter funktionieren, während der Tunnel steht. Diese Ausnahme ist eine Richtlinienentscheidung mit Sicherheitskosten: Ein Angreifer im selben Netz kann sich als lokaler Host ausgeben, und der Verkehr, der ihn erreicht, hat den Tunnel nie betreten.

Fragen Sie, ob das eingesetzte Profil die Ausnahme überhaupt braucht. Eine entfernte Belegschaft, die lokale Erkennung nie nutzt, kann sie oft abschalten, und die verbleibenden lokalen Dienste lassen sich über einen dokumentierten Weg erreichen. Wo die Ausnahme erforderlich ist, nennen Sie die Ziele, die sie abdeckt, statt sie als lokalen Verkehr zu beschreiben.

Die Prüfung ist eine Konfigurationsfrage, kein Paketmitschnitt. Lesen Sie die Profileinstellung und die Client-Dokumentation für den Build, den Sie einsetzen, denn der Standard unterscheidet sich zwischen Produkten und zwischen Versionen desselben Produkts. Schreiben Sie die Antwort neben das Profil, damit der nächste Prüfer sie nicht aus dem Verhalten ableiten muss. Eine Ausnahme, die niemand dokumentiert hat, ist eine Ausnahme, die niemand prüft.

Schritt drei: Sehen Sie sich an, wie die Serveradresse gelernt wird

Der Client muss den VPN-Server erreichen, bevor ein Tunnel existiert, also wird dieses Ziel konstruktionsbedingt außerhalb des Tunnels geroutet. Wird die Adresse aus einem Namen gelernt, ist der Auflösungsschritt Teil des Vertrauenspfads, und ein Angreifer, der diese Abfrage beantworten kann, kann den Client auf einen Host lenken, den er kontrolliert.

Das Festnageln der Adresse, die Verwendung eines verifizierten Zertifikats mit dem richtigen Namen und die Weigerung, auf einen unverifizierten Server zurückzufallen, verringern alle die Exposition. Keine davon beseitigt die Notwendigkeit, den Server außerhalb des Tunnels zu erreichen; sie ändern, wer für diese Adresse antworten kann.

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

Die Routensuche zeigt die Schnittstelle, die der Client für die Serveradresse verwenden würde, und das ist die Ausnahme in konkreter Form. Liefert diese Suche die Tunnelschnittstelle, kann der Client den Tunnel gar nicht erst aufbauen, sodass eine äußere Route erwartet wird und die Frage nur ist, wie ihr Ziel gewählt wird.

Schritt vier: Sehen Sie sich die per DHCP gelieferten Routen an

Klassenlose statische Routen erlauben es einem DHCP-Server, Einträge der Routing-Tabelle auszugeben, und der Endpunkt akzeptiert sie in der Regel, ohne zu fragen. In einem Netz, in dem ein Angreifer schneller als der legitime Server auf DHCP antworten kann, können diese Einträge Verkehr umleiten, von dem der Nutzer glaubt, er sei im Tunnel.

Vergleichen Sie die Routen auf dem Endpunkt mit den Routen, die Sie erwarten. Eine Standardroute oder ein breites Präfix, das auf das lokale Gateway zeigt, während der Tunnel steht, ist die Signatur, die eine Untersuchung wert ist, und sie ist ohne jeden Angriffsverkehr sichtbar.

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

Die letzte Einstellung ist die endpunktseitige Kontrolle, die viele Clients und Plattformen in irgendeiner Form anbieten: vom Netz gelieferte Routen ignorieren. Das Abschalten der automatischen Routenannahme ist ein Kompromiss, weil es auch legitimes Split-Routing von einem Unternehmens-DHCP-Server abschaltet, also entscheiden Sie es je Netzklasse statt global.

Schritt fünf: Trennen Sie die Mitteilung vom aktuellen Build

Ein veröffentlichter Angriff beschreibt Verhalten, das an bestimmten Client-Versionen zu einem bestimmten Zeitpunkt beobachtet wurde. Er belegt nicht, dass der Laptop vor Ihnen betroffen ist, und er belegt nicht, dass er behoben ist. Beide Aussagen brauchen die tatsächliche Build-Nummer und die aktuelle Mitteilung des Herstellers.

Notieren Sie die Client-Version, die Plattform, die Profileinstellungen, die die obigen Ausnahmen regeln, und das Datum, an dem Sie geprüft haben. Diese Aufzeichnung altert ehrlich, eine Notiz, die VPN sei gegen TunnelCrack gepatcht worden, dagegen nicht. Lesen Sie sie bei jedem Client-Update erneut, denn ein Profilstandard kann sich unter einer Version ändern, die Sie nicht angefasst haben.

Wenn Sie tatsächlich validieren, verwenden Sie einen genehmigten Plan gegen Ihren eigenen Endpunkt und ein harmloses Ziel. Den Angriff gegen andere Nutzer in einem gemeinsam genutzten Netz zu reproduzieren ist kein Test, und Peer-Verifikation oder Anwendungsverschlüsselung abzuschalten, um eine Beobachtung zu erleichtern, entfernt den Schutz, den Sie messen wollten.

Schließlich halten Sie den Schutz auf Anwendungsebene im Blick. Eine Routing-Ausnahme kann Verkehr offenlegen, den der Tunnel getragen hätte, und TLS in der Anwendung schützt diesen Verkehr weiterhin Ende zu Ende. Die beiden Schichten versagen unabhängig voneinander, weshalb ein verbundener Steuerkanal kein Beweis dafür ist, dass jeder Fluss den beabsichtigten Weg genommen hat.