Sicherheitsforscher haben eine neue, als TunnelVision bezeichnete Angriffsmethode auf VPN-Verbindungen offen gelegt. Der Angriff ermöglicht es, einen Teil oder den gesamten Datenverkehr durch den unverschlüsselten Tunnel zu leiten. In beiden Fällen meldet die VPN-Anwendung, dass alle Daten über die geschützte Verbindung gesendet werden. Lediglich unter Android sind die VPN-Verbindungen geschützt, weil das Betriebssystem diese schützt.
Anzeige
Die Schwachstelle (CVE-2024-3661) wurde von Leviathan Security vor kurzem entdeckt , wie sie im Beitrag TunnelVision (CVE-2024-3661): How Attackers Can Decloak Routing-Based VPNs For a Total VPN Leak schreiben. Nachfolgender Tweet weist auf diesen Sachverhalt hin.
Die Schwachstelle CVE-2024-3661 lässt sich von Angreifern, die Kontrolle über ein Netzwerk haben, nutzen, um den Datenverkehr eines Zielbenutzers aus seinem VPN-Tunnel zu verdrängen. Die Angriffstechnik nutzt die Funktionen des DHCP (Dynamic Host Configuration Protocol), um den VPN-Tunnel aufzubrechen.
Die VPN-Verbindung meldet zwar, dass die Datenpakete über den VPN-Tunnel vermeintlich gesichert übertragen werden. Durch die DHCP-Manipulation werden jedoch Datenpakete übertragen, die nie von einem VPN verschlüsselt werden, schreiben die Entdecker. Ein Angreifer kann so den gesamten Datenverkehr der vermeintlich sicheren VPN-Verbindung ausspähen. Wichtig sie, so schreiben die Entdecker, dass der VPN-Kontrollkanal beibehalten wird, so dass Funktionen wie Kill Switches nie ausgelöst werden und die Benutzer in allen beobachteten Fällen weiterhin als mit einem VPN verbunden angezeigt werden.
Anzeige
Die Sicherheitsforscher glauben, dass diese Angriffstechnik bereits 2002 möglich war, bereits von Dritten entdeckt und möglicherweise in freier Wildbahn eingesetzt wurde. Aus diesem Grund informieren die Sicherheitsforscher die Öffentlichkeit über das Problem, da die Benachrichtigung aller VPN-Anbieter, Betriebssystem-Betreuer, selbst gehosteten VPN-Administratoren und VPN-Benutzer die Kapazitäten des kleinen Leviathan Security-Forschungsteams bei weitem übersteigt.
In ihrem Beitrag schreiben die Sicherheitsforscher, dass sie eine Entschärfung für diese Technik gesehen und einen Fix auf Linux-basierten Betriebssystemen identifiziert haben. Problem dieser Entschärfung ist aber, dass es trotzdem möglich ist, einen Seitenkanal für die Deanonymisierung des Datenverkehrs durch Verkehrsanalyse genutzt werden könnte. An manchen Orten der Welt könnte allein der Seitenkanal zu Gefängnisstrafen oder zum Tod von Personen führen, die sich aus Sicherheitsgründen auf VPNs verlassen. Hier werden z. B. Journalisten oder Informanten genannt, die häufig Ziel von Überwachung oder Spionageprogrammen sind. Voraussetzungen zur Enttarnung der VPN-Daten:
- Der anvisierte Host muss einen DHCP-Lease von dem vom Angreifer kontrollierten Server akzeptieren.
- Der DHCP-Client des Zielhosts muss die DHCP-Option 121 implementieren (daher ist Android auch gegen den Angriff sicher).
Details zur Angriffsmethode sind dem verlinkten Beitrag zu entnehmen. Ein YouTube-Video, welches den Angriff demonstriert, findet sich hier.
Anzeige
So wie ich das verstehe betrifft dieses Problem hauptsächlich Nutzer, die entweder einen VPN-Anbieter verwenden bzw. ein VPN hauptsächlich zur "Verschleierung" der Quelle nutzen, oder? Weil durch diese Methode wird ja der Traffic, der eigentlich durch den VPN gehen soll, ja auf der physischen NIC direkt ausgeworfen und somit unverschlüsselt übertragen.
Für "normales" Firmen-VPN (also User verbindet sich mit dem VPN-Server der Firma, um aus der Ferne auf Ressourcen innerhalb dieser zuzugreifen) würde das nichts bringen, da die gewünschte Ressource ja nicht direkt per Internet erreichbar ist. Oder mache ich hier einen Denkfehler?
>>> Oder mache ich hier einen Denkfehler?
Ja – weil Firmen-VPNs meist ganz bewusst sämtlichen Traffic durch den Tunnel leiten damit dieser durch die Firmen Firewall durch muss, bevor es raus geht ins weite Netz. Das würde dann hier verhindert. Jetzt hängt es nur noch davon ab, wie das betrügerische Gateway gestaltet ist um etwas abgreifen zu können. Sehe das also primär als Problem für sehr gezielte Angriffe auf klar definierte Einzelpersonen.
Für den Massenmarkt ist das nix. Ob Hänschen gerade Erwachsenenseiten aus dem Hotel WLAN aufruft wird Niemanden interessieren und wenn Hans nicht mehr auf seine Firmenserver drauf kommt, bemerkt er dass innerhalb von Minuten.
Ob es dem Betreiber des komprimierten Netzwerks auffällt oder nicht, ist so eine Sache von Rate mal mit Rosenthal…
Entweder habe ich das schlecht ausgedrückt oder du hast mich missverstanden. Das hier Traffic Richtung Internet ausgeleitet werden kann ist mir klar. Aber zumindest bei uns ist es so, dass die Mitarbeiter das VPN nutzen, wenn sie von extern auf interne Ressourcen zugreifen wollen/müssen. Das wäre dann ja nicht erreichbar. Und das ist denke ich bei den meisten Firmen so, oder verbinden sich bei euch die Mitarbeiter zum Surfen mit dem VPN?
Somit sehe ich hier die Angriffsfläche immer noch eher bei den kommerziellen Anbietern.
Das Problem betrifft niemanden (zuhause). Das dir jemand einen 2ten DHCP-Server im Heim-LAN unterjubelt wäre maximales Versagen des Sysadmins. Das kann nur Unterwegs in einem sehr sehr schlechten Hotelnetz passieren. Wenn wirklich die Zimmer nicht voneinander isoliert im Netz sind und jemand einen 2ten Router aufstellt der deinen PC mit dem VPN mit einem bösartigen 2ten DHCP-Host als Client per Lease übernimmt.
tl;dr: Sicherheitsforscher haben einen neuen Angriff gefunden, bei dem ich den Angreifer selbst reinlasses muss. LOL!
Mit der DHCP-Option 121 können dem DHCP-Client statische Routen mitgegeben werden (RFC 3442). Die Idee von TunnelVision ist, dem Client statische Routen für bestimmte Netze per DHCP zu verpassen, damit diese nicht durch den VPN-Tunnel laufen, sondern an ein vorgegebenes Gateway gehen. Oder wie Netzwerker sagen: the more specific route wins.
Ich verstehe das Problem im Moment noch nicht.
Daten mitlesen, umleiten zu können, heisst ja nicht die Verschlüsselung zu brechen.
Das ich mich kurzfristig auf GanzschlimmeKinderPornos.com verbunden habe könnte ein Popup auf Youporn verursacht haben.
Wenn die Daten nicht über den VPN-Adapter rausgehen, wird auch nichts verschlüsselt.
Ist das so? Wenn das Ziel z.B. die Google-Suche war, was passiert dann?
A) Ich werde zum echten Google geleitet und das sieht der Angreifer. Dann greift aber die Verschlüsselung mittels TLS. Somit kommen beim Angreifer nur verschlüsselte Daten durch.
B) Er leitet mich nicht zum echten Google, wofür noch zusätzlich DNS manipuliert werden müsste oder er versucht sich als MITM. Das wirft zumindest Fragen bzgl. des TLS Zertifikats auf. Der Angreifer benötigt dann ein Google Zertifikat, welchem von meinem Client vertraut wird. Sonst meckert der Browser.
C) Ich möchte meine aktuellen Produktionszahlen von einem interen Webserver in der Firma abrufen, welcher keine Verschlüsselung verwendet (plain http). Das klappt nicht, weil der Client den Server nicht erreicht, wenn die Verbindung aus dem VPN gelöst wird.
Auf den ersten Blick wären für mich nur unverschlüsselte Seiten im Internet mitlesbar, welche eigentlich durch den VPN geladen werden sollen. Zusätzlich Metadaten, aber keine Inhalte. Andere Ansichten?
Verschlüsselte Verbindung sind natürlich nicht betroffen. Alles was unverschlüsselt ist schon. Korrekt.
Witzig, dass hier ausgerechnet Android als sicher benannt wird.
Ist es doch Google, die ein paar ihrer Services absichtlich am VPN vorbei routen und darin auch keinerlei Sicherheitsprobleme erkennen können/wollen.
Bei Google-Androids braucht es also kein 121er DHCP um Traffic zu leaken.
Das finde ich jetzt nicht so toll.
Hoffe, das wird irgendwie gelöst.
Ab jetzt also immer ein eigener Router dazwischen schalten.
…oder schlicht auf DHCP verzichten, manuell konfigurieren.
Natürlich ist es weit besser (nicht nur wegen dieses Angriffes), sich nie ohne zwischengeschaltete Firewall (so ein Router ist Eine, eine "NAT-Firewall") mit einem fremden (nicht vertrauenswürdigen) Netz zu verbinden.
Und jetzt erklär mir, wie man das in einem Hotel machen würde. Glaube kaum, dass du einen eigenen Router an deren Gast WLAN angemeldet bekommst. Und manuell IPs vergeben ist da auch nicht unbedingt möglich.
Bleibt also effektiv nur die Möglichkeit mit dem Handy als Hotspot (was dann i.d.R. Datenvolumen kostet) anstatt das Hotel WLAN zu benutzen.
Was für ein Quatsch!
Man nutzt einen kleinen Reiserouter* (der Suchbegriff ist "WISP-Router", die Chinesen nennen es völlig falsch aber oft "Repeater"), der verbindet sich mit dem Anbieter-LAN oder mit den bekanntgebenen Zugangsdaten (SSID + Passwort) ins PublicWLAN (z.B. Hotel) und spannt ein eigenes, separates (W)LAN auf.
Dann muss man maximal noch die Landingpage überwinden, das kann man bereits mit Handy/Laptop (am RR angemeldet).
Et voila!
P.S. Wer Sorge hat, dass der lokale Anbieter keine Router duldet kann die MAC-Adresse seines eigenen Handys/Laptos auf den RR clonen oder eine beliebige Andere setzen.
P.P.S. Die GL-Inets bieten sogar integrierte VPNclients (OpenVPN + Wireguard), so dass man auch die Inhalte seines Datenverkehrs verbergen kann.
* z.B. GL-Inet hat Gute und recht Preiswerte auf OpenWRT-Basis und mit LuCI (aber mit aufgepfropfter DAU-GUI), laufen am Netzteil oder einer Powerbank
Noch zur FixIP:
Auch das ist simpel (schützt aber nur vor diesem Angriff, nicht vor Würmern etc.). Man holt sich eine Adresse per DHCP und konfiguriert deren Daten (IP/Netzmaske/Gateway/DNS) als FixIP.
Mindestens für die Leasetime funktioniert das problemlos, oft deutlich länger (DHCP-Server vergeben zugewiesene Adressen idR erst bei Adressnot (keine nicht-zugewiesenen Adressen mehr verfügbar) neu, dann beginnend mit dem ältesten inaktiven Lease).
Nunja wenn jemand im Hotel eine VK macht und dann über sage ich mal "Waffen" redet…. und zufällig jemand anderes in "guter" Absicht dieses ausnutzt… kann man auch dieses in den Nachrichten lesen…….. aber das war bestimmt eine andere "Lücke" ;)
HOFFE ich ZUMINDEST :)
Es wurde ein ganz anderer Angriffsvektor kolportiert: Der Kamerad soll mit einem privaten Mobiltelefon per Anruf an der Konferenz teilgenommen haben.