В разборе машины Messenger на платформе Standoff 365 исследователь показал цепочку, которая начинается с обычной разведки и заканчивается доступом к корпоративной переписке и ключу шифрования. Сначала он нашёл веб-приложение и соседний сервис, а затем добрался до уязвимости в серверном рендеринге.

История полезна не только специалистам по ИБ. Она наглядно показывает, как одна ошибка в веб-приложении может потянуть за собой утечку данных, эскалацию прав и захват соседних сервисов.

Что это за явление

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

В этом кейсе ключевую роль сыграла уязвимость типа SSTI — внедрение в серверный шаблон. Если приложение без проверки подставляет пользовательский ввод в шаблон, сервер может начать интерпретировать его как код, а не как текст.

Такие ошибки особенно опасны в корпоративных сервисах. Там один удачный запрос может открыть не только чат, но и внутренние сервисы, секреты CI/CD и токены доступа. Похожую логику атак мы уже разбирали в материале про атаку на Coder, где слабое место тоже вывело злоумышленника к чувствительным данным.

Как это работает технически

Сначала исследователь провёл разведку: просканировал хост, нашёл HTTP-сервисы и отдельно заметил платформу для репозиториев и автоматизации. Потом он перебрал директории, нашёл Swagger-документацию и понял, что приложение работает с JWT-авторизацией.

Дальше началась ручная проверка функций. Одной из зацепок стала страница со сводкой по друзьям, которая отдавала не чистый JSON, а HTML, собранный на сервере. Это уже важный сигнал: если сервер сам строит разметку, в ней может оказаться место для инъекции шаблона.

Чтобы подтвердить гипотезу, автор пробовал отправлять шаблонные выражения в разные поля. Простая проверка вроде 7*7 не сработала с первым движком, но выражение в другом синтаксисе дало нужный результат — значит, на сервере использовали шаблонизатор, уязвимый к SSTI. После этого он смог перейти от проверки к выполнению произвольного кода.

Следующий шаг — повышение привилегий и исследование окружения. Здесь важен не только сам сервер мессенджера: после захвата одной машины атакующий часто ищет соседние сервисы, внутренние очереди, базы данных и инструменты разработки. Именно так в разборе под удар попал Gitness, а затем — сервисы с сообщениями и ключами шифрования.

Почему это опасно

Опасность в том, что атакующий не ограничивается одной страницей или одним пользователем. При удачном развитии цепочки он получает доступ к данным разработчиков, внутренней переписке, конфигурациям и секретам, которые открывают путь к другим системам.

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

Проблема усугубляется тем, что на первом этапе всё выглядит буднично: обычный логин, обычный поиск друзей, обычная HTML-страница. Именно поэтому подобные кейсы важны для разработчиков и администраторов: они показывают, как небезопасный рендеринг и слабая сегментация сети превращают мелкую ошибку в полноценный взлом.

Как понять, что риск касается вас

Если в вашем сервисе есть серверный рендеринг шаблонов, динамическая подстановка пользовательских данных в HTML и внутренние инструменты разработки рядом с боевым приложением — риск уже рядом. Особенно если фронтенд и бэкенд смешаны, а шаблоны строятся на лету.

Ещё один тревожный признак — когда внутренние сервисы доступны из той же сети, что и публичное приложение. Тогда одна уязвимость может открыть доступ не только к чату или профилю, но и к Git-серверу, очередям сообщений, базам данных и секретам сборки.

Если у вас периодически возникают странные ошибки в рендеринге, на странице появляются сырые директивы, а ответы сервера меняются после вставки необычных символов, это повод срочно проверить код и журналы. На стороне защиты полезно сверяться и с материалами вроде разбора уязвимости Magento и Adobe Commerce: логика там другая, но сценарий эскалации очень похож.

Меры защиты

Главное правило простое: не подставляйте пользовательский ввод в шаблон без строгой очистки и экранирования. Если вам нужно вывести данные на страницу, отделяйте данные от кода и не давайте серверу интерпретировать текст как инструкции.

Второй слой защиты — изоляция. Публичное приложение, репозитории, очереди сообщений и хранилища секретов не должны жить в одной плоской сети. Ограничивайте доступ между сервисами, режьте лишние права и проверяйте, что соседний компонент не станет трамплином для атаки.

Третий слой — наблюдаемость. Логи, алерты на необычные запросы, контроль шаблонов и регулярные ручные проверки помогают заметить SSTI раньше, чем она превратится в RCE. Для пользователей и команд, которые работают из кафе, аэропортов и других открытых сетей, отдельным полезным шагом остаётся защита трафика через инструмент для закрытого канала связи — он не чинит уязвимый сервер, но помогает уменьшить лишнюю видимость переписки и метаданных в дороге.

Практический чек-лист

  • Проверьте, не строит ли ваш сервер HTML на основе пользовательских полей.
  • Убедитесь, что шаблоны экранируют ввод и не исполняют его как код.
  • Разведите публичное приложение, Git-сервис, очереди и секреты по разным сегментам сети.
  • Ограничьте права сервисных аккаунтов и токенов доступа.
  • Включите журналирование необычных запросов и ошибок рендеринга.
  • Проверьте, не светятся ли внутренние документы, Swagger и тестовые эндпойнты наружу.
  • Пересмотрите доступ сотрудников к переписке, ключам и конфигурациям.
  • Для работы из открытых Wi-Fi используйте дополнительные меры защиты трафика и не вводите секреты в сомнительные сети.
Поделиться: