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

[ProxyShard]

Что такое 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-соединений на сервер сервиса (см. скриншот ниже).

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

1. он слишком затратный по времени;
2. если вы ранее не работали с подобным ПО, то в первые разы будет сложно разобраться, как фильтровать и сканировать пакеты;
3. параллельно запущен Discord или другой сайт, использующий WebRTC, вы можете перепутать сервера;
4. сайт может маскировать передачу кандидатов под 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-скрипта для определения, какие механизмы детекта может использовать сайт.

 

[Porosenok]

Спасибо, интересная статья.
Такой вопрос - а у некоторых антиков в настройках профиля в пункте WebRTC есть параметр "Google Forwarding". Чем это лучше/хуже просто подмены и передачи UDP IP прокси

 

[ProxyShard]

Спасибо, интересная статья.
Такой вопрос - а у некоторых антиков в настройках профиля в пункте WebRTC есть параметр "Google Forwarding". Чем это лучше/хуже просто подмены и передачи UDP IP прокси

Это что-то среднее между блокировкой и утечкой реального айпи. Запросы будут просто с google turn серверов отправляться, айпи реальный оно скроет, но будут просто айпи гугла, антифрод на такое стриггерится