Когда в проектах по анализу защищённости мы получаем RCE и пробиваем внешний периметр, возникает вопрос — есть ли на пробитом хосте выход в Интернет? Если есть, мы сможем установить быстрый канал с C2-сервером, настроить SOCKS-прокси для других тулов и продолжать работы. Но хост может оказаться глубоко в локальной сети, а доступ в Интернет — сильно порезан.
И тут полезно проверить, есть ли у заказчика специальный хост-ретранслятор для видеоконференций (ВКС) на внешнем периметре. Такие хосты называются TURN-серверами и используются для связи абонентов, которые не имеют прямой видимости, то есть находятся за NAT-ом (Traversal Using Relays around 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-креды.
