Злоумышленник использовал скомпрометированные учетные данные для управления идентификацией и доступом (IAM) в аккаунте AWS платформы больших данных Qubole, чтобы получить доступ к средам AWS нескольких клиентов и похитить данные.
Кампания проводилась с 14 по 26 октября и затронула десятки компаний, в средах AWS которых были настроены роли IAM, доверяющие аккаунту AWS, связанному с Qubole.
Qubole — это корпоративная облачная платформа для обработки и анализа данных, которая помогает компаниям управлять большими массивами данных и выполнять задачи машинного обучения. Она также предлагает интеграцию с AWS для управления вычислительными ресурсами.
Компании могут предоставлять сторонним поставщикам, таким как Qubole, доступ к своим ресурсам AWS, создавая роли IAM для нескольких аккаунтов. Политики доверия определяют, какие внешние аккаунты AWS могут использовать эти роли, а разрешения задают список разрешенных ресурсов и действий.
Исследователи из компании Wiz, специализирующейся на облачной безопасности, объясняют, что внешние провайдеры используют API AWS STS AssumeRole для получения временных учетных данных для доступа к ресурсам клиентов в облаке.
Компания Wiz начала расследование после того, как компания Sentra, специализирующаяся на безопасности данных и управлении ими, поделилась информацией о подозрительной активности в средах некоторых ее клиентов. В расследовании также участвовала компания Mandiant, специализирующаяся на кибербезопасности.
Исследователи обнаружили, что злоумышленник скомпрометировал двух пользователей Qubole IAM и получил доступ к неиспользуемым ролям в аккаунтах AWS нескольких клиентов, которые ранее были настроены на доверие к аккаунту Qubole, что давало ему доступ в рамках разрешений роли.
Обзор атаки
Источник: Sentra
По словам Wiz, злоумышленник изучил облачные ресурсы, получил доступ к секретам из AWS Secrets Manager и SSM Parameter Store, а также к переменным среды Lambda.
Затем они использовали инструмент TruffleHog для проверки обнаруженных ключей AWS, секретов клиентов Microsoft Entra ID и учетных данных клиентов Okta.
Получив более широкий доступ, они скачали данные из всех доступных корзин S3 в среде AWS, действуя по обстоятельствам, а не целенаправленно подбирая конкретные данные.
«Последовательность действий была одинаковой во всех средах: принять роль, вызвать ListBuckets, чтобы посмотреть, к чему у роли есть доступ, вызвать ListObjects и HeadObject, чтобы перечислить и проверить содержимое, а затем вызвать GetObject, чтобы загрузить данные», — .
В отчете не уточняется, каким именно способом были скомпрометированы учетные записи Qubole и сколько пользователей пострадали. Однако Sentra подтвердила, что пострадали десятки пользователей и что только у одного клиента были украдены миллионы файлов.
По словам Sentra, злоумышленник действовал быстро и за семь минут собрал 100 паролей и ключей.
BleepingComputer не удалось найти публичное заявление Qubole об этом инциденте. Мы отправили компании электронное письмо с просьбой предоставить дополнительную информацию об атаке и ждем ответа.
Администраторам, которых это может коснуться, рекомендуется с 1 октября проверять CloudTrail на предмет подозрительного доступа из аккаунта Qubole в AWS, расследовать последующие обращения к секретным данным и S3, менять открытые учетные данные и отзывать активные сеансы ролей.
Также рекомендуется удалить неиспользуемые интеграции и ограничить разрешения оставшихся ролей, доверенные идентификационные данные и разрешенные исходные сети.
Обновление от 11 ноября — представитель AWS прислал BleepingComputer следующий комментарий:
«Эта проблема не повлияла на работу сервисов AWS, которые функционировали в штатном режиме. В отчете описывается, как злоумышленники использовали учетные данные стороннего поставщика для доступа к аккаунтам некоторых клиентов AWS, принимая на себя роли IAM, которые эти клиенты настроили для работы с этим поставщиком. Как и всегда, мы рекомендуем всем клиентам следовать рекомендациям по обеспечению безопасности, идентификации и соблюдению нормативных требований, в том числе регулярно проверять роли IAM между аккаунтами, удалять доступ к интеграциям, которые больше не используются, предоставлять разрешения с минимальными привилегиями и добавлять такие условия, как ограничение IP-адресов источника, в политики доверия к ролям». Клиенты AWS, которые подозревают или узнали о несанкционированной активности в своих аккаунтах, должны следовать инструкциям по устранению потенциально скомпрометированных учетных данных или обращаться в службу поддержки AWS по любым вопросам или проблемам, связанным с безопасностью аккаунта». — представитель AWS
