In einem aktuellen Internet-Draft (draft-ietf-opsec-vpn-leakages-02) beschreibt Fernando Gont Gefahren, die von VPN-Software ausgeht, welche nicht IPv6-fähig ist. Eine Zusammenfassung:
Führen Organisationen IPv6 auf ihren Client-Systemen ein, ist die bevorzugte Strategie in der Regel die, dass IPv6-Konnektivität zusätzlich zur bestehenden IPv4-Anbindung hergestellt wird (“Dual Stack”). Wenn diese Clients sich nun per VPN mit dem nächsten Office-Standort verbinden, sei es z.B. vom Home-Office oder Kunden aus, dann sollte die Verbindung über diese VPN-Schicht für eine verschlüsselte Datenübertragung sorgen.
Das Problem ist nun, dass heute nicht alle VPN-Clients IPv6-fähig und für das Dual-Stack-Szenario gerüstet sind. Sie kennen vereinfacht gesagt kein IPv6. Wenn nun eine VPN-Verbindung aufgebaut wird, kümmern sich diese VPN-Clients wie gewohnt um den IPv4-Traffic, z.B. indem sie die Default Route ändern um den Traffic in den VPN-Tunnel zu leiten. IPv6-Traffic wird aber weiterhin über die normalen IPv6-Routen geleitet und bleibt damit von der VPN-Verschlüsselung ausgenommen. Integrität und Vertraulichkeit der möglicherweise sensiblen Daten ist dadurch nicht mehr gewährleistet.
Voraussetzungen für dieses Szenario sind, dass a) die Verbindung zum Zielsystem über einen Hostnamen aufgebaut wird, für den das DNS auch eine IPv6-Adresse liefert (AAAA DNS resource record) und b) das Zielsystem auch am VPN-Tunnel vorbei erreichbar ist.
Auch im IPv4-only Netz…
Auch im IPv4-only-Netzwerk kann das Verwenden von IPv4-only-VPN-Clients von einem lokalen Angreifer ausgenutzt werden. Durch Versenden von gefälschten Router Advertisements kann dieser gezielt IPv6-Konnektivität auf dem Client herstellen, um den Netzwerkverkehr am VPN vorbeizuleiten. (Also ein weiteres Anwendungs-Szenario des ‘klassischen’ MITM-Angriffs mit Rouge Router Advertisements.)
Was kann man tun?
Im genannten Draft gibt es verschiedene Vorschläge, wie man diesem Problem in der Praxis begegnen kann. Es unterscheidet dabei VPN-Tunnel, die den gesamten Traffic tunneln sollen und welche, die nur für einen Teil des Traffics konfiguriert sind (“split tunnel”):
- Wenn der VPN-Client IPv6 nicht unterstützt, sollte IPv6 auf den Netzwerk-Interfaces des Clients abgeschaltet sein, zumindest während der VPN-Tunnel aufgebaut ist.
- Wenn der VPN-Client bereits IPv6-fähig ist, sollte der Administrator sicherstellen, dass IPv6-Verkehr auch tatsächlich durch den Tunnel geroutet wird.
- Im Split Tunnel Mode muss er ausserdem dafür sorgen, dass die richtigen Netze sowohl für IPv4 als auch für IPv6 durch den Tunnel geroutet werden.
- Darüber hinaus sollte sichergestellt werden, dass die Client-Rechner vor Angriffen über NDP (wie Rogue Router Advertisements) geschützt sind, damit nicht durch Angreifer neue Routen für IPv6 konfiguriert werden können.
Ausblick
Als final note hält Fernando Gont noch fest, dass das gleiche Problem natürlich auch in ein paar Jahren umgekehrt mit v6-only VPN-Lösungen und IPv4-Traffic auftreten kann. 😉
[Update 27.8.2014]
Seit August 2014 gibt es ein RFC 7359 zu dieser Thematik.