Безопасность контейнеризованных сред в AWS поставлена под сомнение после обнаружения критической уязвимости в сервисе Amazon Elastic Container Service (ECS). Исследователи выявили методику атаки, позволяющую злонамеренному контейнеру похищать высокопривилегированные учетные данные AWS у других задач, выполняющихся на том же экземпляре EC2, без необходимости выхода из контейнера (container breakout). Атака, получившая название "ECScape", эксплуатирует недокументированный внутренний протокол взаимодействия для кражи IAM-ролей, включая критически важные "execution roles".
Суть уязвимости, обнаруженной исследователем безопасности Наором Хазизом (Naor Haziz), кроется в фундаментальном аспекте архитектуры управления учетными данными ECS на общих хост-машинах. Когда на одном экземпляре EC2 запущено несколько контейнеров с разным уровнем привилегий, скомпрометированный контейнер с низкими привилегиями может получить доступ к учетным данным задач с более высокими правами. Хазиз наткнулся на проблему во время разработки инструмента мониторинга на базе eBPF, исследуя механизмы получения метаданных задачами ECS. Ключевым наблюдением стало обнаружение WebSocket-соединения между агентом ECS и управляющей плоскостью AWS, использующего параметр "sendCredentials=true" для передачи учетных данных.
Механизм атаки ECScape представляет собой многоэтапный процесс, не требующий выхода из контейнера, но нуждающийся в доступе к службе метаданных экземпляра (IMDS). Злоумышленник, контролирующий один контейнер, сначала похищает учетные данные IAM-роли, привязанной к самому экземпляру EC2, через запросы к IMDS. Используя эти украденные данные, атакующий определяет конечную точку управляющей плоскости ECS и собирает необходимые идентификаторы, такие как ARN кластера и ARN экземпляра контейнера. Затем устанавливается поддельное WebSocket-соединение, имитирующее легитимного агента ECS. Аутентификация выполняется с использованием похищенных учетных данных экземпляра. После установления соединения злоумышленник начинает получать через этот канал учетные данные IAM для *всех* задач, запущенных на этом хосте. Это включает как "task roles" (роли, используемые непосредственно приложением в контейнере), так и гораздо более привилегированные "execution roles".
Риски, создаваемые этой уязвимостью, чрезвычайно высоки, особенно в многопользовательских средах ECS. Нарушаются предполагаемые границы изоляции между контейнерами. Например, скомпрометированный контейнер сканера с доступом "только для чтения" может украсть учетные данные у соседнего контейнера, выполняющего резервное копирование базы данных и обладающего полными правами доступа к ней. Наиболее тревожным аспектом является экспозиция "execution roles". Эти роли, по замыслу архитектуры ECS, не должны быть доступны внутри контейнера приложения. Они обладают широкими правами, такими как доступ к AWS Secrets Manager для извлечения секретов приложения или к приватным реестрам контейнеров (ECR). Компрометация такой роли дает злоумышленнику доступ к критически важным ресурсам, выходящим далеко за пределы одного экземпляра EC2.
Обнаружение подобных инцидентов представляет значительную сложность. Поскольку атака приводит к получению действующих учетных данных, все последующие вызовы API, совершаемые злоумышленником с использованием украденных ролей, в журналах AWS CloudTrail выглядят как абсолютно легитимные действия, атрибутированные владельцу скомпрометированной роли. Это делает начальное обнаружение аномалии крайне трудным без глубокого анализа паттернов поведения задач и сопоставления действий с ожидаемой функциональностью каждой конкретной роли в системе.
Amazon Web Services предоставила рекомендации по смягчению рисков. Основная стратегия защиты заключается в строгом пересмотре политики размещения задач. AWS настоятельно рекомендует избегать совместного размещения задач с высоким уровнем привилегий и ненадежных контейнеров на одних и тех же экземплярах EC2. Для критически важных сервисов предлагается использование выделенных хостов (Dedicated Hosts) или, что предпочтительнее с точки зрения изоляции, миграция на AWS Fargate. Fargate обеспечивает изоляцию задач на уровне микро-ВМ, что исключает описанный вектор атаки, так как каждая задача выполняется в своей собственной изолированной среде, без общего хоста. Дополнительные меры включают ограничение доступа к IMDS с помощью настройки "ECS_AWSVPC_BLOCK_IMDS" (для задач, использующих сетевой режим awsvpc), обязательное применение IMDSv2 (который требует использования токена сессии, усложняя автоматическую эксплуатацию), и неукоснительное следование принципу минимальных привилегий при назначении IAM-ролей задачам. Организациям также следует отключать ненужные Linux capabilities у контейнеров для ограничения возможностей злоумышленника после потенциальной компрометации.
Раскрытие уязвимости ECScape поднимает фундаментальные вопросы о безопасности моделей совместного использования ресурсов в контейнерных оркестраторах. Оно наглядно демонстрирует, что даже в управляемых сервисах границы изоляции могут быть тоньше, чем предполагается, особенно при использовании общей инфраструктуры EC2. Хотя AWS не анонсировала планов по изменению базовой архитектуры протокола взаимодействия агента ECS с управляющей плоскостью, данное исследование служит веским аргументом в пользу выбора Fargate для рабочих нагрузок, обрабатывающих конфиденциальные данные или требующих максимального уровня изоляции. Инцидент подчеркивает необходимость для компаний тщательно оценивать модели риска при развертывании контейнеризованных приложений и понимать реальные границы безопасности, предоставляемые их облачной инфраструктурой.
