Хакеры использовали доверенный доступ Qubole к AWS для взлома учетных записей клиентов и кражи данных

Aws Qubole безопасность утечка данных облако взлом thehackernews.com

Злоумышленник взломал учетные записи AWS клиентов Qubole, похитив секреты и данные. Атака использовала уязвимость в механизме AssumeRole, позволяя получить доступ к конфиденциальной информации. Рекомендуется проверить журналы CloudTrail на предмет подозрительной активности.

Злоумышленник получил доступ к учетным записям AWS нескольких клиентов Qubole в период с 14 по 26 октября и похитил сохраненные секреты и данные, сообщила сегодня компания Wiz, специализирующаяся на облачной безопасности. Злоумышленник использовал учетные данные учетной записи AWS, которую платформа Qubole применяет для доступа к этим клиентам. Как злоумышленник получил эти учетные данные, не раскрывается. Qubole, платформа для работы с озерами данных, принадлежащая Idera, работает в учетных записях AWS своих клиентов. Чтобы предоставить доступ, клиент создает роль IAM — идентификатор AWS с собственным набором разрешений. Политика доверия роли позволяет учетной записи AWS Qubole принять роль, предоставляя эти разрешения. Каждый запрос на выполнение этого действия, называемый AssumeRole, должен включать соответствующий код от Qubole, известный как External ID. По словам исследователей Wiz, помимо атаки, большинство ролей, которые принял злоумышленник, не использовались. Однако каждая роль по-прежнему доверяла учетной записи Qubole, поэтому запросы злоумышленника срабатывали. Любая организация, подключившая Qubole к AWS, даже та, которая больше не использует ее, должна проверить свои журналы CloudTrail начиная с 1 октября. Признаком для поиска является запрос AssumeRole из учетной записи, которую использует платформа Qubole (805246085872), поступивший с адреса за пределами AWS. Исследователи не сообщили, были ли учетные данные с тех пор отключены или прекращена ли активность. Ни Qubole, ни Idera не опубликовали заявления об атаке на своих веб-сайтах на момент проверки The Hacker News сегодня. Исследователи заявили в своем техническом анализе, что каждый запрос AssumeRole, связанный со злоумышленником, имел External ID и был принят. AWS принимает запрос AssumeRole для такой роли, когда он поступает из доверенной учетной записи и включает правильный External ID. Код не считается секретом, и любой, кто имеет доступ к роли, может его просмотреть, согласно руководству AWS по внешним идентификаторам. Sentra обнаружила активность в средах нескольких своих клиентов и уведомила исследователей. В учетных записях, изученных исследователями, злоумышленник искал сохраненные учетные данные. Он считывал переменные среды для функций Lambda, извлекал секреты из Secrets Manager и считывал значения из SSM Parameter Store. Затем он использовал найденные учетные данные с помощью TruffleHog для проверки их работоспособности. Это были собственные ключи доступа AWS жертв, секреты клиентов Entra ID и учетные данные клиентов Okta. Злоумышленник также копировал данные из S3. Он извлекал данные из любого бакета, к которому могла получить доступ роль, вместо поиска конкретных данных, и иногда загружал весь бакет за один сеанс. Исследователи не связали эту кампанию с какой-либо другой общедоступной информацией и утверждают, что таргетинг не соответствует тому, что обычно делают группы, поддерживаемые государством. Qubole также позволяет клиентам подключаться с помощью ключей доступа AWS вместо роли. С 8 по 11 октября злоумышленник использовал собственные ключи доступа AWS клиентов, которые, по мнению исследователей, были настроены для Qubole. Затем этот злоумышленник скомпрометировал несколько облачных сред жертв. Эта активность не была связана с злоупотреблением AssumeRole. Руководство Wiz по поиску охватывает журналы CloudTrail начиная с 1 октября в каждой учетной записи AWS, которая содержит роль Qubole. Ищите: Для каждой подозрительной сессии просматривайте все последующие действия, особенно в Secrets Manager, SSM Parameter Store, Lambda и S3. Управление событиями CloudTrail регистрирует каждый запрос AssumeRole и перечисление бакетов, но не то, какие объекты S3 были прочитаны. Для этого требуются события данных S3 или журналы доступа к серверу S3. У нескольких жертв отсутствовали необходимые журналы, поэтому ответчики не смогли определить, какие объекты прочитал злоумышленник. Исследователи рекомендуют следующие шаги:

Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.

В тренде:


Похожие новости: