„Wrong Way“: Es wurde eine weiteres VPN-Sicherheitsproblem gefunden. Ein routing ‚feature‘ demaskiert ähnlich wie Port Fail die Real-IP eines VPN-Nutzers. Diesmal sind nicht nur Provider die Port-Weiterleitungen anbieten betroffen, sondern alle die keinen Fix für dieses Problem implementiert haben. Das unterliegende Problem besteht darin, dass über die Real-IP eingehende Pakete unter bestimmten Umständen über die VPN-Route beantwortet werden.
Nutzer, die den Perfect Privacy VPN Manager benutzen sind vor dem Angriff geschützt.
In Zusammenarbeit mit ValdikSS vom russischen VPN-Betreiber ProstoVPN wurde folgende Lösung für dieses Problem gefunden.
Folgende Voraussetzungen müssen für einen erfolgreichen Angriff erfüllt sein:
Ein mögliches Angriffsszenario kann wie folgt ausgenutzt werden:
Diese Schwachstelle ist kritisch, weil sie im Allgemeinen alle Betriebssysteme und VPN-Protokolle betrifft. Im Unterschied zu PortFail existiert keine serverseitige Lösung: Die empfohlene Methode, um sich vor diesem Angriff zu schützen, besteht darin, UPnP-Unterstützung auf dem Router abzuschalten. Falls das nicht möglich ist, kann man Pakete, die diesen Angriff ermöglichen, per Firewall blockieren (siehe Gegenmaßnahmen).
ProstoVPN hat ein Video bereitgestellt, dass diesen Angriff unter Verwendung von Windows 10 demonstriert.
Die beste Lösung besteht darin, UPnP-Unterstützung auf dem Router zu deaktivieren. Das verhindert offene Ports auf dem Router auch wenn solche von Programmen angefordert werden.
Anwender, die keinen Zugriff auf ihren Router haben und die UPnP-Unterstützung nicht abschalten können und Nutzer, die direkt (ohne Router) mit dem Internet verbunden sind, müssen Netzwerkverkehr, der die Real-IP leakt, explizit blockieren.
Unter Linux ist das einfach erreichbar, indem man folgenden Befehl eingibt:
sysctl net.ipv4.conf.*.rp_filter=1
Wobei sich * auf das jeweilige Interface bezieht. Wenn das VPN-Interface tun0 und das Internet-Interface wlp3s0 ist, wären die Befehle wie folgt:
sysctl net.ipv4.conf.default.rp_filter=1 sysctl net.ipv4.conf.tun0.rp_filter=1 sysctl net.ipv4.conf.wlp3s0.rp_filter=1
Das sorgt dafür, dass Pakete verworfen werden, die aufgrund der Routing-Table nicht auf dem gleichen Interface beantwortet werden können. Zusätzlich sollte die folgende Firewall-Regel für IPv6 gesetzt werden:
ip6tables -t raw -A PREROUTING -m rpfilter --invert -j DROP
Unter macOS ist das etwas schwieriger; der einfachste Weg besteht darin, alle eingehenden UDP-Pakete zu blockieren, außer sie stammen von nicht-routbaren Adressen, dem Subnetzwerk des ISP oder der IP-Adresse vom VPN-Server selbst:
echo 'pass in quick proto udp from 10.0.0.0/8 to any pass in quick proto udp from 192.168.0.0/16 to any pass in quick proto udp from 172.16.0.0/12 to any pass in quick proto udp from 169.254.0.0/16 to any pass in quick proto udp from 185.61.149.121/32 to any block in quick on ! utun1 proto udp to any' | sudo pfctl -Ef -
In diesem Beispiel ist 185.61.149.121 die IP-Adresse des VPN-Servers und utun1 das VPN-Interface.
Die rp_filter Funktionalität gibt es unter Windows nicht. Allerdings können VPN-Provider mit eigener VPN-Client-Software entsprechende Firewall-Regeln setzen, die das IP-Leak verhindern. Dies ist bei Perfect Privacy der Fall.
Windows-Benutzer, die die OpenVPN-Software verwenden, um zu ihrem VPN-Provider zu verbinden, bleiben anfällig für das IP-Leak. Wenn es nicht möglich ist, UPnP-Unterstützung im Router zu deaktivieren oder wenn ein Windows-Nutzer direkt mit dem Internet verbunden ist, kann das IP-Leak durch Setzen spezifischer Firewall-Regeln verhindert werden. ValdikSS bietet ein Plugin an, dass den Angriff blockiert. Hinweis: Das Plugin wird nicht von Perfect Privacy unterstützt und wir übernehmen keinerlei Verantwortung für die Verwendung. Wir listen es hier nur als möglichen Fix für Nutzer anderer VPN-Anbieter, die keinen Schutz vor diesem Angriff bieten.