[Netzwelt] VPN wirkungslos - WebRTC in Firefox & Chrome verrät sämtliche IPs

Wer sich zum Surfen mit anonymer IP einfach auf ein VPN verlässt und sonst einen normalen Firefox Browser verwendet, sollte sofort handeln. Trotz diverser Datenschutz Addons, könnte der Betreiber der Webseite die echte IP sehen.

WebRTC dient der Echtzeitkommunikation. Also Sprach- und Videotelefonie via Internet, z.B. wie Skype oder SIP. Um Firewalls und NATs zu umgehen, gibt es dort die sogenannten STUN-Server. Diese dienen dazu, auch angerufen werden zu können, wenn man nur eine lokale IP z.B. aus dem Bereich 192.168.x.x hat.

Die Implementierung in Firefox erlaubt es nun, über ein Javascript auf einer Webseite, sämtliche lokalen, aber auch die IPs von VPN und Kabel/DSL Provider auszulesen. Zunächst erhält das Javascript die IPs nur lokal, kann sie dann aber über Umwege wieder an den Server schicken. Der Betreiber erhält die echte IP, die Anonymisierung per VPN ist ausgehebelt.

Betroffen ist auch der Google Browser Chrome. Die Lücke funktioniert jedoch nicht mit dem Internet Explorer oder einem Firefox mit JondoFox Profil (sie wird duch das JonDo AddOn geblockt, ein deaktiviertes NoScript ist unschädlich). Abgeschaltetes Javascript schützt selbstverständlich auch.

Hier kann es jeder selbst testen (bei VPN Nutzung auch auf die zweite öffentliche IP achten).

Was kann man tun?

Wer WebRTC nicht braucht, sollte es abschalten.

32ba008257978e25dd58.png

Dazu wird in about:config einfach media.peerconnection.enabled auf false gesetzt.

Warum ist das so gefährlich?

Nicht nur der Betreiber der Webseite kann diese Lücke einsetzen und z.B. einen Honeypot aufsetzen um die echte Identität eines Besuchers herauszufinden. Denkbar ist auch, dass eine bestehende Seite von einem Angreifer gehackt und mit diesem Code versehen wird. Oder z.B. Webmail Anbieter werden von den Behörden gezwungen, diese Sicherheitslücke auf ihre Seite einzubauen, um an die wahre Identität eines bisher anonymen Postfaches zu kommen.

------------------------------------------------------------------

Quelle:
Englisch:


Vielleicht sollten die hier sich auch aufhaltenden VPN Anbieter (wie Secure-VPN und Perfect-Privacy) eine News mit Anleitung auf ihrer Homepage posten.
 
Echt gut das man nicht regelmäßig drauf aufmerksam gemacht wird wie wichtig eine Javascript Whitelist ist.

Die Superkraft der Hindsight mit ihren Blacklists ist ja schließlich bekanntermaßen soviel Wirkungsvoller.

Und zu guter Letzt gepriesen seien doie Spasten die regelmäßig beschließen Websites nur mit Javascript nutzbar zu machen obwohl es alternativen gibt.:T
 
Danke für den Hinweis! Benutze Firefox (wohlgemerkt aber auch mit NoScript, also Whitelist) und gelegentlich Hide.me, hab die entsprechenden Änderungen mal vorgenommen.

:T
 
Bevor jemand auf die Idee kommt irgendwelche Plugins mit fragwürdigen Berechtigungen zu installieren:
WebRTC kann man im Google Chrome mittels Flags deaktivieren.
Dazu bei Google Chrome chrome:flags aufrufen, nach Media Source API deaktivieren bzw. #disable-media-source suchen und dieses Flag aktivieren.

Achtung: Aktivieren des Flags deaktiviert WebRTC.
 
Über das Wochenende haben wir uns nochmal eingehend mit der WebRTC-Schwachstelle beschäftigt und können dazu einige neue Informationen liefern.

Die wichtigste Erkenntnis ist, dass in diesem Fall zwar WebRTC benutzt wurde, um das IP-Leak auszunutzen, aber WebRTC ist nicht die Ursache dafür, dass dies überhaupt möglich ist. Vielmehr handelt es sich um ein Windows-Feature, dass es erlaubt, unter gewissen Bedingungen die Routing-Table zu umgehen. Microsoft schreibt in seinem Techblog wie folgt:

“If the program specifies a source IP address, that IP address is used as the source IP address for connections sourced from that socket and the adapter associated with that source IP is used as the source interface. The route table is searched but only for routes that can be reached from that source interface.” [1]

Normalerweise wird beim Aufbau eines VPN-Tunnels eine spezifischere Route zum TUN/TAP-Adapter gesetzt, so dass diese grundsätzlich für allen Netzwerkverkehr bevorzugt wird. Die “Source IP address selection” erlaubt es Windows-Programmen allerdings eine generellere Route zu verwenden, wenn die angegebene Quell-IP an ein entsprechendes Interface gebunden ist.

Das lässt sich mit folgendem Befehl in der Konsole überprüfen:

ping -S <lokale LAN-IP> <Ziel-IP>

Wenn man als “lokale LAN-IP” die von Router zugewiesene IP-Adresse verwendet, so werden die Ping-Anfragen über das unverschlüsselte Interface gesendet, auch wenn ein VPN-Tunnel besteht. In unseren Tests hat das nicht auf allen Systemen funktioniert (in einigen Fällen scheitern die Anfragen mit “Allgemeiner Fehler) aber wir konnten dies auf einem frisch installierten Windows 7 reproduzieren.

Folglich können Windows-Applikationen grundsätzlich auf diese Methode zurückgreifen, um Pakete über unverschlüsselte Interfaces zu senden – das Problem ist nicht nur auf WebRTC beschränkt. Die Installation eines Browser-Plugins, dass WebRTC blockiert beseitigt also nicht die zugrundeliegende Ursache.[...]



Gruß
Baer
 
Zur Ergänzung:
  • das Chrome-Plugin funktioniert nicht mehr ( )
  • Deaktivieren des Media Source API bzw. über funktioniert manchmal und manchmal nicht ( ), Zeitpunkt und Art eines Browser-Neustarts scheinen einen Einfluß zu haben
  • die Nutzung der lokalen IP als Interfaceadresse für Apps/Programme funktioniert ( )
    Test: '[kw]ping -S <lokale IP> <Ziel-Adresse>[/kw]', die Laufzeiten sind über VPN typischerweise länger
    (läßt sich das blockieren?)

Das oben gesagte gilt für Chrome 40.0.2311.90 (m) unter Win 8.1 und 64-bit unter OS X 10.10.3.
 
Zuletzt bearbeitet:
Zurück
Oben