Что такое WebRTC, как он используется антифрод системами и как некоторые антидетект браузеры сдают вас им?

Что такое WebRTC?

WebRTC - это P2P-соединение, которое было создано для передачи любых данных в реальном времени между большим количеством кандидатов (клиентов), в основном для аудио. Для быстрой передачи данных был выбран UDP-протокол из-за того, что он позволяет отправлять данные без хендшейка и прочих механизмов компрессии, которые добавляют дополнительный оверхед.

Как антифрод системы используют WebRTC для детекта прокси?

Ответ на данный вопрос максимально прост - из-за того, что в основе WebRTC лежит UDP, а если немного подробнее, то из-за того, что многие антидетект-браузеры не поддерживают проксирование UDP, и вообще малая часть прокси умеет работать с ним.

Данная история тянется примерно с 2013 года: тогда были интегрированы первые максимально простые способы для детекта WebRTC, и в то же время были запущены чекеры на утечку DNS. Один из них знают многие - Browserleaks, к нему вернёмся немного позже.

Первые способы детекта были максимально примитивные, проверка выглядела так

var pc = new RTCPeerConnection({
  iceServers: [{ urls: "stun:stun.l.google.com:19302" }]
});

pc.createDataChannel("");

pc.onicecandidate = function(e) {
  if (!e.candidate) return;

  console.log(e.candidate.candidate);
};

pc.createOffer().then(o => pc.setLocalDescription(o));

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

const Orig = window.RTCPeerConnection;

window.RTCPeerConnection = function(cfg) {
  const pc = new Orig(cfg);

  pc.addEventListener("icecandidate", e => {
    if (e.candidate) {
      e.candidate.candidate =
        e.candidate.candidate.replace(
          /\d+\.\d+\.\d+\.\d+/,
          "127.0.0.1"
        );
    }
  });

  return pc;
};

Способ обхода, как и сама проверка, были максимально примитивными: достаточно было заинжектить на страницу скрипт, который при вызове icecandidate (это метод, который получает и возвращает список всех кандидатов) устанавливал любые адреса в ответ.

Некоторое время такая подмена работала, но антифроды не стоят на месте: в ход пошли двусторонние SRTP-проверки с валидацией на стороне сервера, и тогда же начались огромные волны банов, о которых, возможно, даже кто-то слышал. Например: Ticketmaster в 2018, Facebook в 2017–2018, Google в 2018–2019 и куча других сервисов.

Волны банов начались из-за того, что практически все тогда использовали классическую функцию подмены кандидатов на стороне клиента и не блокировали отправку WebRTC. Из-за того, что WebRTC начали проверять на сервере, он просто сопоставлял TCP-IP клиента и UDP-IP. В таком случае TCP-IP будет прокси, а UDP - устройства, с которого производится подключение. Простыми словами - утечка реального IP через WebRTC.

Тогда антидетект-браузеры начали просто блокировать WebRTC на уровне ядра браузера либо ломать стандартные функции для установки WebRTC-соединения, чтобы соединение на сервер не устанавливалось. Для антифрода это, конечно, подозрительно, но если нет других триггеров, подтверждающих подмену железа, использование прокси и т.д., то он просто записывает вас на карандаш.

Сейчас это работает не везде, особенно на посредственных антидетект-браузерах. За последние несколько лет антифрод-системы начали уделять огромное внимание железу, проверяя всё, что возможно - CPU, GPU, шрифты, CSS и т.д. Об этом я подробнее расскажу в следующей статье про виды антидетектов, как именно работает их многоуровневая проверка и почему даже на максимально «грязном» IP можно пройти некоторые антифрод-системы.

Из-за этого в последние годы всё чаще всплывают вопросы:
«Почему не удаётся решить Funcaptcha в Twitter, уже все виды прокси перепробовал?» или аналогичные вопросы по поводу Hcaptcha Enterprise и других антифрод-систем.

В данных ситуациях накладывается всё: грязные отпечатки, плохая подмена данных самим антиком, и заключительным гвоздём в крышку гроба становится WebRTC. Самое простое решение в данной ситуации - отключение прокси и блокировка WebRTC в профиле, а также раздача интернета с телефона или использование интернета с ПК, если нужно произвести действия с одного аккаунта. Если по отпечаткам не всё так плохо, то данный способ поможет, добавив дополнительные «баллы» за WebRTC и QUIC, но также бывают ситуации, когда это не помогает и нужно менять отпечатки.

Способ с раздачей интернета или использованием домашнего плох тем, что у аккаунта резко два раза меняется гео, и антифрод за такие манипуляции может забанить. Для Discord, Twitter и других соцсетей он ещё подходит, но если работа производится с FB Ads или любым другим сайтом, где стоит антифрод от Akamai, с огромной вероятностью аккаунт будет заблокирован. Поэтому единственное правильное решение, максимально минимизирующее шанс блокировки, - это использование прокси с поддержкой UDP и антидетекта с поддержкой его туннелирования.

Почему практически все чекеры на утечку WebRTC бесполезны, как антидетект браузеры обманывают вас благодаря им и могут и почему некоторые антидетект браузеры сдают вас антифродам?

В предыдущей главе был описан максимально старый, примитивный способ детекта и подмены WebRTC из 2013 года. До сих пор практически все чекеры и некоторая часть антидетект-браузеров используют данный способ. Из-за этого сервисы наподобие whoer, browserleaks, ipleak показывают неверную информацию, создавая иллюзию безопасности, но на деле у вас будет утекать реальный IP, если антидетект-браузер его не блокирует, либо он будет заблокирован, что подтолкнёт антифрод к дополнительной слежке и проверке.

Если вы используете антидетект-браузеры и прокси без поддержки UDP, убедитесь, что WebRTC отключён, т.к. до сих пор существует большое количество антидетект-браузеров, которые используют старый способ подмены без блокировки, и у вас будет утекать реальный IP. Пример утечки на скриншоте ниже.

Важно: если вы используете прокси с поддержкой UDP, TCP-IP и UDP-IP у вас могут отличаться, и это нормально, т.к. многие мобильные/домашние провайдеры используют Dual NAT или симметричный/CG-NAT. В таком случае по WebRTC будет получаться не ваш домашний IP, а IP вашего провайдера, который используется как точка входа в NAT. Такой вид NAT особенно распространён в Америке, например у T-Mobile USA.

Какие сервисы используют проверки WebRTC и как определить есть ли она там или нет?

Способов определения наличия проверки WebRTC на сайте несколько:

1. Сканирование сети через TCPdump, Wireshark и подобное ПО

Если на сайте есть вызов WebRTC, то в Wireshark или TCPdump вы увидите отправку STUN-соединений на сервер сервиса (см. скриншот ниже).

У данного способа есть масса минусов:

он слишком затратный по времени;
если вы ранее не работали с подобным ПО, то в первые разы будет сложно разобраться, как фильтровать и сканировать пакеты;
параллельно запущен Discord или другой сайт, использующий WebRTC, вы можете перепутать сервера;
сайт может маскировать передачу кандидатов под XMLHttpRequest или WebSocket, тогда вы не увидите отправку запроса к серверу.

2. Проверка сурсов сайта через DevTools

Открыв DevTools на сайте, можно через поиск по Sources найти функции для работы с WebRTC по ключевым словам: RTCPeerConnection, RTCIceCandidate, RTCSessionDescription, RTCDataChannel, iceConnectionState, iceTransport, createDataChannel. Также при необходимости можно поставить breakpoints и отдебажить.

Единственный минус этого способа в том, что сайт может быть обфусцирован, и будет тяжело что-то найти, например как у Funcaptcha.

3. Инжект в страницу скрипта, который будет присылать аллерты

Через Tampermonkey можно заинжектить скрипт, который будет слушать все события WebRTC и логировать их в консоль браузера.

На примере LinkedIn можно полностью увидеть все этапы, т.к. у них проверка вызывается сразу на главной странице.

На других антифродах может быть всё не так очевидно, т.к. чаще всего происходит инициализация WebRTC, а запрос отправляется только при наличии подозрений по более дешёвым проверкам (отпечатки и т.д.). Эту тему раскрою подробнее в следующей статье.

Инструкцию и сам скрипт для дебага вы можете найти в нашем гитбуке

Сервисы которые используют новый вид проверки WebRTC через SRTP

Arkose Labs (Funcatpcha Enterprise - Twitter, EpicGames, Roblox и тд)
Cloudflare Turnstile
Hcaptcha Enterprise (Discord, CoinBase, OpenSea, Kraken)
Akamai (Linode, Nike, Ticketmaster, Linkedin)
PerimeterX (StockX, Walmart)
DataDome
Kasada
SEON (Revolut, Bitpanda)
ThreatMetrix (PayPal, American Express)
Криптобиржи, неизвестные SaaS-решения (Binance, OKX, MEXC, Bybit и т.д.)

Как полноценно защититься от утечки WebRTC и не вызывать подозрения у антифрода его блокировкой.

Есть только один способ полностью защититься от этого — использовать прокси с поддержкой UDP и антидетект с поддержкой UDP-туннелирования либо стороннее ПО для проксирования процесса/всей системы.

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

Приобрести все виды прокси с подержкой UDP вы можете у нас на сайте, а так же ознакомиться в документации с ПО и антидетектами поддерживающими проксирование UDP.

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