Взлом городского мессенджера: как развивалась атака на машину Messenger в Standoff 365
Практически любое тестирование на проникновение начинается с разведки. На этом этапе специалист собирает сведения о целевой системе: определяет доступные сервисы, изучает веб-приложения, анализирует документацию API, версии программного обеспечения и возможные точки входа. Даже небольшая утечка технической информации способна повлиять на дальнейшую стратегию атаки.
В рассматриваемом сценарии исследуется учебная машина Messenger на платформе Standoff 365. Цель разбора - показать, как несколько aparentemente незначительных проблем могут объединиться в полноценную цепочку компрометации. В результате атака позволяет получить доступ к внутренней переписке разработчиков и извлечь ключ шифрования городского мессенджера.
Материал предназначен для образовательных целей. Описанные подходы следует применять только в лабораторной среде, на собственных системах или при наличии официального разрешения. Публикация не является призывом к незаконному доступу к информационным ресурсам.
Первый этап: разведка и инвентаризация сервисов
Начальным шагом стало сетевое сканирование. Оно показало, что на сервере открыты SSH и два HTTP-сервиса:
- порт 22 - OpenSSH 9.6p1 на Ubuntu;
- порт 80 - веб-сервер Nginx;
- порт 3000 - отдельное приложение, доступное через нестандартный порт.
На 80-м порту размещался городской мессенджер - самописное веб-приложение, предназначенное для корпоративного общения. На 3000-м порту работала платформа Gitness/Harness. Она используется для хранения Git-репозиториев и автоматизации процессов CI/CD.
Сам факт наличия двух приложений на одном хосте уже важен для анализа. Даже если основной мессенджер изолирован логически, соседний сервис может хранить исходный код, конфигурации, секреты или служебные учетные записи. Поэтому исследовать необходимо не только предполагаемую цель, но и всю связанную инфраструктуру.
Второй этап: изучение веб-приложения
Поскольку Messenger являлся собственной разработкой, рассчитывать на готовую уязвимость с идентификатором CVE не приходилось. Основное внимание пришлось уделить логике приложения, обработке пользовательских данных и взаимодействию компонентов между собой.
Перебор директорий и файлов помог обнаружить Swagger-документацию. Она содержала описание API, перечень маршрутов, используемые параметры и требования к авторизации. Для исследователя такая документация значительно сокращает время анализа, поскольку позволяет увидеть внутреннюю структуру приложения без полного перебора всех возможных запросов.
Авторизация была построена на JWT. Для доступа к защищенным функциям сначала создавалась обычная учетная запись, после чего выполнялся вход и получался токен. Далее функциональность приложения проверялась уже в рамках разрешений зарегистрированного пользователя.
Особое внимание привлекли функции, принимающие текстовые данные и отображающие их в интерфейсе. Мессенджер был разработан на Python с использованием FastAPI. Это само по себе не означает наличие проблемы, однако при таком стеке важно проверять серверный шаблонизатор, обработку входных параметров и границы между пользовательским вводом и командами приложения.
Третий этап: от SSTI к выполнению кода
В одной из функций была обнаружена серверная шаблонная инъекция - SSTI. Такая уязвимость возникает, когда данные пользователя подставляются в шаблон без безопасного экранирования, а затем обрабатываются сервером как выражение шаблонизатора.
На начальной стадии подобная проблема может выглядеть как возможность изменить отображаемый текст. Однако при небезопасной конфигурации шаблонизатор способен предоставить доступ к внутренним объектам Python, классам и функциям. В отдельных случаях это приводит к выполнению произвольных команд на сервере.
Ценность этой находки заключалась не только в самом факте SSTI. Уязвимость стала точкой входа в операционную систему и позволила перейти к следующему этапу - анализу окружения, учетных данных и доступных сетевых ресурсов.
Четвертый этап: изучение окружения и повышение привилегий
Получив выполнение команд с правами пользователя приложения, исследователь проверил конфигурацию системы, переменные окружения, запущенные процессы и доступные каталоги. В подобных местах нередко обнаруживаются ключи API, пароли сервисных учетных записей, строки подключения к базам данных и параметры внутренних интеграций.
Отдельно анализировались права текущего пользователя и возможные пути повышения привилегий. Даже если первоначальный доступ ограничен, служебные файлы, неправильно настроенные задания или чрезмерные разрешения могут позволить расширить контроль над системой.
Однако для реализации целевого бизнес-риска не всегда требуется получать права администратора операционной системы. Иногда достаточно доступа к внутреннему сервису, который хранит нужные данные или обладает более широкими полномочиями.
Пятый этап: компрометация Gitness
Следующим объектом стал сервис Gitness на порту 3000. Платформы управления исходным кодом и CI/CD особенно чувствительны с точки зрения безопасности: в репозиториях могут находиться исходники, файлы конфигурации, секреты, токены и инструкции развертывания.
После анализа окружения удалось установить связь между приложением Messenger и соседним сервисом. Доступ к внутренним данным позволил исследовать репозитории и учетные записи, связанные с разработкой мессенджера.
Главная опасность таких платформ заключается в том, что разработчики нередко считают внутренний Git-сервис доверенной зоной. В результате секреты могут попадать в историю коммитов, тестовые конфигурации или переменные CI/CD. Даже удаленный файл не гарантирует исчезновение данных: чувствительная информация часто остается в истории изменений.
Шестой этап: доступ к корпоративной переписке
Первый бизнес-риск заключался в получении доступа к переписке разработчиков городского мессенджера. Для этого анализировались служебные компоненты приложения и механизмы обмена сообщениями.
Внутренняя переписка особенно ценна для злоумышленника, поскольку может содержать сведения о структуре системы, обсуждение инцидентов, временные пароли, планы релизов и ссылки на внутренние сервисы. Даже сообщения, которые не содержат секретов напрямую, помогают восстановить архитектуру инфраструктуры.
Получение такого доступа демонстрирует, что защищать необходимо не только пользовательский интерфейс. Очереди сообщений, административные панели, фоновые обработчики и внутренние API должны рассматриваться как полноценные элементы периметра.
Седьмой этап: поиск ключа шифрования
Второй бизнес-риск был связан с извлечением ключа шифрования мессенджера. На этом этапе анализировалась внутренняя сеть и взаимодействие между приложением, брокером сообщений и хранилищами данных.
Поиск RabbitMQ
В инфраструктуре был обнаружен RabbitMQ - брокер сообщений, обеспечивающий обмен данными между компонентами приложения. Неправильная сегментация сети или слабая защита учетных данных может позволить обратиться к нему из скомпрометированного приложения.
Особое значение имеют очереди, маршруты и служебные сообщения. В них могут передаваться токены, параметры сессий, команды фоновых задач и другие чувствительные значения.
Анализ Redis
Дополнительным компонентом оказался Redis. Его часто используют для хранения сессий, кэша, временных ключей и очередей. Если Redis доступен без надежной аутентификации или размещен в сети, куда имеет доступ приложение, он становится важным источником информации.
В рассматриваемом сценарии исследователь анализировал структуру ключей и содержимое записей, не ограничиваясь только пользовательским интерфейсом. Именно внутренние хранилища нередко позволяют обнаружить значения, которые никогда не отображаются в браузере.
Как могла быть предотвращена атака
Основная мера защиты от SSTI - строгая обработка пользовательского ввода. Данные пользователя нельзя передавать в шаблонизатор как исполняемый шаблон. Необходимо применять контекстное экранирование, безопасные режимы рендеринга и проверку входных значений.
Swagger-документация не должна оставаться без контроля в рабочей среде. Если она необходима, доступ к ней следует ограничить, а сами API защищать не только JWT, но и проверкой ролей, сроком действия токенов и корректным отзывом сессий.
Gitness и аналогичные платформы нужно регулярно проверять на наличие секретов в репозиториях. Для этого применяются сканеры утечек, правила pre-commit и автоматическая ротация ключей. Секрет, однажды попавший в Git-историю, следует считать раскрытым даже после удаления файла.
RabbitMQ и Redis должны быть доступны только тем компонентам, которым они действительно необходимы. Важно использовать аутентификацию, шифрование соединений, сетевые политики, отдельные учетные записи и минимальные права. Запрещено полагаться лишь на то, что сервис находится во внутренней сети.
Итоги
Цепочка атаки показала, как серверная шаблонная инъекция, слабая изоляция сервисов и недостаточная защита внутренних компонентов превращают локальную ошибку в серьезный инцидент. Начав с обычного веб-приложения, исследователь смог перейти к инфраструктурным сервисам, получить доступ к переписке разработчиков и обнаружить ключ шифрования.
Для защиты подобных систем необходим комплексный подход: безопасная разработка, регулярный пентест, контроль секретов, сегментация сети, минимальные привилегии и постоянный аудит внутренних сервисов. Одна найденная уязвимость редко существует изолированно - наибольший риск возникает тогда, когда несколько слабых мест объединяются в единую цепочку.