• Hallo liebe Userinnen und User,

    nach bereits längeren Planungen und Vorbereitungen sind wir nun von vBulletin auf Xenforo umgestiegen. Die Umstellung musste leider aufgrund der Serverprobleme der letzten Tage notgedrungen vorverlegt werden. Das neue Forum ist soweit voll funktionsfähig, allerdings sind noch nicht alle der gewohnten Funktionen vorhanden. Nach Möglichkeit werden wir sie in den nächsten Wochen nachrüsten. Dafür sollte es nun einige der Probleme lösen, die wir in den letzten Tagen, Wochen und Monaten hatten. Auch der Server ist nun potenter als bei unserem alten Hoster, wodurch wir nun langfristig den Tank mit Bytes vollgetankt haben.

    Anfangs mag die neue Boardsoftware etwas ungewohnt sein, aber man findet sich recht schnell ein. Wir wissen, dass ihr alle Gewohnheitstiere seid, aber gebt dem neuen Board eine Chance.
    Sollte etwas der neuen oder auch gewohnten Funktionen unklar sein, könnt ihr den "Wo issn da der Button zu"-Thread im Feedback nutzen. Bugs meldet ihr bitte im Bugtracker, es wird sicher welche geben die uns noch nicht aufgefallen sind. Ich werde das dann versuchen, halbwegs im Startbeitrag übersichtlich zu halten, was an Arbeit noch aussteht.

    Neu ist, dass die Boardsoftware deutlich besser für Mobiltelefone und diverse Endgeräte geeignet ist und nun auch im mobilen Style alle Funktionen verfügbar sind. Am Desktop findet ihr oben rechts sowohl den Umschalter zwischen hellem und dunklem Style. Am Handy ist der Hell-/Dunkelschalter am Ende der Seite. Damit sollte zukünftig jeder sein Board so konfigurieren können, wie es ihm am liebsten ist.


    Die restlichen Funktionen sollten eigentlich soweit wie gewohnt funktionieren. Einfach mal ein wenig damit spielen oder bei Unklarheiten im Thread nachfragen. Viel Spaß im ngb 2.0.

[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: http://www.anonym-im-netz.com/vpn-wirkungslos-webrtc-in-firefox-verraet-saemtliche-ips/
Englisch: https://torrentfreak.com/huge-security-flaw-leaks-vpn-users-real-ip-addresses-150130/


Vielleicht sollten die hier sich auch aufhaltenden VPN Anbieter (wie Secure-VPN und Perfect-Privacy) eine News mit Anleitung auf ihrer Homepage posten.
 

alter_Bekannter

N.A.C.J.A.C.

Registriert
14 Juli 2013
Beiträge
4.829
Ort
Midgard
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
 

Kaesereibe

Haben oder Sein?

Registriert
20 Juli 2013
Beiträge
875
Ort
NRW
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
 

accC

gesperrt

Registriert
14 Juli 2013
Beiträge
5.250
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.
 

Baer

Ottonormalverbrecher
Veteran

Registriert
15 Juli 2013
Beiträge
3.629
Ü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.[...]

Quelle

Gruß
Baer
 

Nachtschatten

gesperrt

Registriert
16 März 2015
Beiträge
560
Zur Ergänzung:
  • das Chrome-Plugin WebRTC Block funktioniert nicht mehr (Warum nicht?)
  • Deaktivieren des Media Source API bzw. #disable-media-source über chrome:flags funktioniert manchmal und manchmal nicht (Test), Zeitpunkt und Art eines Browser-Neustarts scheinen einen Einfluß zu haben
  • die Nutzung der lokalen IP als Interfaceadresse für Apps/Programme funktioniert (KB175396)
    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:
Oben