Trust Chain Hijack: как REST API позволила провести эскалацию привилегий через междоменную уязвимость

Атака, использующая уязвимость отраженного XSS в доверенном поддомене для обхода CSP и эксплуатации REST API, обнаруженного через утечку документации. Цепочка атаки демонстрирует, как злоумышленник может использовать доверительные отношения между поддоменами и недостаточную изоляцию API для эскалации привилегий без прямого доступа к системе

Разведка началась стандартно: поддомены, порты, дорки. Ничего необычного, пока не выплёвывается интересный поддомен static.COMPANY.com с файлом api-provider.min.js.map. В файле вижу содержимое такого типа:

apiSpec: {
  openapi: "***",
  info: {
    title: "***",
    version: "v2"
  },
  url: "https://backend-api.COMPANY.com/api/v2/docs",
  ...

В коде обнаружился блок конфигурации с явной ссылкой на внутреннюю документацию, однако прямой запрос на https://backend-api.COMPANY.com/api/v2/docs или попытки его фаззинга, приводили к 404 ошибке, пошел смотреть индексацию и нахожу слепок N-года, а внутри код опенапи, если точнее - спефикация сваггера. В этом же разделе был указан эндпоинт, отвечающий за модификацию учетки пользователя, в частности, его привилегий (role_id), но с обычной учеткой ничего не поддавалось изменению (недостаточно прав), требовалась сессия более привилегированного пользователя, иначе говоря, сессия администратора. Поэтому я решил найти более подходящий вектор для этой атаки

Фронтенд имел относительно строгую CSP: default-src 'self'; script-src 'self' *.COMPANY.com; connect-src 'self' backend-api.COMPANY.com;. Это запрещало произвольные внешние запросы, но разрешало запросы из доверенных поддоменов (да, можно и стянуть любой поддомен, ибо стяжка динамическая, а не фиксированный диапазон)

На поддомене lib.COMPANY.com нашёл отражённую XSS в параметре topic - пользовательский ввод отражался в ответе без надёжной санитизации, немного колдовства, да и только. А поскольку этот поддомен находился в пределах доверенных источников CSP, из этого следовало, что скрипт в его контексте имеет право делать fetch/XHR к backend-api.COMPANY.com и использовать куки текущей сессии, например, если админ откроет страницу будучи залогиненным, достаточно будет заставить браузер администратора инициировать нужный запрос. Как я сказал, запросы на внешние ресурсы блочатся и надо проводить операцию в пределах скоупа CSP

1. Сначала подготовил примерно такую нагрузку (не poc, а похожая логика, фулл нагрузку не буду приводить):

(function(){var x=new XMLHttpRequest();x.open("PUT","https://backend-api.COMPANY.com/api/v2/users/update",true);x.setRequestHeader("Content-Type","application/json");x.withCredentials=true;x.send(JSON.stringify({"user_id":"***","role_id":"1"}));})();

2. Закодировал ее в base64 и обернул :

eval(atob('KGZ1bmN0aW9uKCl7dmFyIHg9bmV3IFhNTEh..'))

3. Финальный результат:

https://lib.COMPANY.com/q?topic=%22-fetch(eval.call%24%7B'eval%5Cx28atob%5Cx28%22BASE64_ЗАКОДИРОВАННЫЙ%22%5Cx29%5Cx29'%7D)//%22

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

Не самый распространенный, но интересный вектор для целевой атаки

Краткий вывод: атакующий запускает персонализированный фишинг через Telegram Mini-App: присылает официально выглядящее предложение с deeplink startapp, WebView загружает клон интерфейса (копию Fragment), подключает TON-интеграции (TON Connect / Tonkeeper) и добивается либо ввода сид/ключа, либо подписи транзакции/approve - в результате средства или контроль над NFT/allowance переходят атакующему

Атакующий реализует персонифицированный фишинг, где отправляет предложение о покупке логина, где, после непродолжительной беседы и торгов, атакующий пересылает сообщение-уведомление от якобы официального бота, прикрепляя к нему инлайн-кнопку на Telegram Mini-App, подгружающее внешнее dApp-приложение, имитирующее официальную площадку Fragment, ссылка в формате:

https://t.me/<bot>/... ?startapp=<логин>-<идентификтатор>

Параметр ?startapp=<логин> выполняет социнжиниринговую роль - при запуске мини-приложения WebView получает этот параметр и динамически вставляет целевой ник в заготовленный шаблон площадки Fragment и пользователь видит персонализированный интерфейс, полностью стилизованный под официальную площадку

В загружаемом коде присутствуют библиотеки/хелперы для работы с TON (условно tonconnect, tonweb или Tonkeeper hooks, как в этом случае) либо самописная логика, эмулирующая их API. UI предлагает подключить кошелёк и далее подтвердить получение средств. При попытке подключения запускается flow TON Connect / Tonkeeper: браузер/кошелёк получает запрос на соединение, а затем - запрос на подпись

Далее код приложения подгружает заготовленную нагрузку для подписи: либо прямую транзакцию, либо апрув (позволяющий контракту/спендору списывать токены в будущем), либо произвольное сообщение на подпись (что может использоваться для авторизации действий в других сервисах). В UI это кажется подтверждением сделки, но фактически пользователь подписывает операцию, дающую доступ атакующему к активам

Атакующий дополнительно прикладывает ссылку на блок-эксплорер (например tonviewer.com/...) и/или короткое демонстрационное видео (что я часто сейчас наблюдаю) - это таки микропрогрев для повышения доверия; наличие адреса в блок-эксплорере не подтверждает легитимность - это просто адрес и баланс

Мануал для параноиков: защита от IP-трекеров в ссылках

Часто начал замечать, как граждане дошкольного и школьного возраста раскрывают адреса пользователей при переходе по ссылкам, для примера возьмем телегу с возможностью создания ссылок с "двойным дном" (aka гиперссылка) - внешне безобидный ресурс маскирует логгер, раскрывая IP жертвы при клике, где невнимательность приводит к деанонимизации (для понимания, динамический адрес может раскрывать город, область или регион провайдера - что в целом дает базовое представление об ареале обитания пользователя)

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

Работает метод на Linux (/etc/hosts) и Windows (C:\Windows\System32\drivers\etc\hosts)

1.3.3.7  iplogger.com
1.3.3.7  maper.info
1.3.3.7  iplogger.ru
1.3.3.7  iplogger.co
1.3.3.7  2no.co
1.3.3.7  yip.su
....

Метод с hosts-файлом хорош для массовой защиты, но не ловит новые или редкие ссылки. Здесь dnsmasq с DNS-подменой и wildcard (на примере *iplogger.com) решает проблему автоматически без ручного листинга сотен доменов

Dnsmasq работает как локальный DNS-сервер: ловит все поддомены, масштабируется на тысячи трекеров, подходит для всей сети (роутер, несколько устройств), хорошая динамика, поддержка wildcard подстановки

В одном из недавних расследований наткнулся на хитрый вектор атаки - цепочка заражений через PyPI и requirements.txt из github репозиториев. Злоумышленники заливают в PyPI вредоносные пакеты с похожими именами (атака типа typosquatting) или подменяют популярные либы, а потом рассылают зараженные requirements.txt/setup.py по публичным репам. Даже обычные разрабы попадают в такую ловушку, слепо клонируя репозитории и выполняя тот же pip install -r requirements.txt или pip install <lib> без проверки сурсов или анализа

На скрине один из примеров, что мне недавно попался - интересный dropper/persistence мальвар для Linux систем. Скрипт скачивает исполняемый файл с удаленного сервера, делает его исполняемым и добавляет автозапуск в .bashrc

Идеальный foothold в CI/CD dev-окружениях. Один git clone и закреп на хосте. Поэтому, старайтесь проверять requirements.txt / setup.py перед установкой