Виявлення витоку 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 відповідає прямому з'єднанню».

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