Sicherheitsproblem: TunnelVision umgeht den VPN-Tunnel

Ein VPN-Tunnel dient entweder als sichere Verbindung zwischen zwei Netzwerken oder zur Anonymisierung der eigenen Internetnutzung. Die Daten im VPN-Tunnel sind verschlüsselt und bleiben neugierigen Blicken verborgen. Es sei denn der lokale DHCP-Server nutzt die im Jahr 2002 eingeführte Option 121, um ein abweichendes IP-Routing vorzugeben. Dann fließen die Daten am VPN-Tunnel vorbei und der VPN-Client bekommt davon absolut nichts mit.

Wo genau liegt das Sicherheitsproblem?
TunnelVision ist keine Sicherheitslücke im eigentlichen Sinne. Was die Forscher von Leviathan Security entdeckt haben, ist vielmehr eine Methode, wie man legitime Netzwerkfunktionen auf bösartige Weise missbrauchen kann, um VPN-Tunnel weitgehend auszuhebeln. Dazu benötigt man die Kontrolle über einen DHCP-Server im lokalen Netzwerk, welcher den angeschlossenen Netzwerkgeräten über die Option 121 Vorgaben zum klassenlosen Routing macht. Diese IP-Routen, welche vom Betriebssystem für das physische Netzwerkgerät gesetzt werden, haben eine höhere Priorität als die Routen für die virtuelle Netzwerkschnittstelle des VPN. Die Netzwerkdaten fließen somit nicht mehr über die virtuelle Netzwerkschnittstelle des VPN, welche die Verschlüsselung vornimmt, sondern werden unverschlüsselt über den physischen Netzwerkadapter zum DHCP-Server geleitet. Derweil bleibt der VPN-Kontrollkanal intakt, so dass ein sicherer VPN-Status angezeigt wird und auch Sicherheitsfunktionen wie ein erzwungener Verbindungsabbruch (Kill Switch) ins Leere laufen.

Hintergründe: DHCP und die Option 121
Damit sich Netzwerkgeräte miteinander unterhalten können, sieht das Internet Protocol (IP) eindeutige Adressen vor. Diese werden im Lokalen Netzwerk (LAN) vom Router vergeben, wahlweise über eine dedizierte Zuweisung oder automatisiert per Dynamic Host Configuration Protocol (DHCP). Während es bei einem Gerät mit Serverdiensten (NAS, Drucker) empfehlenswert ist, eine feste IP-Adresse zu vergeben, reicht für Clients eine dynamische IP voll und ganz aus. Die Adressverwaltung per DHCP verringert den Verwaltungsaufwand und ermöglicht es zudem, mehr Geräte im LAN unterzubringen, als Adressen zur Verfügung stehen. Die dynamischen Adressen sind hierzu mit einer Verfallszeit (Lease Time) ausgestattet und werden nach deren Ablauf neu vergeben. Ende 2002 wurde DHCP um die Option 121 (The Classless Static Route Option for Dynamic Host Configuration Protocol (DHCP) version 4) erweitert, welche zugleich die Option 33 in RFC 2132 für statische DHCP-Routen (Classful Routing) ersetzt.

Diese Änderung machte durchaus Sinn, denn das klassische Routing war im Jahr 2002 schon lange veraltet. Beim klassischen Routing (Classful Routing) besteht eine Adresse aus drei Teilen: Netzwerk, Subnetz und Host. Die maximale Größe eines Netzes wurde direkt aus der Netzwerknummer abgeleitet, wobei es fünf Netzklassen (A bis E) mit maximal 16.777.214, 65.534 oder 254 Hosts gab. Schon im Jahr 1993 hatte sich gezeigt, dass dieses System viel zu unflexibel war und eine effiziente Zuteilung von Adressbereichen verhinderte. Die Lösung hieß klassenloses Routing (Classless Routing) und ergänzte die Adresse um eine Subnetzmaske für jeden Eintrag. Das klassenlose Routing brachte VLMS (Variable Length Subnet Mask) und CIDR (Classless Inter-Domain Routing). Doch warum wird der Routing-Table über DHCP aktualisiert? Weil es bequem ist. In den meisten Netzwerken des Jahres 2002 lief bereits ein DHCP-Dienst und schickte regelmäßig Mitteilungen an die Clients im lokalen Netzwerk. Dass dieser nicht nur die IP-Adressen verwaltet, sondern sich auch um das Routing kümmert, macht durchaus Sinn.

Rogue DHCP-Server: Der Feind in Deinem Netz
Wenn sich ein Gerät in einem Netzwerk anmelden möchte, schickt es blind ein DHCPDISCOVER-Paket an das gesamte lokale Subnetz. Während alle anderen Netzwerkgeräte diese Anfrage ignorieren (sollten), nimmt der DHCP-Server diese zur Kenntnis und antwortet mit einem DHCPOFFER-Paket. Mit diesem Paket stellt sich der DHCP-Server vor und übermittelt auch die Optionen, darunter Routing-Vorgaben gemäß Option 121. Wenn alles perfekt läuft, bekommt der neue Client nur ein Angebot und nimmt dieses inklusive der enthaltenen Vorgaben an. Sollten sich mehrere DHCP-Server melden, muss der Client eine Auswahl treffen. In der Regel wird er den Server vorziehen, der sich zuerst gemeldet hat. Doch warum sollten sich mehrere DHCP-Server im selben LAN befinden?

Nun, jeder, der Zugriff auf das LAN hat, kann dort auch einen DHCP-Server bereitstellen. Dies geschieht normalerweise aus bösen Absichten und ist ein Problem, da das DHCP-Konstrukt auf Vertrauen basiert. Wurde ein DHCP-Server erst einmal akzeptiert, wird der Client zukünftige Anfragen direkt an diesen adressieren. Will sich der Angreifer nicht auf ein Wettrennen mit dem echten DHCP-Server einlassen, kann er versuchen, alle verfügbaren IP-Adressen des Servers zu binden, so dass dieser keine freien Kapazitäten mehr hat. Ein DHCPOFFER-Paket für neue Clients kommt somit nur noch vom Rogue DHCP-Server. Weiterhin wäre es möglich, die Client-Anfragen zur Verlängerung der Nutzungszeit (Lease Renewing) mit Hilfe von ARP-Spoofing abzufangen.

Unbemerkt am VPN-Tunnel vorbei
Wenn eine VPN-Software gestartet wird, kontaktiert diese den VPN-Server über den physische Netzwerkadapter (und den Routing-Vorgaben gemäß Option 121) und etabliert einen VPN-Kontrollkanal. Dann wird eine virtuelle Netzwerkschnittstelle erzeugt und ein Routing-Eintrag wie 0.0.0.0\0 angelegt, um praktisch alle Anfragen über diese virtuelle Netzwerkschnittstelle durch den verschlüsselten VPN-Tunnel zu leiten. Bei der Zahl hinter dem Schrägstrich handelt es sich um den Präfix und in einer Routing-Tabelle werden standardmäßig jene Einträge priorisiert, welche hier den höchsten Wert haben. Leviathan Security hat über die DHCP-Option 121 zwei Einträge (0.0.0.0\1 und 128.0.0.0\1) höherer Priorität gesetzt und damit die virtuelle Netzwerkschnittstelle des VPN vollständig umgangen. Die VPN-Software bekommt hiervon nichts mit, denn die direkte Kommunikation zwischen dem VPN-Client und dem VPN-Server läuft ja über den physischen Netzadapter.

Was kann man tun?
Hier wird es kompliziert, denn die beste Empfehlung lautet, sich ausschließlich mit sicheren Netzwerken zu verbinden. Doch wir nutzen VPN-Tunnel ja insbesondere in jenen Netzwerken, denen wir nicht vollständig vertrauen. Unter Linux ist es zudem möglich, den Datenverkehr gar nicht über Routing-Tabellen sondern über sogenannte Namespaces zu leiten. In der Dokumentation von Wireguard findet sich ein Beispiel, wie sich so etwas umsetzen lässt. Das hilft allerdings unter Windows, macOS oder iOS nicht weiter.

Einzig Android unterstützt die DHCP-Option 121 nicht und ist damit von Hause aus sicher. Damit stellt sich die Frage, ob man die DHCP-Option 121 nicht auch auf anderen Betriebssystemen deaktivieren kann. In Netzwerken, die diese Option verwenden, wird ein generelles Deaktivieren allerdings neue Probleme verursachen. Werden die physischen Netzwerkadapter per Firewall auf die IP-Adressen der DHCP- und VPN-Server beschränkt, kann man zwar das Umgehen des VPN-Tunnels unterbinden, eröffnet aber Seitenkanalangriffe zur Offenlegung der Zieladressen.

Bleibt noch die Möglichkeit, VPN-Verbindungen über eine Virtuelle Maschine herzustellen. Dabei darf der virtuelle Netzwerkadapter allerdings nicht im gebrückten Modus laufen, weil er dann eine IP-Adresse nebst weiterer Optionen beim DHCP-Server anfragen würde. Weiterhin könnte man ein Smartphone als mobilen Wifi-Hotspot verwenden. In diesem Fall kontrolliert das Smartphone das Netzwerk inklusive DHCP, so dass man sein eigenes, vertrauenswürdiges LAN mit sich trägt. Das kann als Notlösung funktionieren, ist aber nicht wirklich praxistauglich.

Sofern man VPN nicht zum Anonymisieren verwendet, sondern auf ein bekanntes Netzwerk zugreifen will, kann man sich die Präfix-Priorisierung zu Nutze machen. Verwendet das Zielnetzwerk beispielsweise den Adressbereich zwischen 192.168.2.1 und 192.168.2.254, würde ein Eintrag für 192.168.2.0/24 in der Routing-Tabelle sehr spezifisch sein und somit eine sehr hohe Priorität genießen.