Как злоумышленники использовали доступ Qubole к AWS для кражи данных?

С 14 по 26 октября злоумышленник через AWS-аккаунт платформы Qubole получил доступ к облачным аккаунтам нескольких клиентов и похитил хранившиеся там учетные данные и данные из Amazon S3. Об атаке сообщила компания Wiz, занимающаяся облачной безопасностью. Как именно злоумышленник добыл учетные данные аккаунта Qubole, не раскрыто; исследователи также не сообщили, отключили ли эти данные и прекратилась ли активность. На момент проверки The Hacker News ни Qubole, ни ее владелец Idera не опубликовали заявлений на своих сайтах.
Qubole — платформа для работы с озерами данных, которая запускается внутри AWS-аккаунтов клиентов. Обычно клиент создает IAM-роль с нужными разрешениями и добавляет в ее политику доверия AWS-аккаунт Qubole. Платформа получает доступ через запрос AssumeRole, содержащий External ID — идентификатор, который предоставляет Qubole. Если запрос приходит из доверенного аккаунта и содержит подходящий External ID, AWS разрешает принять роль.
Проблема в том, что External ID не считается секретом: любой, у кого есть доступ к роли, может его просмотреть. По данным Wiz, большинство ролей, принятых злоумышленником, давно не использовались, но продолжали доверять аккаунту Qubole. В техническом анализе исследователи указали, что каждый связанный с атакой запрос AssumeRole содержал External ID и был принят. Активность в нескольких клиентских средах обнаружила компания Sentra и сообщила о ней исследователям.
Получив доступ, злоумышленник искал учетные данные в настройках Lambda-функций, хранилищах AWS Secrets Manager и AWS Systems Manager Parameter Store. Найденные данные проверяли с помощью TruffleHog. Среди них были ключи AWS, клиентские секреты Entra ID и учетные данные Okta. Затем атакующий копировал доступные ему данные из бакетов Amazon S3: он не выбирал отдельные файлы по названиям, а забирал содержимое бакетов, иногда целиком за один сеанс.
Отдельно исследователи зафиксировали другую активность: с 8 по 11 октября кто-то использовал собственные AWS access keys клиентов, предположительно настроенные для подключения к Qubole. Были скомпрометированы облачные среды нескольких жертв. Связи между этим эпизодом и последующей кампанией с AssumeRole исследователи не установили. Они также не связали атаку с другими публично известными кампаниями и отметили, что выбор жертв не похож на обычные цели групп, поддерживаемых государствами.
Организациям, которые когда-либо подключали Qubole к AWS, включая тех, кто уже перестал пользоваться платформой, следует проверить журналы CloudTrail начиная с 1 октября во всех аккаунтах, где есть роль Qubole. Особое внимание нужно уделить запросам AssumeRole, в которых userIdentity.accountId равен 805246085872, а sourceIPAddress не относится к AWS-адресам. По наблюдениям исследователей, легитимный трафик Qubole приходил только из AWS.
Проверьте также активность IAM principal ID AIDA3W7DIFLYOLTK63SFS: в изученных аккаунтах им пользовался только атакующий. ID AIDAJYRRH5Y3A7AAJM2HW требует проверки, если запрос пришел не из AWS: злоумышленник использовал эту учетную запись с 18 октября, но она встречалась и в обычном трафике Qubole. Среди подозрительных адресов были OVH-адреса 57.129.54[.]120 и 2001:41d0:70d[:]7800::, а также IP-адреса VPN-сервиса Mullvad: 45.83.220[.]211, 185.209.199[.]73 и 89.37.63[.]175. Совпадение с адресом Mullvad само по себе не доказывает взлом: его могут использовать разные люди. Ищите сеансы ролей с именами, начинающимися на quiam-, например quiam-enum, а также вызовы GetCallerIdentity с User-Agent TruffleHog и последующие входы в журналы провайдера идентификации с тем же User-Agent.
После обнаружения подозрительного сеанса нужно проследить всю последующую активность, прежде всего обращения к Secrets Manager, SSM Parameter Store, Lambda и S3. События управления CloudTrail фиксируют запросы AssumeRole и перечисление бакетов, но не показывают, какие именно объекты S3 читались. Для этого нужны S3 data events или журналы доступа S3. У нескольких пострадавших таких записей не было, поэтому установить, какие файлы открыл злоумышленник, не удалось.
Если роль Qubole была принята, замените все секреты и параметры, доступные этой роли, а также учетные данные в переменных окружения Lambda. Отзовите активные сессии: простая смена пароля или ключа не завершает уже выданные сессии. Удалите ненужные роли Qubole либо исключите аккаунт Qubole из их политик доверия. Там, где это поддерживается, замените широкого субъекта :root на конкретный IAM principal, который использует Qubole.
Доступ роли стоит ограничить условиями aws:SourceIp или aws:SourceVpce, разрешив запросы только из документированных сетей поставщика. По оценке исследователей, одно ограничение по исходному IP заблокировало бы все замеченные в атаке запросы AssumeRole. Не считайте External ID паролем: он может храниться в открытом виде в CloudTrail, документации поставщика и файлах инфраструктуры как кода. После инцидента смените его через Qubole и, где возможно, задавайте отдельное значение для каждой роли.
Наконец, пересмотрите разрешения ролей поставщиков. В руководстве по настройке Qubole есть пример политики S3, позволяющей читать все бакеты аккаунта; подобные широкие права на S3, настройки Lambda, Secrets Manager и SSM упрощают работу, но расширяют возможный ущерб. Настройте оповещения о запросах AssumeRole от поставщиков, если они приходят через незнакомый VPN или хостинг-провайдера. Включите организационный CloudTrail во всех аккаунтах и регионах, а для бакетов с чувствительными данными — S3 data events или журналы доступа.