Qubole: атакующие использовали доверенные IAM-роли в AWS для кражи данных клиентов

КиберБез 7 мин чтения 52 просмотра

Компания Wiz сообщила об атаке на AWS-аккаунты нескольких клиентов Qubole: с 14 по 26 октября злоумышленник заходил в них, используя учётные данные AWS-аккаунта самой платформы Qubole, и похищал сохранённые секреты и данные. Как именно атакующий получил эти учётные данные, не раскрывается.

Qubole — платформа для работы с данными (data lake), принадлежит Idera. Она работает внутри AWS-аккаунтов заказчиков: клиент создаёт IAM-роль с нужными правами, а её trust policy разрешает аккаунту Qubole принимать эту роль через AssumeRole. Каждый такой запрос должен содержать совпадающий код от Qubole — External ID.

Почему сработали даже неиспользуемые роли

По данным исследователей Wiz, большинство ролей, которые принимал атакующий, клиенты уже не использовали. Но каждая из них по-прежнему доверяла аккаунту Qubole, поэтому запросы проходили. Все запросы AssumeRole, связанные с атакующим, содержали External ID и были приняты.

AWS принимает такой запрос, если он пришёл из доверенного аккаунта и содержит правильный External ID. Сам код секретом не считается: его может увидеть любой, у кого есть доступ к роли, — так это описано в рекомендациях AWS по External ID.

Активность заметила компания Sentra в средах нескольких своих клиентов и сообщила о ней исследователям.

Что именно делал атакующий

В изученных аккаунтах злоумышленник искал сохранённые учётные данные: читал переменные окружения Lambda-функций, забирал секреты из Secrets Manager и значения из SSM Parameter Store. Найденные учётные данные он прогонял через TruffleHog, чтобы проверить их работоспособность. Среди них были собственные AWS access keys жертв, клиентские секреты Entra ID и клиентские учётные данные Okta.

Кроме того, атакующий копировал данные из S3: брал их из любого бакета, к которому давала доступ роль, а не искал что-то конкретное, и иногда выкачивал весь бакет за одну сессию.

Исследователи не связывают эту кампанию с другими публично известными атаками и отмечают, что выбор целей не похож на то, за чем обычно охотятся группы, поддерживаемые государствами.

Второй эпизод: ключи доступа вместо роли

Qubole позволяет подключаться к AWS не только через роль, но и через access keys. С 8 по 11 октября атакующий использовал собственные AWS access keys клиентов, которые, по мнению исследователей, были настроены для Qubole. Ему удалось скомпрометировать несколько облачных сред жертв. С атакой через AssumeRole этот эпизод не связан.

Как проверить свои аккаунты

Wiz рекомендует проверить логи CloudTrail с 1 октября во всех AWS-аккаунтах, где есть роль для Qubole, и искать следующие признаки:

  • Аккаунт: запросы AssumeRole, где userIdentity.accountId равен 805246085872, а sourceIPAddress — не адрес AWS. Настоящий трафик Qubole, по наблюдениям исследователей, шёл только из AWS.
  • IAM principal ID: AIDA3W7DIFLYOLTK63SFS — любая активность этого IAM-пользователя требует разбора: в изученных аккаунтах его использовал только атакующий.
  • IAM principal ID: AIDAJYRRH5Y3A7AAJM2HW, если адрес источника вне AWS. Атакующий использовал этого IAM-пользователя с 18 октября, но этот же пользователь задействован и в обычном трафике Qubole.
  • IP: 57.129.54[.]120 и 2001:41d0:70d[:]7800:: — адреса OVH, которые использовал атакующий.
  • IP: 45.83.220[.]211, 185.209.199[.]73 и 89.37.63[.]175 — адреса Mullvad VPN. Их используют и другие клиенты VPN, поэтому совпадение само по себе ничего не доказывает.
  • Имя сессии: сессии роли, начинающиеся с quiam-, например quiam-enum.
  • User agent: TruffleHog в вызовах GetCallerIdentity с одного из указанных выше IP. Тот же user agent стоит искать в логах входа вашего провайдера идентификации.

Для каждой подозрительной сессии нужно разобрать всё, что она делала дальше, особенно в Secrets Manager, SSM Parameter Store, Lambda и S3.

Важное ограничение: CloudTrail фиксирует события управления, включая каждый запрос AssumeRole и листинг бакетов, но не то, какие объекты S3 читались. Для этого нужны S3 data events или server access logs. У нескольких жертв нужных логов не было, и специалисты по реагированию не смогли установить, какие объекты прочитал атакующий.

Как закрыть маршрут

Исследователи рекомендуют следующее:

  1. Если атакующий принимал вашу роль Qubole, смените все секреты, параметры и переменные окружения Lambda, к которым эта роль имела доступ, и отзовите активные сессии роли. Смена учётных данных не завершает уже выданные сессии.
  2. Удалите роли Qubole, которые больше не нужны, или уберите аккаунт Qubole из их trust policy.
  3. Там, где Qubole это поддерживает, замените в trust policy принципал :root на уровне аккаунта на конкретный IAM-принципал, который использует Qubole.
  4. Добавьте условие aws:SourceIp или aws:SourceVpce, ограничивающее запросы AssumeRole документированными диапазонами сети вендора. По словам исследователей, в этой атаке «одно условие на IP источника заблокировало бы все наблюдавшиеся принятия ролей».
  5. Исходите из того, что External ID могут увидеть другие: он пишется в CloudTrail открытым текстом, а вендоры и файлы infrastructure-as-code часто его хранят. Не полагайтесь на него как на единственный контроль. После такого инцидента смените его в Qubole и по возможности используйте отдельное значение для каждой роли.
  6. Проверьте, до чего может дотянуться каждая роль вендора. В руководстве по настройке Qubole есть пример политики S3, позволяющей роли читать все бакеты в аккаунте. Ролям вендоров часто выдают доступ к настройкам Lambda, Secrets Manager, параметрам SSM и широкие права на чтение S3 ради удобства, отмечают исследователи.
  7. Настройте оповещения о запросах AssumeRole из аккаунта вендора, приходящих через VPN или хостинг-провайдера, которого вендор раньше не использовал.
  8. Включите логирование всех аккаунтов и регионов через organization trail, а также S3 data events или server access logs для бакетов с чувствительными данными.

Схема с доверием к аккаунту вендора знакома и по другим инцидентам: например, в случае с CVE-2026-110447 в Collabora Online атакующие тоже действовали через легитимный компонент инфраструктуры. Разница в том, что там дыра была в коде, а здесь — в конфигурации доверия. Похожий урок — у истории про эксплуатацию OpenSSH SSHole: защита держится не на секретности одного параметра, а на ограничениях доступа. И совсем близкий по механике случай — цепочка Plex2Shell из четырёх уязвимостей, где чужие доверенные связи тоже стали входной точкой.

На момент проверки The Hacker News ни Qubole, ни Idera не опубликовали заявления об атаке на своих сайтах. Исследователи также не уточнили, отключены ли с тех пор учётные данные и прекратилась ли активность.

Частые вопросы

Кого касается эта атака?

Всех, кто подключал Qubole к AWS, — даже если сервис уже не используется. Роли с доверием аккаунту Qubole остаются в аккаунте после отказа от платформы и продолжают работать.

Что искать в CloudTrail в первую очередь?

Запросы AssumeRole с userIdentity.accountId = 805246085872, где sourceIPAddress не принадлежит AWS. Настоящий трафик Qubole, по данным Wiz, приходил только из AWS.

Достаточно ли сменить пароли и ключи?

Нет. Смена учётных данных не завершает уже выданные сессии роли, поэтому активные сессии нужно отзывать отдельно.

Поможет ли ограничение по IP?

По словам исследователей, в этой атаке условие на IP источника заблокировало бы все наблюдавшиеся принятия ролей. Но это лишь одна из мер: её стоит сочетать с удалением ненужных ролей и заменой принципала :root на конкретный.

Можно ли считать External ID защитой?

Нет. AWS не считает его секретом, он пишется в CloudTrail открытым текстом и может храниться у вендора или в файлах infrastructure-as-code. Как единственный контроль он ненадёжен.

Удалось ли установить, какие данные из S3 прочитал атакующий?

У нескольких жертв не было нужных логов. CloudTrail фиксирует AssumeRole и листинг бакетов, но не то, какие объекты читались; для этого нужны S3 data events или server access logs.

Связана ли атака с государственными группами?

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

Что делать, если роль Qubole больше не нужна?

Удалить её или убрать аккаунт Qubole из trust policy. Пока роль существует и доверяет аккаунту вендора, запросы AssumeRole с правильным External ID будут приниматься.

Источник: thehackernews.com