Detekce úniku IP přes WebRTC: od chyby k funkci

WebRTC — Web Real-Time Communication — bylo navrženo pro videohovory, sdílení souborů a přímý peer-to-peer přenos dat přímo v prohlížeči. Aby prohlížeče tato spojení navázaly, musí zjistit svá vlastní síťová rozhraní a dohodnout se na konektivitě se vzdálenými protějšky. Tento proces zahrnuje servery STUN (Session Traversal Utilities for NAT) a TURN (Traversal Using Relays around NAT), které prohlížečům pomáhají zjistit jejich veřejné IP adresy a projít přes NAT firewally.

Vedlejší efekt je mocný: i když se uživatel připojuje přes VPN, může zásobník WebRTC v prohlížeči odhalit skutečnou IP adresu za tunelem. Děje se to proto, že kandidáti WebRTC ICE (Interactive Connectivity Establishment) obsahují adresy lokálních síťových rozhraní, které VPN nemaskuje.

Jak únik funguje

Když prohlížeč vytvoří RTCPeerConnection a shromažďuje ICE kandidáty, dotazuje se STUN serverů, aby zjistil svou veřejnou IP. Zároveň však vyčísluje lokální síťová rozhraní — včetně privátní IP fyzického adaptéru. Pokud VPN tuneluje provoz jen na úrovni IP, ale nenakonfiguruje zásobník WebRTC v prohlížeči tak, aby výhradně používal rozhraní tunelu, skutečná IP unikne skrze host kandidáta.

Ve společnosti tracio.ai toto chování pečlivě sondujeme. Náš systém IP Intelligence vytvoří řízený STUN požadavek a analyzuje ICE kandidáty, které prohlížeč vrátí. Když se veřejná IP ze STUN liší od IP, kterou vidíme na našem serveru, označíme VPN nebo proxy. Když IP lokálního rozhraní odhalí rozsah privátní sítě, který je v rozporu s údajnou geografickou polohou, zvýšíme skóre podezřelosti.

Od chyby k detekčnímu signálu

Většina prohlížečů zaměřených na soukromí tento únik opravila — Chrome vyžaduje pro WebRTC výslovné svolení uživatele a Firefox nabízí nastavení pro vypnutí neproxovaného UDP. Závody ve zbrojení však pokračují: některé VPN klienty WebRTC správně nekonfigurují, starší verze prohlížečů zůstávají zranitelné a samotný vzorec chování „opravené“ versus „unikající“ odpovědi WebRTC je sám o sobě užitečným signálem.

Náš přístup zachází s odpovědí WebRTC jako se složeným signálem: přítomnost host kandidátů, počet vrácených ICE kandidátů, typy kandidátů (host, srflx, relay) i časování odpovědi — to vše přispívá k otisku zařízení. I když žádná IP neunikne, vzorec chování WebRTC je výrazný.

Sondování TURN serverů

Kromě STUN sondujeme také chování TURN serverů. TURN relays se typicky používají, když přímá peer-to-peer spojení selžou — což je běžné v korporátních sítích za přísnými firewally. Odpověď na alokaci TURN odhalí informace o cestě přes relay: transportní protokol (UDP versus TCP versus TLS), adresu relay a dobu platnosti alokace.

Náš systém SignalProbe zasílá pečlivě sestavené požadavky na alokaci TURN na naše vlastní relay servery. Doba odezvy, podporované transporty a vzorce úspěchu/selhání alokace se liší podle síťového prostředí a poskytují další rozmanitost signálů pro fingerprinting zařízení.

Ohledy na soukromí

Chceme jasně říct: tracio.ai nezneužívá úniky WebRTC k deanonymizaci uživatelů. Náš systém detekuje, kdy je VPN v provozu, a hlásí to jako rizikový signál. Uniklou IP adresu nikdy neukládáme ani nezveřejňujeme. Signál je binární: „VPN detekována s nekonzistencí WebRTC“ nebo „chování WebRTC odpovídá přímému připojení“.

Tento přístup poskytuje týmům pro prevenci podvodů informace, které potřebují — návštěvník maskuje svou skutečnou polohu — aniž by to ohrozilo soukromí jednotlivce. Signál pomáhá odhalovat koordinované podvodné útoky, kdy více účtů pochází ze stejné skryté lokality.