Найти в Дзене
Герман Геншин

Уязвимости стандартных IAM ролей AWS: открывая двери для атак и угрожая безопасности аккаунтов

Исследователи в области кибербезопасности выявили опасные стандартные роли управления идентификацией и доступом (IAM), которые могут серьезно ослабить безопасность Amazon Web Services. Они предоставляют злоумышленникам возможность повышать свои привилегии, вмешиваться в работу других сервисов AWS и в некоторых случаях полностью захватывать аккаунты AWS.

«Эти роли, часто создаваемые автоматически или рекомендуемые в процессе настройки, предоставляют слишком широкие полномочия, например, полный доступ к S3», - подчеркивают исследователи компании Aqua Якир Кадкод и Офек Итах в своем анализе. «Эти стандартные роли незаметно открывают пути для атак, позволяя повышать привилегии, получать доступ к другим сервисам и даже потенциально компрометировать аккаунт.»

Компания по обеспечению безопасности облачных технологий сообщает, что обнаружила проблемы безопасности в стандартных IAM ролях, созданных сервисами AWS, такими как SageMaker, Glue, EMR и Lightsail. Похожая проблема также была выявлена в популярном открытом фреймворке Ray, который автоматически создает стандартную IAM роль (ray-autoscaler-v1) с политикой AmazonS3FullAccess.

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

Эти атаки выходят за рамки простых манипуляций с ведрами и могут возникать в сценарии, когда злоумышленник использует предсказуемые шаблоны именования S3 ведер для создания ведер в неиспользуемых регионах AWS, в конечном итоге получая контроль над содержимым ведра, когда законный клиент начинает использовать такие сервисы, как CloudFormation, Glue, EMR, SageMaker, ServiceCatalog и CodeStar.

«В таком случае злоумышленнику, получившему доступ к стандартной сервисной роли с AmazonS3FullAccess, даже не нужно угадывать имена ведер», - объясняют исследователи.

«Они могут использовать свои существующие привилегии для поиска ведер, задействуемых другими сервисами, используя шаблоны именования, модифицировать ресурсы, такие как шаблоны CloudFormation, скрипты EMR и ресурсы SageMaker, а также перемещаться между сервисами внутри одного и того же аккаунта AWS.»

Другими словами, IAM роль в аккаунте AWS с правами AmazonS3FullAccess обладает правами на чтение и запись для каждого S3 ведра и может вносить изменения в различные сервисы AWS, превращая роль в мощный инструмент для бокового перемещения и повышения привилегий.

-2

Некоторые из сервисов, у которых обнаружены разрешительные политики, включают:

  • Amazon SageMaker AI, который создает стандартную роль выполнения с названием AmazonSageMaker-ExecutionRole-<Дата&Время> при настройке домена SageMaker с пользовательской политикой, эквивалентной AmazonS3FullAccess.
  • AWS Glue, который создает стандартную роль AWSGlueServiceRole с политикой AmazonS3FullAccess.
  • Amazon EMR, который создает стандартную роль AmazonEMRStudio_RuntimeRole_<Время Epoch>, которой присвоена политика AmazonS3FullAccess.

В гипотетическом сценарии атаки злоумышленник мог бы загрузить вредоносную модель машинного обучения на Hugging Face, которая, будучи импортированной в SageMaker, могла бы привести к выполнению произвольного кода. Этот код могли бы затем использовать для захвата контроля над другими сервисами AWS, такими как Glue, внедряя бэкдор, способный красть IAM учетные данные заданий Glue.

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

В ответ на эти угрозы AWS устранила выявленные проблемы, изменив политику AmazonS3FullAccess для стандартных сервисных ролей.

«Стандартные сервисные роли должны быть строго ограничены конкретными ресурсами и действиями, необходимыми для их выполнения», - отметили исследователи. «Организации должны проактивно проверять и обновлять существующие роли, чтобы минимизировать риски, а не полагаться на стандартные конфигурации.»

Эти выводы стали известны после сообщения Varonis о уязвимости в утилите для монтирования Azure Storage, предустановленной на Microsoft Azure AI и вычислениях высокой производительности (HPC), которая позволяет неавторизованному пользователю на машине с Linux с установленной этой утилитой повысить свои привилегии до root.

-3

«Это классический метод повышения привилегий, связанный с SUID бинарными файлами, которые являются частью установки AZNFS-mount - утилиты для монтирования конечных точек NFS Azure Storage Account», - рассказал исследователь безопасности Тал Пелег.

«Например, пользователь мог бы повысить свои привилегии до root и использовать эти полномочия для монтирования дополнительных контейнеров Azure Storage, установки вредоносного ПО или программ-вымогателей на машине и попытки перемещения в сети или облачных средах.»

Несмотря на то, что уязвимость затрагивала все версии утилиты до 2.0.10, она была устранена в версии 2.0.11, выпущенной 30 января 2025 года.

Если вам понравилась эта статья, подпишитесь, чтобы не пропустить еще много полезных статей!

Премиум подписка - это доступ к эксклюзивным материалам, чтение канала без рекламы, возможность предлагать темы для статей и даже заказывать индивидуальные обзоры/исследования по своим запросам!Подробнее о том, какие преимущества вы получите с премиум подпиской, можно узнать здесь

Также подписывайтесь на нас в: