Детекция утечки IP через WebRTC: от бага к фиче

WebRTC — Web Real-Time Communication — был создан, чтобы обеспечить видеозвонки, обмен файлами и передачу данных peer-to-peer прямо в браузере. Чтобы установить такие соединения, браузерам нужно обнаружить собственные сетевые интерфейсы и согласовать связность с удалёнными пирами. В этом процессе участвуют серверы STUN (Session Traversal Utilities for NAT) и TURN (Traversal Using Relays around NAT), которые помогают браузерам определить свои публичные IP-адреса и пройти через NAT-фаерволы.

Побочный эффект оказался мощным: даже когда пользователь подключается через VPN, стек WebRTC браузера может раскрыть реальный IP-адрес за туннелем. Это происходит потому, что ICE-кандидаты WebRTC (Interactive Connectivity Establishment) включают адреса локальных сетевых интерфейсов, которые VPN не маскирует.

Как работает утечка

Когда браузер создаёт RTCPeerConnection и собирает ICE-кандидатов, он запрашивает STUN-серверы, чтобы определить свой публичный IP. Но он также перечисляет локальные сетевые интерфейсы — включая приватный IP физического адаптера. Если VPN туннелирует трафик только на уровне IP, но не настраивает стек WebRTC браузера так, чтобы тот использовал исключительно интерфейс туннеля, реальный IP утекает через host-кандидата.

В tracio.ai мы аккуратно зондируем это поведение. Наша система IP Intelligence формирует контролируемый STUN-запрос и анализирует ICE-кандидатов, которые возвращает браузер. Когда публичный IP из STUN отличается от IP, который мы видим на своём сервере, мы помечаем VPN или прокси. Когда IP локального интерфейса раскрывает диапазон приватной сети, противоречащий предполагаемому географическому положению, мы повышаем оценку подозрительности.

От бага к сигналу детекции

Большинство браузеров, ориентированных на приватность, закрыли эту утечку — Chrome требует явного разрешения пользователя для WebRTC, а Firefox предлагает настройки для отключения непроксированного UDP. Но гонка вооружений продолжается: некоторые VPN-клиенты неправильно настраивают WebRTC, старые версии браузеров остаются уязвимыми, а сам поведенческий паттерн «закрытого» и «утекающего» WebRTC-ответа уже является полезным сигналом.

Наш подход рассматривает WebRTC-ответ как составной сигнал: наличие host-кандидатов, количество возвращённых ICE-кандидатов, их типы (host, srflx, relay) и тайминг ответа — всё это вносит вклад в отпечаток устройства. Даже когда IP не утекает, паттерн поведения WebRTC остаётся отличительным.

Зондирование TURN-серверов

Помимо STUN мы также зондируем поведение TURN-серверов. TURN-реле обычно используются, когда прямые peer-to-peer соединения не удаются — это типично для корпоративных сетей за строгими фаерволами. Ответ на TURN-аллокацию раскрывает информацию о пути реле: транспортный протокол (UDP, TCP или TLS), адрес реле и время жизни аллокации.

Наша система SignalProbe отправляет тщательно сформированные запросы на TURN-аллокацию к нашим собственным серверам-реле. Время ответа, поддерживаемые транспорты и паттерны успеха/неуспеха аллокации различаются в зависимости от сетевого окружения и дают дополнительное разнообразие сигналов для отпечатка устройства.

Соображения приватности

Хотим прояснить: tracio.ai не эксплуатирует утечки WebRTC для деанонимизации пользователей. Наша система выявляет факт использования VPN и сообщает об этом как о сигнале риска. Мы никогда не храним и не раскрываем утёкший IP-адрес. Сигнал бинарный: «обнаружен VPN с несоответствием WebRTC» или «поведение WebRTC согласуется с прямым соединением».

Такой подход даёт командам по борьбе с фродом нужную им информацию — что посетитель маскирует своё реальное местоположение — не компрометируя приватность отдельного человека. Сигнал помогает выявлять скоординированные фрод-атаки, когда множество аккаунтов исходит из одного скрытого местоположения.