Wykrywanie wycieku IP przez WebRTC: od błędu do funkcji

WebRTC — Web Real-Time Communication — zaprojektowano, aby umożliwić rozmowy wideo, udostępnianie plików i bezpośredni transfer danych peer-to-peer w przeglądarce. Aby nawiązać te połączenia, przeglądarki muszą wykryć własne interfejsy sieciowe i wynegocjować łączność ze zdalnymi partnerami. Proces ten wykorzystuje serwery STUN (Session Traversal Utilities for NAT) i TURN (Traversal Using Relays around NAT), które pomagają przeglądarkom wykryć ich publiczne adresy IP i przejść przez zapory NAT.

Efekt uboczny jest potężny: nawet gdy użytkownik łączy się przez VPN, stos WebRTC przeglądarki może ujawnić prawdziwy adres IP kryjący się za tunelem. Dzieje się tak, ponieważ kandydaci ICE (Interactive Connectivity Establishment) w WebRTC zawierają adresy lokalnych interfejsów sieciowych, których VPN nie maskuje.

Jak działa wyciek

Gdy przeglądarka tworzy RTCPeerConnection i zbiera kandydatów ICE, odpytuje serwery STUN, aby wykryć swój publiczny adres IP. Ale wylicza także lokalne interfejsy sieciowe — w tym prywatny adres IP fizycznej karty sieciowej. Jeśli VPN tuneluje ruch tylko na warstwie IP, ale nie konfiguruje stosu WebRTC przeglądarki tak, by korzystał wyłącznie z interfejsu tunelu, prawdziwy adres IP wycieka przez kandydata host.

W tracio.ai badamy to zachowanie starannie. Nasz system IP Intelligence tworzy kontrolowane żądanie STUN i analizuje kandydatów ICE zwróconych przez przeglądarkę. Gdy publiczny adres IP ze STUN różni się od adresu, który widzimy na naszym serwerze, oznaczamy użycie VPN lub proxy. Gdy adres IP lokalnego interfejsu ujawnia zakres sieci prywatnej sprzeczny z rzekomą lokalizacją geograficzną, podnosimy wynik podejrzenia.

Od błędu do sygnału wykrywania

Większość przeglądarek nastawionych na prywatność załatała ten wyciek — Chrome wymaga wyraźnej zgody użytkownika na WebRTC, a Firefox oferuje ustawienia wyłączające nieproksowany UDP. Ale wyścig zbrojeń trwa: niektóre klienty VPN nie konfigurują WebRTC poprawnie, starsze wersje przeglądarek pozostają podatne, a sam wzorzec zachowania „załatanej” kontra „przeciekającej” odpowiedzi WebRTC jest użytecznym sygnałem.

Nasze podejście traktuje odpowiedź WebRTC jako sygnał złożony: obecność kandydatów host, liczba zwróconych kandydatów ICE, typy kandydatów (host, srflx, relay) oraz czas odpowiedzi — wszystko to składa się na fingerprint urządzenia. Nawet gdy żaden adres IP nie wycieka, wzorzec zachowania WebRTC jest charakterystyczny.

Sondowanie serwera TURN

Poza STUN badamy również zachowanie serwera TURN. Przekaźniki TURN są zwykle używane, gdy bezpośrednie połączenia peer-to-peer zawodzą — co jest częste w sieciach korporacyjnych za restrykcyjnymi zaporami. Odpowiedź na alokację TURN ujawnia informacje o ścieżce przekaźnika: protokół transportowy (UDP kontra TCP kontra TLS), adres przekaźnika oraz czas życia alokacji.

Nasz system SignalProbe wysyła starannie spreparowane żądania alokacji TURN do naszych własnych serwerów przekaźnikowych. Czas odpowiedzi, obsługiwane transporty oraz wzorce sukcesu/niepowodzenia alokacji różnią się w zależności od środowiska sieciowego i zapewniają dodatkową różnorodność sygnału na potrzeby fingerprintingu urządzeń.

Kwestie prywatności

Chcemy jasno powiedzieć: tracio.ai nie wykorzystuje wycieków WebRTC do deanonimizacji użytkowników. Nasz system wykrywa, kiedy używany jest VPN, i zgłasza to jako sygnał ryzyka. Nigdy nie przechowujemy ani nie ujawniamy wyciekłego adresu IP. Sygnał jest binarny: „wykryto VPN z niespójnością WebRTC” lub „zachowanie WebRTC spójne z połączeniem bezpośrednim”.

To podejście daje zespołom przeciwdziałającym oszustwom potrzebne im informacje — że odwiedzający maskuje swoją prawdziwą lokalizację — bez naruszania prywatności jednostki. Sygnał pomaga wykrywać skoordynowane ataki oszustów, w których wiele kont pochodzi z tej samej ukrytej lokalizacji.