WebRTC-Leck

Ein WebRTC-Leck ist eine Schwachstelle in Browsern, die es einer Website ermöglicht, die reale IP-Adresse eines Benutzers zu ermitteln, indem sie Proxyserver oder VPNs umgeht und Netzwerk-Schnittstellen direkt über die STUN/TURN-Mechanismen von WebRTC abfragt. Diese Offenlegung geschieht, weil WebRTC, das für Echtzeitkommunikation entwickelt wurde, oft UDP-Verbindungen zu STUN- (Session Traversal Utilities for NAT) und TURN- (Traversal Using Relays around NAT) Servern verwendet, um direkte Peer-to-Peer-Verbindungen herzustellen, und diese Anfragen möglicherweise nicht über den konfigurierten Proxy des Browsers geleitet werden.

WebRTC und seine Architektur verstehen

WebRTC (Web Real-Time Communication) ist ein Open-Source-Projekt, das Echtzeit-Sprach-, Video- und Datenkommunikation direkt zwischen Browsern und anderen Client-Anwendungen ermöglicht. Es erlaubt die Peer-to-Peer-Datenübertragung ohne die Notwendigkeit von Zwischenservern, wodurch die Latenz und die Serverlast für Anwendungen wie Videokonferenzen, Dateifreigabe und Live-Streaming erheblich reduziert werden.

Zu den Schlüsselkomponenten der WebRTC-Verbindungsherstellung gehören:

• Signalisierungsserver: Wird verwendet, um Metadaten (z. B. Sitzungssteuerungsmeldungen, Netzwerkkonfiguration, Medienfähigkeiten) zwischen Peers auszutauschen, bevor eine direkte Verbindung hergestellt wird. Der Signalisierungsprozess selbst ist nicht durch WebRTC standardisiert und kann verschiedene Protokolle (z. B. WebSocket) verwenden.
• ICE (Interactive Connectivity Establishment): Ein Framework, das es Peers ermöglicht, direkte Verbindungen zu entdecken und herzustellen. ICE verwendet STUN- und TURN-Server, um den bestmöglichen Kommunikationspfad zu finden.
• STUN-Server: Hilft Peers, ihre öffentliche IP-Adresse und den Typ des NATs, hinter dem sie sich befinden, zu ermitteln. Wenn ein Client hinter einem NAT eine Anfrage an einen STUN-Server sendet, antwortet der Server mit der öffentlichen IP-Adresse und dem Port des Clients, wie sie vom Internet aus gesehen werden.
• TURN-Server: Wird verwendet, wenn eine direkte Peer-to-Peer-Verbindung nicht möglich ist (z. B. aufgrund restriktiver NATs oder Firewalls). Ein TURN-Server fungiert als Relais und leitet den gesamten Datenverkehr zwischen den Peers weiter.

Der kritische Aspekt für IP-Leckagen ist, wie ICE "Kandidaten" sammelt – potenzielle Netzwerkadressen und Ports, die für die Kommunikation verwendet werden können. Diese Kandidaten umfassen:

• Host-Kandidaten: Lokale IP-Adressen (z. B. 192.168.1.100, 10.0.0.5) des Benutzergeräts.
• Server-Reflexive Kandidaten: Die öffentliche IP-Adresse und Port-Zuordnung, die vom NAT-Router zugewiesen wird, entdeckt über einen STUN-Server.
• Relay-Kandidaten: IP-Adressen und Ports auf einem TURN-Server, die verwendet werden, wenn eine direkte Verbindung nicht möglich ist.

Der WebRTC-Leck-Mechanismus

Wenn ein Browser eine WebRTC-Verbindung initiiert, verwendet er JavaScript-APIs, um das Betriebssystem nach lokalen Netzwerkschnittstellen abzufragen und führt dann STUN-Anfragen durch, um seine öffentliche IP-Adresse zu ermitteln. Diese STUN-Anfragen basieren typischerweise auf UDP und werden oft direkt vom Browser oder der zugrunde liegenden WebRTC-Bibliothek gestellt, wodurch die für den allgemeinen Webverkehr konfigurierten HTTP/SOCKS-Proxy-Einstellungen umgangen werden.

Das RTCPeerConnection-Objekt des Browsers listet direkt lokale IP-Adressen auf und sendet STUN-Binding-Anfragen. Die Antworten von STUN-Servern enthalten die öffentliche IP-Adresse des Clients. Diese Informationen, einschließlich sowohl lokaler als auch öffentlicher IP-Kandidaten, werden dann dem entfernten Peer (oder, kritischerweise, der Website, die die WebRTC-Anwendung hostet) durch den ICE-Kandidatenaustauschprozess zur Verfügung gestellt.

Selbst wenn ein Proxy oder VPN verwendet wird, kann die WebRTC-Engine des Browsers möglicherweise immer noch diese direkten, nicht-proxiierten Verbindungen zu STUN-Servern herstellen oder lokale Netzwerkschnittstellen direkt abfragen, wodurch die wahre IP-Adresse des Benutzers offengelegt wird.

Beispiel: JavaScript IP-Offenlegung

Eine bösartige oder diagnostische Website kann mit wenigen Zeilen JavaScript eine WebRTC-Verbindung initiieren und diese ICE-Kandidaten extrahieren.

// Dies ist ein vereinfachtes Beispiel zu Illustrationszwecken.
// Eine reale Ausnutzung beinhaltet komplexere Kandidatensammlung.

function getWebRTCIPs() {
    return new Promise((resolve, reject) => {
        const pc = new RTCPeerConnection({
            iceServers: [{ urls: 'stun:stun.l.google.com:19302' }]
        });
        const candidates = [];

        pc.onicecandidate = (event) => {
            if (event.candidate) {
                const candidate = event.candidate.candidate;
                // Beispiel-Kandidatenstring:
                // "candidate:4234997380 1 udp 2043278322 192.168.1.100 50000 typ host" (lokale IP)
                // "candidate:4234997380 1 udp 2043278322 203.0.113.45 50000 typ srflx" (öffentliche IP via STUN)

                const ipMatch = /(?:[0-9]{1,3}\.){3}[0-9]{1,3}/.exec(candidate);
                if (ipMatch && ipMatch[0] && candidates.indexOf(ipMatch[0]) === -1) {
                    candidates.push(ipMatch[0]);
                }
            } else {
                // Alle ICE-Kandidaten wurden gesammelt
                if (candidates.length > 0) {
                    resolve(candidates);
                } else {
                    reject(new Error('No WebRTC IP candidates found.'));
                }
            }
        };

        pc.createDataChannel(''); // Benötigt einen Datenkanal, um die Kandidatensammlung auszulösen
        pc.createOffer()
            .then(offer => pc.setLocalDescription(offer))
            .catch(reject);
    });
}

// Verwendung:
// getWebRTCIPs().then(ips => console.log('Discovered IPs:', ips)).catch(error => console.error(error));

Dieser JavaScript-Code initiiert eine RTCPeerConnection und lauscht auf onicecandidate-Ereignisse. Jedes Ereignis enthält einen Kandidatenstring, der eine IP-Adresse (lokal, öffentlich über STUN oder weitergeleitet über TURN) enthält. Eine Website kann diese Kandidaten parsen, um die echten IP-Adressen zu extrahieren.

Ein WebRTC-Leck identifizieren

Um festzustellen, ob eine Proxy-Einrichtung anfällig für WebRTC-Lecks ist, können Online-Tools verwendet werden:

1. Besuchen Sie einen IP-Testdienst: Navigieren Sie zu Websites wie ipleak.net oder browserleaks.com/webrtc, während Sie über den Proxy verbunden sind.
2. Vergleichen Sie die gemeldeten IPs:
   • Proxy-IP: Dies ist die IP-Adresse, die der Proxy-Dienst dem Internet präsentieren sollte.
   • WebRTC-IP: Dieser Abschnitt listet IP-Adressen auf, die über WebRTC entdeckt wurden.
   • Ihre echte IP: Dies ist Ihre tatsächliche öffentliche IP-Adresse, die idealerweise verborgen sein sollte.

Wenn der Abschnitt "WebRTC-IP" Ihre tatsächliche öffentliche IP-Adresse anzeigt, liegt ein WebRTC-Leck vor. Wenn er Ihre lokale Netzwerk-IP (z. B. 192.168.x.x oder 10.x.x.x) anzeigt, deutet dies darauf hin, dass der Browser lokale Schnittstellen aufzählt, was Ihre öffentliche IP möglicherweise nicht direkt preisgibt, aber dennoch interne Netzwerkkonfigurationen offenbart.

Minderungsstrategien

Die Minderung von WebRTC-Lecks erfordert spezifische Maßnahmen, da Standard-Proxy-Konfigurationen oft nicht ausreichen.

Browser-Konfiguration und Erweiterungen

Verschiedene Browser bieten unterschiedliche Kontrollmöglichkeiten über WebRTC:

• Mozilla Firefox:

  • Geben Sie about:config in die Adressleiste ein.
  • Suchen Sie nach media.peerconnection.enabled und setzen Sie dessen Wert auf false. Dies deaktiviert WebRTC vollständig, was jedoch einige legitime Webanwendungen beeinträchtigen kann.
  • Alternativ suchen Sie nach media.peerconnection.ice.no_host_candidates und setzen Sie es auf true. Dies verhindert, dass der Browser lokale IP-Adressen offenlegt.
  • Suchen Sie nach media.peerconnection.ice.default_obfuscate_host_addresses und setzen Sie es auf true. Dies verschleiert lokale IP-Adressen, die von WebRTC gemeldet werden.

• Google Chrome / Chromium-basierte Browser:

  • Chrome bietet keine direkten Konfigurations-Flags in chrome://flags, um WebRTC vollständig zu deaktivieren, ohne andere Browserfunktionen zu beeinträchtigen.
  • Erweiterungen: Installieren Sie eine Browser-Erweiterung, die darauf ausgelegt ist, WebRTC-Lecks zu blockieren, wie z. B. "WebRTC Network Limiter" oder "uBlock Origin" mit spezifischen Filtern. Diese Erweiterungen ändern typischerweise das Verhalten der WebRTC-API des Browsers, um eine direkte IP-Offenlegung zu verhindern.
  • Die Erweiterung "WebRTC Network Limiter" funktioniert, indem sie Chrome so konfiguriert, dass nur "mDNS host candidates" oder "proxy-only ICE candidates" verwendet werden, wodurch die Arten der gesammelten und geteilten Kandidaten effektiv begrenzt werden.

• Opera:

  • Die integrierte VPN-Funktion von Opera beinhaltet manchmal einen WebRTC-Leckschutz. Wenn aktiviert, leitet sie den WebRTC-Verkehr durch das VPN. Überprüfen Sie die Einstellungen unter Einstellungen > Datenschutz & Sicherheit > VPN.

Betriebssystem-Ebene-Kontrollen

Obwohl weniger präzise, können OS-Ebene-Kontrollen den WebRTC-Verkehr einschränken:

• Firewall-Regeln: Blockieren Sie ausgehenden UDP-Verkehr auf gängigen STUN/TURN-Ports (z. B. 3478, 19302-19309). Dies kann verhindern, dass STUN-Anfragen externe Server erreichen, kann aber auch legitime WebRTC-Funktionalität beeinträchtigen.
• Netzwerkschnittstellenverwaltung: In einigen Szenarien kann das Deaktivieren spezifischer Netzwerkadapter verhindern, dass deren IP-Adressen aufgezählt werden, dies ist jedoch im Allgemeinen für den täglichen Gebrauch unpraktisch.

Proxy vs. VPN für WebRTC-Leckschutz

Der grundlegende Unterschied in der Funktionsweise von Proxys und VPNs beeinflusst ihre Fähigkeit, WebRTC-Lecks zu verhindern.

Ein VPN verschlüsselt und leitet den gesamten Netzwerkverkehr vom Gerät durch einen sicheren Tunnel, einschließlich des UDP-Verkehrs, der durch die STUN-Anfragen von WebRTC generiert wird. Dies stellt sicher, dass die einzige IP-Adresse, die externen STUN-Servern preisgegeben wird, die IP des VPN-Servers ist, wodurch ein WebRTC-Leck effektiv verhindert wird. Browser-Proxys hingegen arbeiten auf einer höheren Ebene und leiten möglicherweise nur TCP-Verkehr, wodurch UDP-WebRTC-Verbindungen direkt hergestellt werden können.

Für einen robusten Schutz vor WebRTC-Lecks und umfassende Privatsphäre ist eine vollständige System-VPN-Lösung im Allgemeinen effektiver als ein browserspezifischer Proxy. Bei der Verwendung eines Proxys sind spezifische Browser-Konfigurationen oder Erweiterungen zwingend erforderlich, um zu verhindern, dass WebRTC die echte IP-Adresse preisgibt.