Neue Informationen zum WebRTC IP Leak

Perfect Privacy

Administrator
Ü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:
Code:
  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.
Der Perfect Privacy VPN Manager verhindert dieses IP-Leak mit den Standardeinstellungen. Der integrierte Firewall-Schutz ist defaultmäßig aktiviert, sobald ein VPN-Tunnel aufgebaut wird. Das verhindert, dass Pakete über unverschlüsselte Interfaces gesendet werden, auch wenn “Source IP address selection” genutzt wird: Solche Pakete werden grundsätzlich blockiert.
Fazit: Solange der Firewall-Schutz in der Perfect-Privacy-Software aktiviert ist, besteht keine Möglichkeit, über diese Methode an die öffentliche IP zu gelangen – egal ob über WebRTC oder andere Methoden.
[1] http://blogs.technet.com/b/networki...ection-on-a-multi-homed-windows-computer.aspx

Mit freundlichen Grüssen,
Euer Perfect Privacy Team
 
Könnte ich fast nen Veto einlegen.Ohne die Änderung beim Fuchs in der about:config sehe ich die interne VPN Ip,meine Rechner IP,die IP vom Server,mit dem ich verbunden bin,und MEINE Reale IP.Firewall aktiviert. Starte ich den Fuchs allerdings in Sandboxie,sehe ich auf der Testseite NICHT meine reale IP,sondern nur die anderen.Auch bei Eingeschaltetem Java Script taucht sie nicht auf...
 
Hallo,

Wie in unserem Post beschrieben konnten wir diese Schritte auf einem frisch installierten Windows 7 zuverlässig reproduzieren. Es ist immer äußert schwierig, so etwas auf bestehende Systeme zu übertragen, insbesondere wenn Software installiert ist, die in irgendeiner Weise Veränderungen in den Netzwerkeinstellungen vornehmen kann (betrifft beispielseweise jede Sicherheits-Software wie Antivirus-Programme oder Personal Firewalls).

Ich will trotzdem versuchen, Deinen Fall nachzuvollziehen. Dazu müsste ich folgendes wissen:

1) Ich nehme an, Du beziehst Dich auf die Demonstration von Daniel Roesler hier: https://diafygi.github.io/webrtc-ips/ - Ist das korrekt?

2) Welches Windows-Version setzt Du ein?

3) Bist Du als Administrator oder normaer Nutzer angemeldet?

4) Benutzt Du die Final. oder die Beta-Version des Perfect Privacy VPN Managers?

5) Welche Sicherheitssoftware setzt Du ein (AV, Personal Firewall, sonstiges)

6) Hast Du mit Chrome die gleichen Ergebnisse wie mit Firefox?

Wenn Du diese Informationen nicht öffentlich stellen willst, kannst Du das auch gerne per Mail an support@perfect-privacy.com schicken. Schreib dann bitte 'Stephan' in den Betreff, so dass die auch an mich geht.
 
Ich (Win-7/64 Bit seit einigen Monaten und alles Updates drauf) konnte übrigens auch die komplette Route bei Davids Link sehen, sobald ich "Adblock Plus" ausgeschaltet habe. Und ich habe immer im BETA-Manager den Haken beim Leakschutz aktiviert (Standard bei mir). Ich surfe nur mit dem Fox. Virus-Firewall ist F-secure. Ich habe vor wenigen Tagen den Firefox (about:config) umgestellt.
Danach konnte ich bei dem Link von David keine der IPs sehen.
Ich bin damit auch zufrieden und lasse das auch alles mal so.
Worüber ich mir lediglich Gedanken mache, ist, dass der Leakschutz (Beta-Manager) auf die Firewall bzgl. WebRTCnicht funktioniert.
Kann ich speziell diesen 'Schutz nicht selbst peer Hand für immer heraus nehmen? Wenn ja, dann gebe mit mal den Pfad dahin bzw. was ich da anklicken muß.
......................................................
Zusätzlich:
Kann es sein,dass man im TAP-Adapter die "Datei- und Druckerfreigabe für Microsoft-Netzwerke" nicht frei geben darf? Ich habe vor langer Zeit mal gelesen, dass diese Schnittstelle verräterisch sein soll, wenn man sie an hat. Kann mich aber nicht mehr genau erinnern um was es da genau ging.
 
Meinst Du den DNS Leak Schutz, oder den Firewall-Schutz im Client? Der DNS-Leak-Schutz hat damit nichts zu tun, es muss der Firewall-Schutz aktiviert sein.

Unabhängig davon: Benutzt Du F-Secure Internet Security? Ich fürchte, das könnte im Konflikt mit dem PP VPN Manager liegen, wenn beide auf Firewall-Regeln zugreifen...

EDIT: Lars ergänzt gerade noch, dass das Problem auch entsteht, wenn Du in deinem lokalen LAN eine 10er IP-Range benutzt (ist zum Beispiel der Fall in einer VM oder mit UMTS). Denn dann kann der PP VPN Manager die Firewall-Regeln nicht korrekt setzen, weil die IP-Range im Konflikt mit der VPN-IP-Range liegt.

Das wird in der nächsten Version des Clients behoben; dann funktioniert der Firewall-Schutz auch wenn du lokal schon in einer 10er-Range bist.
 
Ah ja, zur Klar-Richtigstellung:
Firewallhäkchen gesetzt bei:
- Bei Programmstart aktivieren
- Zugriff auf lokalen Router blockieren
- Diesem Programm Downloads ohne VPN erlauben
..................

DNS-Leak-Schutz wurde gesetzt bei:
- Bei Programmstart aktivieren

Obige Einstellungen sind Standard bei mir.
 
Gerade 20 Min. verschiedene Einstellungen im Fox ausprobiert. Danach auch mal neu gestartet. Java und Flash sind in den 20 Min. deaktiviert gewesen:
- Nochmal die Daten: Win-7/64Bit mit allen Updates. Das System ist vor einigen Monaten aufgespielt worden. Virusscanner und Firewall ist F-secure.
Was habe ich eben getan:
- Ghostery geladen und im aktiven sowie passiven Zustand ausprobiert. Resultat: IPs waren zu sehen.
- Der gleiche Versuch wurde mit NoScript und Adblock Plus ausprobiert. Resultat: Egal ob ein- oder ausgeschaltet, die IPs waren zu sehen.

Was bei mir nur hilft ist die Einstellung über About:config, indem ich dort den Wert "media.peerconnection.enabled" auf false setze.
...............................
Dabei, ich habs vor wenigen Tagen hier noch geschrieben, hat das Aktivieren von "Adblock Plus" dazu geführt, dass ich die IPs NICHT sehen konnte.
Sobald, also vor wenigen Tagen, ich "Adblock Plus" aber deaktiviert hatte, konnte ich die IPs sehen.

Warum das heute nicht funktioniert hat entzieht sich meiner Kenntnis. Ich habe am Rechner nichts gemacht. Auch keine neuen Progs ausprobiert. Ich fahre seit Win-7 immer mit den gleichen Einstellungen und Programmen.

Jetzt steht der Firefox wie oben erwähnt auf "false" und alles ist gut :)
xxxxxxxxxxxxxxxxxxxx

Nachtrag:
Geschrieben am 31.01.2015, 11:29
Bei mir (Win-7/64 Bit) erscheinen keine IP's, weil ich "Adblock Plus" im Firefox aktiviert habe. Schalte ich "Adblock Plus" aus, sehe ich alle IP's.
Quelle hier: https://board.perfect-privacy.com/f...und-schutz/11930-echte-ip-trotz-vpn-augelesen

Und das war auch so - IPs gesehen, IPs nicht mehr gesehen.
Zu dem Zeitpunkt war ich noch nicht im Firefox-about:config.
Und an/in "Adblock Plus" rumgefummelt habe ich auch nicht.
Alles sehr merkwürdig.

Aber wie bereits geschrieben: Wenn das weiterhin mit der neuen Foxeinstellung funktioniert, bin ich damit zufrieden.
 
Ich fasse mal zusammen:
  • WebRTC in Chrome und Firefox unter Windows kann die vom ISP zugewiesene IP leaken, Browser-Plugins wie AdBlock oder Ghostery blockieren dies nicht, wie auf https://github.com/diafygi/webrtc-ips beschrieben.
  • Der Firewall-Schutz im Perfect Privacy VPN Manager schützt dagegen, allerdings funktioniert dies nur, wenn der eigene Rechner in keinem 10.*.*.* LAN sitzt, weil sonst die IP-Range mit dem VPN im Konflikt steht und so die Firewall-Regeln nicht greifen. Zudem kann Sicherheits-Software auf dem Rechner die Firewall-Regeln beeinträchtigen.
  • WebRTC im Browser lässt sich blockieren. In FIrefox wie von Dr_Iwan_Kakalakow beschrieben, in dem man media.peerconnection.enabled in about:config auf false setzt. Für Chrome gibt es ein Plugin, um WebRTC zu blockieren: https://chrome.google.com/webstore/detail/webrtc-block/nphkkbaidamjmhfanlpblblcadhfbkdm
 
Dr_Iwan_Kakalakow;n12107 said:
Nachtrag:
Geschrieben am 31.01.2015, 11:29
Bei mir (Win-7/64 Bit) erscheinen keine IP's, weil ich "Adblock Plus" im Firefox aktiviert habe. Schalte ich "Adblock Plus" aus, sehe ich alle IP's.
Quelle hier: https://board.perfect-privacy.com/f...und-schutz/11930-echte-ip-trotz-vpn-augelesen

Und das war auch so - IPs gesehen, IPs nicht mehr gesehen.
Zu dem Zeitpunkt war ich noch nicht im Firefox-about:config.
Und an/in "Adblock Plus" rumgefummelt habe ich auch nicht.
Alles sehr merkwürdig.

Aber wie bereits geschrieben: Wenn das weiterhin mit der neuen Foxeinstellung funktioniert, bin ich damit zufrieden.

Das ist interessant, da der Author explizit sagt, AdBlock blockiert den Angriff nicht (https://github.com/diafygi/webrtc-ips):

Additionally, these STUN requests are made outside of the normal XMLHttpRequest procedure, so they are not visible in the developer console or able to be blocked by plugins such as AdBlockPlus or Ghostery.

Möglicherweise funktioniert das im Zusammenspiel mit etwas anderem., Wie gesagt, auf bereits installierten System sind die Ergebnisse durchaus unterschiedlich, es hängt sehr damit zusammen, welche Software und Browserplugins aktiviert sind, ob man mit Admin-Rechten unterwegs ist, etc.

Grundsätzlich ist es zu empfehlen, im Browser WebRTC zu blockieren und zusätzlich den Firewall-Schutz zu aktivieren. Dann ist man auf jeden Fall auf der sicheren Seite.
 
Soweit richtig, Stephan.
Wie/wo kann ich das kontrollieren ---> "...keinem 10.*.*.* LAN sitzt, weil sonst die IP-Range mit dem VPN im Konflikt steht und so die Firewall-Regeln nicht greifen."
Mein Login geht so: Beta-Manager aufrufen. Kein IPSEC, sondern Open-VPN. Dann z.B. Rotterdam-Server. Danach Tunnelmanager nach z.B. Stockholm.
Ab ins Netz.
 
In Windows kannst Du in der Konsole (cmd.exe) ipconfig /all eingeben, und schaust nach, welche IP dir über LAN bzw. WLAN (je nachdem, was du benutzt) zugewiesen wurde.
 
PP Stephan;n12112 said:
In Windows kannst Du in der Konsole (cmd.exe) ipconfig /all eingeben, und schaust nach, welche IP dir über LAN bzw. WLAN (je nachdem, was du benutzt) zugewiesen wurde.

Auch davon habe ich 0,00 Ahnung, aber habe es versucht. Resultat: Mein DHCP-Server über Normal-LAN hat eine 10-ner Nummer. Die wurde doch von PP gestellt, oder? Ich bin da nicht so gut bewandert..... :) Deshalb bastel ich auch kaum am PC herum.
 
PP Stephan;n12110 said:
... und zusätzlich den Firewall-Schutz zu aktivieren. Dann ist man auf jeden Fall auf der sicheren Seite.
Ich habe das ja im Firewallschutz aktiviert, aber scheint nicht zu funktionieren. Vielleicht oder wahrscheinlich wegen der 10-ner Nummer.
Vielleicht sollte ich die Häkchen in der Win-7-Firewall selbst setzen. Ich muß allerdings wissen wo und ob die Häkchen dann auch stets gesetzt bleiben - also immer. Wenn Stephan mal viel Zeit hat (ob das bei PP-Menschen derzeit überhaupt vor kommt? ), könnte er doch die Punkte (Kästchen) angeben, wo diese Häkchen in der Firewall aktiviert oder deaktiviert werden müssen. Oder mal einen Screen machen, wenn es sich nur um wenige Häkchen handeln sollte.
Ich selbst, da ja blutiger Laie, muß erst einmal sehen, wie ich in die Firewall komme, denn dort war ich noch nie :)
Die dann von mir gesetzten Häkchen könnten sogar gesetzt bleiben, weil ich nie ohne PP unterwegs bin.
 
Dr_Iwan_Kakalakow;n12114 said:
Resultat: Mein DHCP-Server über Normal-LAN hat eine 10-ner Nummer. Die wurde doch von PP gestellt, oder?

Nein, die 10'er IPs von PP sind im TUN bzw. TAP adapter. Dass Dein lokales LAN eine 10er-Range hat ist das Problem - daher kann keine entsprechende Firewall-Regel gesetzt werden.

Wie gesagt: Im nächsten Client-Update funktioniert das dann auch mit 10'er IPs. Bis dahin kannst WebRTC blockieren (was ohnehin sinnvoll ist)
 
PP Stephan;n12117 said:
Nein, die 10'er IPs von PP sind im TUN bzw. TAP adapter. Dass Dein lokales LAN eine 10er-Range hat ist das Problem - daher kann keine entsprechende Firewall-Regel gesetzt werden.
Wie gesagt: Im nächsten Client-Update funktioniert das dann auch mit 10'er IPs. Bis dahin kannst WebRTC blockieren (was ohnehin sinnvoll ist)

Okidoki, wieder ein Stückchen schlauer :)

Danke Dir !
 
Vielleicht kann ja jemand in Erfahrung bringen, seit wann diese Lücke existiert bzw. bei welchem Firefox sie noch nicht war. Vielleicht ist die Lücke ja durch die letzte Erneuerung (Apps u.a. sind ja dazu gekommen) entstanden. Surft jemand vielleicht noch mit einem alten Fox?

Nachtrag:
Die Lücke ist ab Version-34. Jetzt haben wir Version-35.0.1.
 
Der Perfect Privacy VPN Manager verhindert dieses IP-Leak mit den Standardeinstellungen

Code:
C:\>ping -S 192.168.1.30 8.8.8.8

Ping wird ausgeführt für 8.8.8.8 von 192.168.1.30 mit 32 Bytes Daten:
Antwort von 8.8.8.8: Bytes=32 Zeit=9ms TTL=58
Antwort von 8.8.8.8: Bytes=32 Zeit=9ms TTL=58
Antwort von 8.8.8.8: Bytes=32 Zeit=9ms TTL=58
Antwort von 8.8.8.8: Bytes=32 Zeit=9ms TTL=58

Ping-Statistik für 8.8.8.8:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 9ms, Maximum = 9ms, Mittelwert = 9ms

Im VPN Manager ist die FW aktiviert und wird mit einem F oben rechts angezeigt. Win 7 Ultimate 64x und als Admin angemeldet. Taugt der VPN Manager bei mir nichts?
 
Setze mal die Windows Firewall auf Standard zurück, dann Manager wieder aufmachen(vorm zurücksetzen natürlich zu machen), verbinden und nochmal testen.... Das Gleiche Ergebniss?
 
Das sagt jetzt so noch nicht aus, wie das geroutet wurde. Probiere mal folgendes aus:

Verbinde dich mit Brisbane via OpenVPN, aktiviere den Firewall-Schutz und probiere den ping einmal mit und einmal ohne Quell-IP, also:


ping -S 192.168.1.30 8.8.8.8

und einmal nur

ping 8.8.8.8

Und pste beide outputs hier. Wenn mit Source-IP nicht über VPN geroutet wird, sollte das deutlich weniger Latenz aufzeigen.

Wenn das der Fall ist, dann sage uns bitte ob Du die Beta oder Final der Software verwendest, und ggf. sende uns dann mal deine Ruuting-Table per mail.
 
Code:
C:\>ping -S 192.168.1.30 8.8.8.8

Ping wird ausgeführt für 8.8.8.8 von 192.168.1.30 mit 32 Bytes Daten:
Antwort von 8.8.8.8: Bytes=32 Zeit=9ms TTL=58
Antwort von 8.8.8.8: Bytes=32 Zeit=9ms TTL=58
Antwort von 8.8.8.8: Bytes=32 Zeit=9ms TTL=58
Antwort von 8.8.8.8: Bytes=32 Zeit=9ms TTL=58

Ping-Statistik für 8.8.8.8:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 9ms, Maximum = 9ms, Mittelwert = 9ms

C:\>ping 8.8.8.8

Ping wird ausgeführt für 8.8.8.8 mit 32 Bytes Daten:
Antwort von 8.8.8.8: Bytes=32 Zeit=12ms TTL=59
Antwort von 8.8.8.8: Bytes=32 Zeit=11ms TTL=59
Antwort von 8.8.8.8: Bytes=32 Zeit=12ms TTL=59
Antwort von 8.8.8.8: Bytes=32 Zeit=12ms TTL=59

Ping-Statistik für 8.8.8.8:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 11ms, Maximum = 12ms, Mittelwert = 11ms

C:\>

Das was Frank geschrieben hat probiere ich in ca. 20min

PP Frank;n12126 said:
Setze mal die Windows Firewall auf Standard zurück, dann Manager wieder aufmachen(vorm zurücksetzen natürlich zu machen), verbinden und nochmal testen.... Das Gleiche Ergebniss?


Code:
C:\>ping -S 192.168.1.30 8.8.8.8

Ping wird ausgeführt für 8.8.8.8 von 192.168.1.30 mit 32 Bytes Daten:
Allgemeiner Fehler.
Allgemeiner Fehler.
Allgemeiner Fehler.
Allgemeiner Fehler.

Ping-Statistik für 8.8.8.8:
    Pakete: Gesendet = 4, Empfangen = 0, Verloren = 4
    (100% Verlust),

Danke für den Tipp :)
 
Back
Top