„TunnelVision“-Angriff macht nahezu alle VPNs anfällig für Spionage

Forscher haben einen Angriff gegen fast alle virtuellen privaten Netzwerkanwendungen entwickelt, der sie dazu zwingt, einen Teil oder den gesamten Datenverkehr außerhalb des verschlüsselten Tunnels zu senden und zu empfangen, um ihn vor Schnüffeln oder Manipulationen zu schützen.

TunnelVision, wie die Forscher ihren Angriff nannten, negiert weitgehend den gesamten Zweck und das Verkaufsargument von VPNs, nämlich den ein- und ausgehenden Internetverkehr in einem verschlüsselten Tunnel zu kapseln und die IP-Adresse des Benutzers zu verschleiern. Die Forscher glauben, dass alle VPN-Anwendungen betroffen sind, wenn sie mit einem feindlichen Netzwerk verbunden sind, und dass es keine Möglichkeit gibt, solche Angriffe zu verhindern, außer wenn das VPN des Benutzers unter Linux oder Android läuft. Sie sagten auch, dass ihre Angriffstechnik möglicherweise seit 2002 möglich sei und seitdem möglicherweise bereits entdeckt und in freier Wildbahn eingesetzt worden sei.

VPN-Verkehr lesen, löschen oder ändern

Der Effekt von TunnelVision besteht darin, dass „der Datenverkehr des Opfers nun enttarnt wird und direkt durch den Angreifer geleitet wird“, a Videodemonstration erklärt. „Der Angreifer kann den durchgesickerten Datenverkehr lesen, löschen oder ändern und das Opfer behält seine Verbindung sowohl zum VPN als auch zum Internet bei.“

Der Angriff funktioniert durch Manipulation des DHCP-Server Dieser vergibt IP-Adressen an Geräte, die versuchen, sich mit dem lokalen Netzwerk zu verbinden. Eine Einstellung namens Option 121 ermöglicht es dem DHCP-Server, Standard-Routing-Regeln außer Kraft zu setzen, die VPN-Verkehr über eine lokale IP-Adresse senden, die den verschlüsselten Tunnel initiiert. Durch die Verwendung von Option 121 zur Weiterleitung des VPN-Verkehrs über den DHCP-Server leitet der Angriff die Daten an den DHCP-Server selbst um. Forscher von Leviathan Security erklärten:

Unsere Technik besteht darin, einen DHCP-Server im selben Netzwerk wie ein Ziel-VPN-Benutzer zu betreiben und unsere DHCP-Konfiguration auch so einzustellen, dass sie sich selbst als Gateway verwendet. Wenn der Datenverkehr unser Gateway erreicht, verwenden wir die Regeln zur Datenverkehrsweiterleitung auf dem DHCP-Server, um den Datenverkehr an ein legitimes Gateway weiterzuleiten, während wir es ausspionieren.

Wir verwenden die DHCP-Option 121, um eine Route in der Routing-Tabelle des VPN-Benutzers festzulegen. Die von uns festgelegte Route ist beliebig und wir können bei Bedarf auch mehrere Routen festlegen. Indem wir Routen weiterleiten, die spezifischer sind als ein /0-CIDR-Bereich, den die meisten VPNs verwenden, können wir Routing-Regeln erstellen, die eine höhere Priorität haben als die Routen für die virtuelle Schnittstelle, die das VPN erstellt. Wir können mehrere /1-Routen festlegen, um die von den meisten VPNs festgelegte Regel 0.0.0.0/0 für den gesamten Datenverkehr wiederherzustellen.

Das Pushen einer Route bedeutet auch, dass der Netzwerkverkehr über dieselbe Schnittstelle wie der DHCP-Server und nicht über die virtuelle Netzwerkschnittstelle gesendet wird. Hierbei handelt es sich um eine beabsichtigte Funktionalität, die im RFC nicht klar angegeben ist. Daher werden die von uns gepushten Routen niemals über die virtuelle Schnittstelle des VPN verschlüsselt, sondern stattdessen über die Netzwerkschnittstelle übertragen, die mit dem DHCP-Server kommuniziert. Als Angreifer können wir auswählen, welche IP-Adressen über den Tunnel und welche über die Netzwerkschnittstelle gehen und mit unserem DHCP-Server kommunizieren.

Der Datenverkehr wird jetzt außerhalb des verschlüsselten VPN-Tunnels übertragen. Diese Technik kann auch für eine bereits bestehende VPN-Verbindung verwendet werden, wenn der Host des VPN-Benutzers eine Lease von unserem DHCP-Server erneuern muss. Wir können dieses Szenario künstlich erzeugen, indem wir im DHCP-Lease eine kurze Lease-Zeit festlegen, sodass der Benutzer seine Routing-Tabelle häufiger aktualisiert. Zudem ist der VPN-Kontrollkanal noch intakt, da er für seine Kommunikation bereits die physikalische Schnittstelle nutzt. Bei unseren Tests meldete das VPN immer weiterhin eine Verbindung und der Kill-Switch wurde nie betätigt, um unsere VPN-Verbindung zu trennen.

Der Angriff kann am effektivsten von einer Person ausgeführt werden, die die administrative Kontrolle über das Netzwerk hat, mit dem sich das Ziel verbindet. In diesem Szenario konfiguriert der Angreifer den DHCP-Server für die Verwendung von Option 121. Es ist auch möglich, dass Personen, die sich als unprivilegierter Benutzer mit dem Netzwerk verbinden können, den Angriff durchführen, indem sie einen eigenen betrügerischen DHCP-Server einrichten.

Durch den Angriff kann ein Teil oder der gesamte Datenverkehr durch den unverschlüsselten Tunnel geleitet werden. In beiden Fällen meldet die VPN-Anwendung, dass alle Daten über die geschützte Verbindung gesendet werden. Jeglicher Datenverkehr, der von diesem Tunnel umgeleitet wird, wird vom VPN nicht verschlüsselt und die für den Remote-Benutzer sichtbare Internet-IP-Adresse gehört zu dem Netzwerk, mit dem der VPN-Benutzer verbunden ist, und nicht zu einem Netzwerk, das von der VPN-App festgelegt wurde.

Interessanterweise ist Android das einzige Betriebssystem, das VPN-Apps vollständig vor dem Angriff schützt, da es Option 121 nicht implementiert. Für alle anderen Betriebssysteme gibt es keine vollständigen Korrekturen. Wenn Apps unter Linux ausgeführt werden, gibt es eine Einstellung, die die Auswirkungen minimiert, aber selbst dann kann TunnelVision verwendet werden, um eine auszunutzen Seitenkanal Dies kann verwendet werden, um den Zielverkehr zu deanonymisieren und gezielte Denial-of-Service-Angriffe durchzuführen. Netzwerk-Firewalls können auch so konfiguriert werden, dass ein- und ausgehender Datenverkehr zur und von der physischen Schnittstelle blockiert wird. Diese Lösung ist aus zwei Gründen problematisch: (1) Ein VPN-Benutzer, der eine Verbindung zu einem nicht vertrauenswürdigen Netzwerk herstellt, hat keine Möglichkeit, die Firewall zu kontrollieren, und (2) es öffnet denselben Seitenkanal, der auch bei der Linux-Abwehr vorhanden ist.

Die effektivsten Lösungen bestehen darin, das VPN in einer virtuellen Maschine auszuführen, deren Netzwerkadapter sich nicht im Bridged-Modus befindet, oder das VPN über das Wi-Fi-Netzwerk eines Mobilfunkgeräts mit dem Internet zu verbinden. Die Studie der Leviathan Security-Forscher Lizzie Moratti und Dani Cronce ist verfügbar Hier.

Diese Geschichte erschien ursprünglich auf Ars Technica.