Атака whoAMI позволяла выполнить код в Amazon EC2 - «Новости» » Самоучитель CSS
Меню
Наши новости
Учебник CSS

Невозможно отучить людей изучать самые ненужные предметы.

Введение в CSS
Преимущества стилей
Добавления стилей
Типы носителей
Базовый синтаксис
Значения стилевых свойств
Селекторы тегов
Классы
CSS3

Надо знать обо всем понемножку, но все о немногом.

Идентификаторы
Контекстные селекторы
Соседние селекторы
Дочерние селекторы
Селекторы атрибутов
Универсальный селектор
Псевдоклассы
Псевдоэлементы

Кто умеет, тот делает. Кто не умеет, тот учит. Кто не умеет учить - становится деканом. (Т. Мартин)

Группирование
Наследование
Каскадирование
Валидация
Идентификаторы и классы
Написание эффективного кода

Самоучитель CSS

Вёрстка
Изображения
Текст
Цвет
Линии и рамки
Углы
Списки
Ссылки
Дизайны сайтов
Формы
Таблицы
CSS3
HTML5

Новости

Блог для вебмастеров
Новости мира Интернет
Сайтостроение
Ремонт и советы
Все новости

Справочник CSS

Справочник от А до Я
HTML, CSS, JavaScript

Афоризмы

Афоризмы о учёбе
Статьи об афоризмах
Все Афоризмы

Видео Уроки


Наш опрос



Наши новости

      
  • 24 марта 2016, 16:20
15-02-2025, 00:00
Атака whoAMI позволяла выполнить код в Amazon EC2 - «Новости»
Рейтинг:
Категория: Новости

Специалисты 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.
Иллюстрация к статье - Яндекс. Картинки.
Есть вопросы. Напишите нам.
Общие правила  поведения на сайте.

Специалисты 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 для дополнительной защиты.
Просмотров: 536
Комментариев: 0:   15-02-2025, 00:00
Уважаемый посетитель, Вы зашли на сайт как незарегистрированный пользователь. Мы рекомендуем Вам зарегистрироваться либо войти на сайт под своим именем.

 
Еще новости по теме:



Другие новости по теме: