IP-Leak bei VPN Providern mit Port Forwarding

PP Frank

Outstanding Member
Sicherheitslücke „Port Fail“ legt IP-Adresse offen
Wir haben eine Sicherheitslücke bei diversen VPN-Anbietern entdeckt, die es einem Angreifer erlaubt, die Real-IP der VPN-Nutzer herauszufinden. „Port Fail“ betrifft alle VPN-Provider, die Port-Forwarding anbieten und keine Schutzmaßnahmen gegen diesen Angriff getroffen haben. Perfect-Privacy-Nutzer sind vor diesem Angriff geschützt.

Dieses IP-Leak betrifft alle Nutzer: Auch wenn die Opfer kein Port-Forwarding aktiviert haben, können Sie von Angreifern, bei denen das Port-Forwarding aktiviert ist, ausgespäht werden.

Wir haben neun der bekanntesten VPN-Provider mit Port-Forwarding getestet. Fünf davon waren anfällig für den Angriff und wurden vorab darüber informiert, damit sie das Problem vor Veröffentlichung beheben konnten. Möglicherweise sind aber noch weitere Anbieter betroffen, da wir unmöglich alle existierenden Provider überprüfen konnten.

Details zum Leak
Der Angreifer muss die folgenden Bedingungen erfüllen:

  • Er hat einen Account beim gleichen VPN-Anbieter wie das Opfer
  • Er kennt die IP-Adresse des VPN-Exits vom Opfer. (Diese kann über viele Möglichkeiten gefunden werden, etwa über Torrent-Clients, IRC oder indem man das Opfer dazu bringt, eine Webseite aufzurufen, die unter Kontrolle des Angreifers steht.)
  • Der Angreifer richtet Port-Fowarding ein. Es spielt keine Rolle, ob das Opfer Port-Forwarding einsetzt oder nicht.
So wird das IP-Leak ausgelöst:

  1. Opfer ist zum VPN-Server 1.2.3.4 verbunden
  2. Die Routingtabelle des Opfers sieht dann beispielsweise so aus:
    0.0.0.0/0 -> 10.0.0.1 (interner VPN-Gateway)
    1.2.3.4/32 -> 192.168.0.1 (alter Default-Gateway)
  3. Angreifer verbindet zum gleichen VPN-Server wie das Opfer (Angreifer kennt die IP-Adresse über IRC, torrent, oder andere Methoden).
  4. Angreifer aktiviert Port Forwarding auf dem server 1.2.3.4, Beispielport 12345.
  5. Angreifer bringt das Opfer dazu, 1.2.3.4:12345 aufzurufen, beispielsweise durch einbinden von <img src=“http://1.2.3.4:12345/x.jpg“> auf einer Webseite.
  6. Diese Verbindung offenbart dann die reale IP des Opfers aufgrund der „1.2.3.4/32 -> 192.168.0.1“ VPN-Route.
Das Entscheidene hier ist, dass Verbindungen zur IP-Adresse des VPN-Servers nicht durch das VPN gehen, sondern über den alten Default-Gateway, ergo mit der Real-IP des Nutzers.

Wenn ein anderer Nutzer (der Angreifer) Port-Forwarding auf dem gleichen Server aktiviert, kann er die Real-IP jedes Nutzers auf diesem Server ermitteln, indem er Sie dazu bringt, einen Link aufzurufen, der den Traffic auf einen Port unter seiner Kontrolle weiterleitet.

Zudem sei darauf hingewisen, dass aufgrund der Natur des Angriffs alle VPN-Protokolle (IPSec, OpenVPN, PPTP, etc.) und alle Betriebssysteme betroffen sind.

Gegenmaßnahmen für VPN-Anbieter
Betroffene VPN-Provider sollten eine der beiden folgenden Maßnahmen ergreifen:

  • Mehrere IP-Adressen einsetzen: Eingehende Verbindungen sind auf ip1 erlaubt, ausgehende Verbindungen gehen über ip2-ipx raus. Port-Forwadings sind dann nur auf ip2-ipx aktiviert.
  • Nach Verbindung des Clients eine serverseitige Firewall-Regel setzen, die den Zugriff von der Real-IP des Clients auf Port-Forwardings blockieren, die nicht seine eigenen sind.
 
Na klar. Steht doch da *kopfgegenwand* Garnicht gesehen :oops:

Finde es auch sehr fair von PP die anderen zu informieren
 
Ja, das Ding ist nicht ohne, weswegen wir auch ettliche andere angeschrieben haben. Deren Nutzer stehen sonst blöde da. Das einzige was zum Kotzen war, ist das der Typ von oVPN die Klappe nicht halten konnte.
Sinn der Aktion war es ja, dass das nicht public wird bevor das die guten Dienste gefixt haben. Wenn das bekannt wird, wird es auch massenweise ausgenutzt. PP Nutzer waren schon geschützt bevor wir das den anderen Diensten gesagt haben, von daher ist das für uns nichtmal das Problem. Aber das Verhalten an sich ist zum Kotzen und hat Null mit Anstand zu tun
 
Frank,
wann und wie seit Ihr dahinter gekommen?
Lars, Daniel, Du evtl. durch Zufall oder anderes?


*Antwort auch über PN, wenn nötig.
 
Habt ihr wirklich gut gemacht. Schön das PP bei Torrentfreak erwähnt wird! Die 5000 Dollar von PIA könnt ihr versaufen;-)
 
Hallo,

die 5000 Dollar haben wir direkt und komplett an den Finder des Bugs weiter gereicht. Wir haben diese also nicht behalten.

wann und wie seit Ihr dahinter gekommen?

Auf die Idee das zu probieren kam ein Bekannter, der uns auch ab und zu mal hilft. Deswegen haben wir ihm auch den Betrag von PIA komplett gegeben
 
Na das ist doch schon lange bekannt und läßt sich einfach dadurch lösen, daß man nicht den ganzen traffic zum vpn-server durch das alte default-gw leitet, sondern mittels firewall-regel alles bis auf das vpn-port blockiert.
Das ist ja z.B. auch bei bit-torrent clients ein Problem, wenn die auf dem selben vpn unterwegs sind und dann plötzlich über ihre öffentliche IP Daten tauschen...
Ich frag mich nur, wie ihr das von eurer Seite verhindern wollt, daß ich ein offenes Port auf dem vpn-server über meine öffentliche IP anspreche. Das kann doch nur ich selbst verhindern. Oder macht ihr "deep packet inspection".
Wenn einer das z.B. in einem java-script verbirgt, kriegt ihr das doch sonst gar nicht mit.

p.s. lese gerade:
  • Nach Verbindung des Clients eine serverseitige Firewall-Regel setzen, die den Zugriff von der Real-IP des Clients auf Port-Forwardings blockieren, die nicht seine eigenen sind.
ist aber nicht unbedingt die beste Lösung - das muß clientseitig gemacht werden und wenn serverseitg dann nur Zugriffe über die öffentliche IP auf das geforwardete port - von intern kommt man doch noch hin, oder?
 
Last edited:
Na das ist doch schon lange bekannt und läßt sich einfach dadurch lösen, daß man nicht den ganzen traffic zum vpn-server durch das alte default-gw leitet, sondern mittels firewall-regel alles bis auf das vpn-port blockiert.

Ist ne praktikable Lösung, was man einfach clientseitig selbst machen kann. Ein Aufruf 1.2.3.4:12345 ist dann nicht mehr möglich.
 
@Mädels und Jungs!
Wenn ich (Win7/64Bit) an meiner Firewall etwas ändern muß, dann bitte Klick-für-Klick beschreiben. Ich danke Euch :)
 
Es geht darum den erzwungenen Aufruf 1.2.3.4:1234 zu verhindern, wobei 1.2.3.4 die externe IP eines VPN Servers ist. Aufgrund des Routings gehen Aufrufe an die externe IP des jeweils verbundenen VPN Servers zwingend am Tunnel vorbei. Das ist etwas, das nicht geändert werden kann. Was man allerdings ändern kann, sind die erlaubten Ports, die du rausgehend über dein Standard-Interface erreichen darfst. Dort muss clientseitig per Firewall lediglich jeglicher Traffic, ausser Traffic zu den VPN Ports der Server, unterbunden werden. Ein Aufruf an den Port 1234 wird dann geblockt.

Wie du das auf Win einstellst, kann ich dir nicht sagen, auf OSX wird das bereits durch die Settings, die ich im OSX Firewall pf Thread gepostet habe, unterbunden.
 
Danke Jack!
Vielleicht kennt sich hier ja jemand bzgl. der Win-7-Firewall aus und kann mir die KLICKS mitteilen?
Über welchen Port holt sich z.B. Windows sein Update? O.k., ich habe auf "manuelles Update" eingestellt, aber würde mich trotzdem interessieren.
Oder über welchen Port holt sich der CCleaner sein Update, wenn ich auf Update klicke?
Oder ich frage mal andersherum: Welche Ports braucht PP?
 
Die PP Ports findest du im Mitgliederbereich unter Server. Alle weiteren Ports sind uninteressant, da die Ports nur auf deinem Standard Interface geblockt werden. Auf dem VPN Interface bleiben alle frei, so dass alle Programme frei ins Netz können sofern VPN läuft.
 
Also - es ist etwas komplexer - pp hat ja typischerweise 1149,1150,1151, sowie 49,50,51 - daneben auch 443 und so weiter. Wenn man sich in der Config auf 1149 und 1150 beschränkt, muß man nur die durchlassen, sonst eben alle, die in der Konfig stehen.
*ABER* DNS soll natürlich noch funktionieren. Man muß es also entweder über die öffentliche IP (z.B. 8.8.8.8) machen, oder durch den Tunnel (udp port 53, bzw TCP port 53).
Ich hab bei mir einen eigenen kleinen DNS-Server, der über einen getrennten Tunnel mit den Forwarders verbunden ist. Damit sind die DNS-Abfragen auch mit einer anderen PP-IP als der übrige Krempel.
Hat übrigens auch den Vorteil, daß ich in meinen NS automatisch die PP-IPs eintragen kann:
Code:
dig frankfurt.pp.local A
...
Frankfurt.pp.local.   300   IN   A   10.29.11.1

Aufpassen muß man halt, wenn der Tunnel zusammenbricht - dann kann es sein, daß garnix mehr läuft - naja ein caching-DNS server tut dann noch eine Weile, wenn er die IP schon im cache hat - eben bis die TTL abgelaufen ist.

Zu Windows kann ich nix sagen - muß mich nur im Büro damit rumärgern - hier bin ich seit 10 Jahren Windows-frei
 
Es geht alles durch den VPN Tunnel, mit Ausnahme direkter Verbindungen zur externen IP des PP Servers. Das ist aber bei Win Update nicht der Fall. Das Problem tritt nur auf, wenn dein Client direkt die externe IP des VPN Servers anspricht, ansonsten nicht.
 
Moin zusammen,

Also: Erstmal müsst ihr wegen diesem leak clientseitig nichts tun, wir haben das Serverseitig abgefangen. Auch schon weil das ja alle Protokolle und alle Betriebsysteme betrifft ist das sinnvoller so.

Ich werde das aber denke ich mal in der nächsten Version vom Windows Client das auch noch clientseitig verhindern,
doppelt gemoppelt hält ja bekanntlich besser. Aber nötig ist das nicht.


Grüße
Lars
 
Back
Top