✔Атака whoAMI позволяла выполнить код в Amazon EC2 - «Новости»

15 февраля 2025 692 Новости / Типы носителей / Изображения / Преимущества стилей / Списки / Текст 0

Эксперты рассказали, что атака была разработана еще в августе 2024 года. Они продемонстрировали, что злоумышленник мог добиться выполнения произвольного кода в контексте учетной записи AWS, эксплуатируя то, каким образом обычно осуществляется работа с идентификаторами AMI.

Компания Amazon подтвердила наличие уязвимости и исправила ее еще в сентябре прошлого года, однако проблема сохраняется на стороне клиента в тех средах, где организации не обновляют код.

AMI представляют собой предварительно сконфигурированные и оснащенные необходимым софтом (операционной системой, приложениями) виртуальные машины, которые применяются для создания виртуальных серверов в экосистеме AWS, называемых EC2 (Elastic Compute Cloud).

Существуют публичные и приватные AMI, и все они имеют специфические идентификаторы. В случае с общедоступными AMI пользователи могут найти нужный идентификатор в каталоге AWS. Чтобы убедиться, что AMI происходит из надежного источника, в поиске следует указывать атрибут owner, иначе возрастает риск атаки типа whoAMI.

В DataDog объясняют, что атака whoAMI становится возможной из-за неправильной настройки выбора AMI в средах AWS в следующих ситуациях:

получение AMI программами, использующими API ec2:DescribeImages, без указания владельца (owner);

скрипты используют wildcard вместо конкретных идентификаторов AMI;

некоторые IaC-инструменты (такие как Terraform) используют параметр most_recent=true, автоматически выбирая последний AMI, соответствующий фильтру.

Перечисленные условия позволяют злоумышленнику внедрять вредоносные AMI в процесс выбора. Если owner не указан, то AWS возвращает все подходящие AMI, включая вредоносные.

Если параметр most_recent имеет значение true, система жертвы «видит» все последние AMI, добавленные на маркетплейс AWS, среди которых может быть вредоносный, имя которого схоже с легитимным.

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

После того как исследователи уведомили Amazon об этой угрозе, компания подтвердила, что внутренние непроизводственные системы были уязвимы перед whoAMI. Как уже упоминалось выше, уязвимость была исправлена в сентябре прошлого года, а 1 декабря 2024 года в AWS появился новый защитный механизм под названием «Разрешенные AMI» (Allowed AMIs), позволяющий клиентам создавать списки доверенных поставщиков AMI.

Разработчики AWS подчеркивают, что уязвимость использовалась только в рамках тестов, проведенных исследователями, и данные клиентов не пострадали в результате атак whoAMI.

Amazon рекомендует клиентам всегда указывать владельца AMI при использовании API ec2:DescribeImages и активировать функцию Allowed AMIs для дополнительной защиты.

Специалисты DataDog рассказали об атаке типа name confusion, которая получила название whoAMI. Любой, кто публиковал образ Amazon Machine Image (AMI) с определенным именем, мог получить доступ к учетной записи Amazon Web Services. Эксперты рассказали, что атака была разработана еще в августе 2024 года. Они продемонстрировали, что злоумышленник мог добиться выполнения произвольного кода в контексте учетной записи AWS, эксплуатируя то, каким образом обычно осуществляется работа с идентификаторами AMI. Компания Amazon подтвердила наличие уязвимости и исправила ее еще в сентябре прошлого года, однако проблема сохраняется на стороне клиента в тех средах, где организации не обновляют код. AMI представляют собой предварительно сконфигурированные и оснащенные необходимым софтом (операционной системой, приложениями) виртуальные машины, которые применяются для создания виртуальных серверов в экосистеме AWS, называемых EC2 (Elastic Compute Cloud). Существуют публичные и приватные AMI, и все они имеют специфические идентификаторы. В случае с общедоступными AMI пользователи могут найти нужный идентификатор в каталоге AWS. Чтобы убедиться, что AMI происходит из надежного источника, в поиске следует указывать атрибут owner, иначе возрастает риск атаки типа whoAMI. В DataDog объясняют, что атака whoAMI становится возможной из-за неправильной настройки выбора AMI в средах AWS в следующих ситуациях: получение AMI программами, использующими API ec2:DescribeImages, без указания владельца (owner); скрипты используют wildcard вместо конкретных идентификаторов AMI; некоторые IaC-инструменты (такие как Terraform) используют параметр most_recent=true, автоматически выбирая последний AMI, соответствующий фильтру. Перечисленные условия позволяют злоумышленнику внедрять вредоносные AMI в процесс выбора. Если owner не указан, то AWS возвращает все подходящие AMI, включая вредоносные. Если параметр most_recent имеет значение true, система жертвы «видит» все последние AMI, добавленные на маркетплейс AWS, среди которых может быть вредоносный, имя которого схоже с легитимным. По сути, злоумышленнику достаточно иметь учетную запись AWS, чтобы опубликовать свой вредоносный AMI в публичном каталоге Community AMI и выбрать имя, которое имитирует целевой AMI доверенного владельца. После того как исследователи уведомили Amazon об этой угрозе, компания подтвердила, что внутренние непроизводственные системы были уязвимы перед whoAMI. Как уже упоминалось выше, уязвимость была исправлена в сентябре прошлого года, а 1 декабря 2024 года в AWS появился новый защитный механизм под названием «Разрешенные AMI» (Allowed AMIs), позволяющий клиентам создавать списки доверенных поставщиков AMI. Разработчики AWS подчеркивают, что уязвимость использовалась только в рамках тестов, проведенных исследователями, и данные клиентов не пострадали в результате атак whoAMI. Amazon рекомендует клиентам всегда указывать владельца AMI при использовании API ec2:DescribeImages и активировать функцию Allowed AMIs для дополнительной защиты.

Цитирование статьи, картинки - фото скриншот - Rambler News Service.

Иллюстрация к статье - Яндекс. Картинки.

Есть вопросы. Напишите нам.

Общие правила поведения на сайте.