Carder.life

Carder.life (http://txgate.io:443/index.php)
-   Новости мирового кардинга (http://txgate.io:443/forumdisplay.php?f=18)
-   -   Атака whoAMI позволяла выполнить код в Amazon EC2 (http://txgate.io:443/showthread.php?t=7775)

Artifact 01-05-2025 09:25 PM


Специалисты DataDog рассказали об атаке типа name confusion, которая получила название https://securitylabs.datadoghq.com/a...fusion-attack/. Любой, кто публиковал образ Amazon Machine Image (AMI) с определенным именем, мог получить доступ к учетной записи Amazon Web Services.
Эксперты рассказали, что атака была разработана еще в августе 2024 года. Они https://youtu.be/l-WEXFJd-Bo, что злоумышленник мог добиться выполнения произвольного кода в контексте учетной записи AWS, эксплуатируя то, каким образом обычно осуществляется работа с идентификаторами AMI.
Компания Amazon подтвердила наличие уязвимости и исправила ее еще в сентябре прошлого года, однако проблема сохраняется на стороне клиента в тех средах, где организации не обновляют код.
AMI представляют собой предварительно сконфигурированные и оснащенные необходимым софтом (операционной системой, приложениями) виртуальные машины, которые применяются для создания виртуальных серверов в экосистеме AWS, называемых EC2 (Elastic Compute Cloud).
Существуют публичные и приватные AMI, и все они имеют специфические идентификаторы. В случае с общедоступными AMI пользователи могут найти нужный идентификатор в каталоге AWS. Чтобы убедиться, что AMI происходит из надежного источника, в поиске следует указывать атрибут owner, иначе возрастает риск атаки типа whoAMI.
В DataDog объясняют, что атака whoAMI становится возможной из-за неправильной настройки выбора AMI в средах AWS в следующих ситуациях:<ul><li>получение AMI программами, использующими API ec2https://txgate.io/images/smilies/mosking.gifescribeImages, без указания владельца (owner);</li>
</ul><ul><li>скрипты используют wildcard вместо конкретных идентификаторов AMI;</li>
</ul><ul><li>некоторые IaC-инструменты (такие как Terraform) используют параметр most_recent=true, автоматически выбирая последний AMI, соответствующий фильтру.</li>
</ul>Перечисленные условия позволяют злоумышленнику внедрять вредоносные AMI в процесс выбора. Если owner не указан, то AWS возвращает все подходящие AMI, включая вредоносные.
https://xakep.ru/wp-content/uploads/...i-planting.jpg
Если параметр most_recent имеет значение true, система жертвы «видит» все последние AMI, добавленные на маркетплейс AWS, среди которых может быть вредоносный, имя которого схоже с легитимным.
По сути, злоумышленнику достаточно иметь учетную запись AWS, чтобы опубликовать свой вредоносный AMI в публичном каталоге Community AMI и выбрать имя, которое имитирует целевой AMI доверенного владельца.
https://xakep.ru/wp-content/uploads/...ttack-flow.png
После того как исследователи уведомили Amazon об этой угрозе, компания подтвердила, что внутренние непроизводственные системы были уязвимы перед whoAMI. Как уже упоминалось выше, уязвимость была исправлена в сентябре прошлого года, а 1 декабря 2024 года в AWS появился новый защитный механизм под названием «Разрешенные AMI» (Allowed AMIs), позволяющий клиентам создавать списки доверенных поставщиков AMI.
Разработчики AWS подчеркивают, что уязвимость использовалась только в рамках тестов, проведенных исследователями, и данные клиентов не пострадали в результате атак whoAMI.
Amazon рекомендует клиентам всегда указывать владельца AMI при использовании API ec2https://txgate.io/images/smilies/mosking.gifescribeImages и активировать функцию Allowed AMIs для дополнительной защиты.
https://xakep.ru/2025/02/14/whoami/


All times are GMT. The time now is 12:44 AM.

Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2025, vBulletin Solutions, Inc.