"Tunnelvision": Neuer Angriff knackt fast alle VPNs

Loreas

Member

IT-SECURITY​

"Tunnelvision": Neuer Angriff knackt fast alle VPNs​

Die von Forschern demonstrierte Attacke setzt auf eine Schwachstelle, die schon seit 2002 existiert

Virtual Private Networks (VPNs) ermöglichen einen digitalen Ortswechsel und können auch zum Schutz der Privatsphäre beitragen. Letzteres freilich nur, wenn man weiß, dass man dem VPN-Anbieter auch vertrauen kann. Forscher von Leviathan Security haben nun allerdings einen Angriff demonstriert, der die große Stärke von VPNs – den Datenverkehr des Nutzers über eine verschlüsselte Verbindung zu führen und seine IP-Adresse zu verstecken – aushebelt.
Die Attacke haben die Wissenschafter Tunnelvision getauft. Sie betrifft fast alle VPNs und setzt auf eine seit 22 Jahren existierende Lücke. Die Implikationen sind beachtlich, schreibt Ars Technica.

Option 121​

Zur Durchführung muss ein Angreifer einen DHCP-Server am gleichen Netzwerk betreiben, in dem sich sein Opfer befindet. Besagter Server ist dafür zuständig, die IP-Adressen innerhalb dieses Netzwerks zu vergeben. Bei der Verwendung eines VPNs durch einen Teilnehmer würde dessen Datenverkehr zunächst über eine lokale IP-Adresse laufen, über die der VPN-Tunnel initiiert wird. Eine Einstellung, bekannt unter dem Namen Option 121, ermöglicht es dem DHCP-Server aber, die Standard-Routing-Regeln auszuhebeln und zumindest einen Teil des VPN-Datenverkehrs stattdessen über sich selbst als Gateway laufen zu lassen.
157a7c6e-7f4e-4e1a-a672-2ded2d5f90b2.jpeg
Auch nicht privilegierte Nutzer mit Zugang zum Netzwerk können mittels eines bösartigen DHCP-Servers einen "Tunnelvision"-Angriff durchführen.IMAGO/imageBROKER/Paul Hartl
Sämtlicher Traffic, der auf diesem Wege am VPN-Tunnel vorbeigeschleust wird, wird nicht mehr VPN-seitig verschlüsselt (bestehende Verschlüsselung, etwa via TLS, ist nicht beeinträchtigt) und gibt auch die eigentliche IP-Adresse des jeweiligen Nutzers preis. Für die Betroffenen ist die Attacke nicht ersichtlich. Weil die Verbindung am Ende immer noch über den gleichen physischen Netzwerkanschluss läuft, erkennen VPN-Apps die Umleitung nicht und melden weiter eine sichere VPN-Verbindung. Es ist auch möglich, auf diese Weise eine schon bestehende VPN-Verbindung zu kapern, sobald deren Host den DHCP-Lease – also die Reservierung einer IP-Adresse – erneuert. Dies lässt sich beschleunigen, da der DHCP-Server vorgibt, wie lange ein solcher Lease gültig ist.
Besonders einfach ausführbar ist der Angriff für alle, die administrative Kontrolle über das jeweilige Netzwerk haben. Allerdings ist es auch Usern ohne spezielle Rechte möglich, einen bösartigen DHCP-Server aufzusetzen, sobald sie mit dem Netzwerk verbunden sind.

Alte Schwachstelle​

Die Option-121-Schwachstelle existiert seit dem Jahr 2002. Laut den Leviathan-Forschern ist es durchaus möglich, dass dieses Problem seitdem auch schon entdeckt und von Angreifern ausgenutzt wurde. Betroffen sind alle bekannteren Betriebssysteme in unterschiedlichem Umfang. Die einzige Ausnahme ist Googles Android. Hier wurde Option 121 schlicht nie implementiert.
Wer sich schützen will, hat laut den Experten zwei Optionen. Einerseits kann man VPN über eine virtuelle Maschine nutzen, deren Netzwerkadapter nicht im Bridgemodus läuft, oder man verbindet sich über das WLAN (Hotspot) eines Geräts mit mobilem Internetzugang. In beiden Szenarien soll ein Tunnelvision-Angriff nicht möglich sein. Eine umfassende Beschreibung des Problems hat Leviathan auf seinem Blog veröffentlicht.
 
Typisch klatsch und tratsch Presse, die wichtigen Informationen lassen die weg:

...Einen Entwurf einer Methode zur Absicherung von DHCP hat 1997 der damalige Intel-Mitarbeiter Baiju V. Patel vorgeschlagen, doch ist daraus nichts geworden...
...VPN-Anbieter können auf zusätzliche technische Maßnahmen zurückgreifen, um ihre Kunden zu schützen....
...Dabei geben die beiden Forscher zu, dass Tunnelvision nicht unbedingt als Sicherheitslücke gesehen werden muss. Schließlich beruht der Angriff auf einer Option, die so funktioniert, wie sie designt worden ist...

Fazit: Es wurde vorsätzlich eine Sicherheitslücke integriert. Und die Möglichkeit, das zu schließen wurde verweigert. Und ich bin mir sicher, in unzähligen anderen Standarts gibt es ebenfalls lücken (hat man ja sogar bei "Sicherer Verschlüsselung" gefunden. Und es gibt auch böse Gerüchte über den MS-Bitlocker). Und ich bin mir sicher, es wird auch in Zukunft (vielleicht besser versteckte) Lücken geben damit man alles ausspionieren kann.

edit: Es wäre sogar noch seriöser gewesen, wenn man die getesteten VPNs aufgelistet hätte und wer verwundbar ist und wer nicht. Muss da an TunnelCrack denken.
 
Ich wollts nur als FYI posten. Ich glaube da hat es in der Vergangenheit schon mal was zu Option ### gegeben.
 
  • Like
Reactions: Nul
Thx, war ja auch nicht gegen dich oder so, sondern was ich seit vielen Jahren kritisiere. Der Interessante Teil wird einfach als nicht-existend totgeschwiegen (wie oft höre/lese/sehe ich Nachrichten und frage mich "Ja, was ist jetzt mit dem ganzen wichten Rest?" aber das ist ein anderes Thema.

Mal schauen, was das PP-Team dazu sagt.
 
Ist halt blöd, da so was kurz vor Feiertag + für manche verlängertest Wochenende passiert. Da müssen wir uns nicht wundern, wenn die Antwort nicht in 20 Minuten kommt -__-
 
Ist halt blöd, da so was kurz vor Feiertag + für manche verlängertest Wochenende passiert. Da müssen wir uns nicht wundern, wenn die Antwort nicht in 20 Minuten kommt -__-
Seit 2002, da macht ein verlängertes Wochenende doch kein unterschied mehr, oder?
 
Wir werden jetzt alle gehackt aufgrund einer Option und einem Feiertag inkl verlängertem Wochenende. Schon scheisse so eine Kausalkette.


JOKE 😆
 
The most effective fixes are to run the VPN inside of a virtual machine whose network adapter isn’t in bridged mode or to connect the VPN to the Internet through the Wi-Fi network of a cellular device.
 
Sind wir betroffen? Bitte um Rückmeldung. Danke
Also, ich hab mit Lars darüber gesprochen und die Gefahr davon ist nicht so groß. Der Angreifer muss im selben Netz sein, so dass er DHCP spielen kann. Bei IPv6 ist das noch einfacher, da kann man einfach Routing Advertisement senden, und schon hat jemand eine andere Routing Table. Für IPv6 blockieren wir das deshalb auch. Bei IPv4 kann man diesen Angriff aber theoretisch durchführen, aber auch nicht so einfach, dafür muss man bei unserem Client/Firewalling immerhin die IP-Range raten die man vom Server bekommt, sonst ist das gefirewalled. Aber ja, theoretisch geht der Angriff bei uns auch, aber nur eingeschränkt, wegen firewalling. Lars baut gerade ein Update für den Client , das das komplett dicht macht. Das Update kommt so schnell wie möglich.
 
Also, ich hab mit Lars darüber gesprochen und die Gefahr davon ist nicht so groß. Der Angreifer muss im selben Netz sein, so dass er DHCP spielen kann. Bei IPv6 ist das noch einfacher, da kann man einfach Routing Advertisement senden, und schon hat jemand eine andere Routing Table. Für IPv6 blockieren wir das deshalb auch. Bei IPv4 kann man diesen Angriff aber theoretisch durchführen, aber auch nicht so einfach, dafür muss man bei unserem Client/Firewalling immerhin die IP-Range raten die man vom Server bekommt, sonst ist das gefirewalled. Aber ja, theoretisch geht der Angriff bei uns auch, aber nur eingeschränkt, wegen firewalling. Lars baut gerade ein Update für den Client , das das komplett dicht macht. Das Update kommt so schnell wie möglich.
Also, kurz gesagt: IPv6 nein. IPv4 praktisch auch nein; außer man kennt die dynamische ip-range (die man im alten Clienten sehen kann?). Normal funktioniert dieser Angriff ebenfalls nicht. Richtig so?

edit: Der Angreifer müsste interna der Server/Struktur kennen oder erraten können was die Anzahl möglicher Angreifer stark einschränkt ^^
 
Naja, ich hab auch einen Nachbarn (IT-ler - lol) der auf einen Trojaner reingefallen ist und fast 5000€ verloren hätte.
Wenn man nicht weiß was man tut, kann das immer passieren.
Also wenn ich in einem mir unbekannten Ort in's Netz gehe und dann ein VPN starte, dann gucke ich erstmal was
Code:
ip -4 rule show
ip -6 rule show
ip -4 route show
ip -6 route show
mir sagt. Dann ist es sofort offensichtlich, wenn einer versucht, was am Tunnel vorbei zu routen.
Aber sowas wissen die heutigen "Internet-Natives" ja nicht mehr - geht ja auch auf nem Handy nicht so einfach...
 
Back
Top