Ssylka

Как уязвимость ECScape обнажила системные риски в облачных средах?

На конференции Black Hat USA в Лас-Вегасе исследователь Наор Хазиз из компании Sweet Security представил информацию об уязвимости в Amazon Elastic Container Service (ECS), получившей название ECScape. Этот дефект позволяет создать полную цепочку эскалации привилегий, в рамках которой контейнер с низкими правами может похитить учетные данные AWS у любого другого контейнера, запущенного на том же хосте EC2, получая таким образом доступ к его более мощным разрешениям.
Как уязвимость ECScape обнажила системные риски в облачных средах?
Изображение носит иллюстративный характер

Атака эксплуатирует недокументированный внутренний протокол в ECS. На каждом хосте ECS работает специальная служба метаданных по IP-адресу 169.254.170[.]2, которая предоставляет временные учетные данные для IAM-роли каждой задачи. Суть атаки заключается в том, чтобы вредоносный контейнер выдал себя за легитимного агента ECS. Успешно имитируя его поведение, например, подтверждая сообщения, увеличивая порядковые номера и отправляя сигналы активности, контейнер обманывает систему.

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

Для минимизации риска рекомендуется избегать развертывания задач с высокими привилегиями рядом с недоверенными или низкопривилегированными задачами на одном экземпляре EC2. Использование AWS Fargate обеспечивает полную серверную изоляцию между задачами, устраняя проблему общего хоста. Также следует отключать или ограничивать доступ к службе метаданных экземпляра (IMDS) для задач, которые в этом не нуждаются, и жестко ограничивать разрешения самого агента ECS. Для обнаружения аномального использования IAM-ролей необходимо настроить оповещения с помощью CloudTrail.

Наор Хазиз сформулировал ключевой принцип защиты: «Относитесь к каждому контейнеру как к потенциально скомпрометированному и строго ограничивайте радиус его поражения».

ECScape — не единичный случай. Недавно была обнаружена уязвимость в Google Cloud Build, использующая состояние гонки в интеграции с GitHub. Она позволяла злоумышленнику обходить проверку со стороны сопровождающих и запускать сборку непроверенного кода после выдачи команды /gcbrun. В Oracle Cloud Infrastructure (OCI) была найдена ошибка удаленного выполнения кода (RCE) в OCI Code Editor, позволявшая захватить Cloud Shell жертвы и получить доступ к другим сервисам OCI через атаку "drive-by".

В экосистеме Microsoft была выявлена техника атаки I SPy, которая эксплуатирует сервисный принципал (SP) приложения Microsoft в Entra ID (ранее Azure AD) для сохранения присутствия в системе и повышения привилегий через федеративную аутентификацию. Другая уязвимость в Azure Machine Learning (AML) позволяла злоумышленнику с доступом только к Storage Account модифицировать скрипты вызова, выполнять произвольный код в конвейере AML, извлекать секреты из Azure Key Vaults и получать расширенный доступ.

Проблемы затрагивают и управляемые политики. Устаревшая политика AWS под названием AmazonGuardDutyFullAccess содержала уязвимость в области видимости, которая могла позволить полный захват организации из скомпрометированного аккаунта-участника. В Azure Arc была обнаружена техника злоупотребления ролью Azure Connected Machine Resource Administrator для эскалации привилегий и использования в качестве механизма персистентности для командно-контрольных (C2) серверов.

Исследователи также продемонстрировали, как связывание чрезмерно привилегированной встроенной роли Azure Reader с уязвимостью в API Azure может привести к утечке ключей VPN, предоставляя доступ к внутренним облачным активам и локальным сетям.

Серьезной угрозой для цепочки поставок стала уязвимость GerriScary (CVE-2025-1568, CVSS 8.8) в Google Gerrit. Она позволяла неавторизованно отправлять код как минимум в 18 проектов Google, включая ChromiumOS, Chromium, Dart и Bazel. Кроме того, была выявлена некорректная конфигурация в Google Cloud Platform (GCP), из-за которой подсети, используемые для обмена трафиком в точках обмена интернет-трафиком (IXP), оказались раскрыты, создавая риск злоупотребления инфраструктурой Google для доступа к внутренним сетям IXP.

Техника повышения привилегий ConfusedFunction, изначально обнаруженная в Google Cloud, была успешно адаптирована для работы на AWS (через Lambda) и Azure (через Azure Functions), а также расширена для перечисления ресурсов в облачной среде.

Группа киберразведки Cisco Talos рекомендует придерживаться трех основных стратегий для усиления облачной безопасности. Во-первых, все сервисные учетные записи (Service Accounts) в облачной среде должны строго соответствовать принципу наименьших привилегий. Во-вторых, необходимо полностью отказаться от использования устаревших облачных сервисных аккаунтов, заменив их новыми с минимально необходимыми правами. В-третьих, следует обеспечивать своевременное обновление всех облачных сервисов и их зависимостей последними патчами безопасности.


Новое на сайте