Detektering av WebRTC-IP-läckor: från bugg till funktion

WebRTC — Web Real-Time Communication — konstruerades för att möjliggöra videosamtal, fildelning och peer-to-peer-dataöverföring direkt i webbläsaren. För att upprätta dessa anslutningar behöver webbläsare upptäcka sina egna nätverksgränssnitt och förhandla om anslutningsbarhet med fjärranslutna peers. Denna process involverar STUN-servrar (Session Traversal Utilities for NAT) och TURN-servrar (Traversal Using Relays around NAT) som hjälper webbläsare att upptäcka sina publika IP-adresser och passera NAT-brandväggar.

Sidoeffekten är kraftfull: även när en användare ansluter via ett VPN kan webbläsarens WebRTC-stack avslöja den riktiga IP-adressen bakom tunneln. Detta sker eftersom WebRTC ICE-kandidater (Interactive Connectivity Establishment) inkluderar adresser till lokala nätverksgränssnitt som VPN:et inte maskerar.

Hur läckan fungerar

När en webbläsare skapar en RTCPeerConnection och samlar in ICE-kandidater frågar den STUN-servrar för att upptäcka sin utåtvända IP-adress. Men den räknar också upp lokala nätverksgränssnitt — inklusive den fysiska adapterns privata IP-adress. Om VPN:et bara tunnlar trafik på IP-lagret men inte konfigurerar webbläsarens WebRTC-stack att uteslutande använda tunnelgränssnittet, läcker den riktiga IP-adressen ut genom host-kandidaten.

På tracio.ai undersöker vi detta beteende noggrant. Vårt IP Intelligence-system skapar en kontrollerad STUN-förfrågan och analyserar de ICE-kandidater som webbläsaren returnerar. När den publika IP-adressen från STUN skiljer sig från den IP-adress vi ser vid vår server, flaggar vi ett VPN eller en proxy. När den lokala gränssnitts-IP:n avslöjar ett privat nätverksintervall som motsäger den påstådda geografiska platsen, höjer vi misstankepoängen.

Från bugg till detekteringssignal

De flesta integritetsfokuserade webbläsare har åtgärdat denna läcka — Chrome kräver uttryckligt användartillstånd för WebRTC, och Firefox erbjuder inställningar för att inaktivera icke-proxad UDP. Men kapprustningen fortsätter: vissa VPN-klienter konfigurerar inte WebRTC korrekt, äldre webbläsarversioner förblir sårbara, och själva beteendemönstret hos ett "åtgärdat" kontra "läckande" WebRTC-svar är i sig en användbar signal.

Vårt tillvägagångssätt behandlar WebRTC-svaret som en sammansatt signal: förekomsten av host-kandidater, antalet returnerade ICE-kandidater, kandidattyperna (host, srflx, relay) och svarstiden bidrar alla till enhetens fingeravtryck. Även när ingen IP-adress läcker är mönstret i WebRTC-beteendet distinkt.

Undersökning av TURN-servrar

Utöver STUN undersöker vi även TURN-servrarnas beteende. TURN-reläer används vanligtvis när direkta peer-to-peer-anslutningar misslyckas — vanligt i företagsnätverk bakom strikta brandväggar. TURN-allokeringssvaret avslöjar information om relävägen: transportprotokollet (UDP kontra TCP kontra TLS), reläadressen och allokeringens livslängd.

Vårt SignalProbe-system skickar noggrant utformade TURN-allokeringsförfrågningar till våra egna reläservrar. Svarstiden, de transporter som stöds och mönstren för lyckad/misslyckad allokering varierar med nätverksmiljön och ger ytterligare signaldiversitet för enhetsfingeravtryck.

Integritetsöverväganden

Vi vill vara tydliga: tracio.ai utnyttjar inte WebRTC-läckor för att avanonymisera användare. Vårt system upptäcker när ett VPN används och rapporterar detta som en risksignal. Vi lagrar eller exponerar aldrig den läckta IP-adressen. Signalen är binär: "VPN upptäckt med WebRTC-inkonsekvens" eller "WebRTC-beteende förenligt med direktanslutning".

Detta tillvägagångssätt ger team för bedrägeriförebyggande den information de behöver — att en besökare maskerar sin riktiga plats — utan att kompromissa med individens integritet. Signalen hjälper till att upptäcka koordinerade bedrägeriattacker där flera konton härrör från samma dolda plats.