Атака на Capital One: как SSRF вывела данные из AWS

В 2019 году атака на Capital One показала, как уязвимость в одном веб-сервисе превращается в утечку данных из облака. Злоумышленница использовала SSRF в приложении, получила доступ к метаданным виртуальной машины AWS, извлекла временные учетные данные IAM и обратилась к хранилищам S3. По материалам дела, затронуты были сведения более чем о 100 млн клиентов в США и примерно 6 млн в Канаде.

Что произошло и почему это не была «атака на S3»

Инцидент произошел в 2019 году. Публичное описание дела не дает полной информации о фреймворке и версии приложения Capital One, поэтому приписывать атаке конкретную версию Rails, Java или Nginx нельзя. Ниже разобрана именно архитектурная цепочка, а не воспроизводимый сценарий проникновения.

Ключевой вход находился перед приложением: неправильно обработанный запрос позволял серверу обратиться к адресу, который контролировал или выбирал внешний пользователь. Такая уязвимость называется SSRF^[1]. Само по себе это еще не означает доступ к базе данных. Опасность появляется, когда сервер имеет сетевой доступ к внутренним адресам и запускается с избыточными правами.

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

Цепочка атаки внутри инфраструктуры

1. Внешний запрос достиг внутреннего маршрута

Веб-приложение принимало пользовательские данные и использовало их при обращении к другому ресурсу. Вместо ожидаемого внешнего адреса сервер можно было направить на внутренний endpoint. Приложение стало сетевым посредником между интернетом и инфраструктурой AWS.

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

2. Сервис метаданных вернул сведения об окружении

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

Сегодня AWS отдельно документирует IMDSv2 — вариант сервиса метаданных, который требует предварительного получения сессионного токена. Это усложняет часть SSRF-сценариев, но не исправляет уязвимость приложения и не заменяет сетевые ограничения. Публичные материалы по делу Capital One не позволяют уверенно утверждать, какой именно режим IMDS использовался в момент атаки.

3. Временные ключи дали доступ в AWS

Роль IAM выдала виртуальной машине временные учетные данные. Это нормальный механизм облака: приложение получает права без хранения постоянного ключа в файле конфигурации. Проблема возникла из-за сочетания двух условий — SSRF позволяла добраться до метаданных, а роль имела больше разрешений, чем требовалось конкретному сервису.

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

4. Из S3 извлекли данные

По материалам обвинения, доступ использовали для получения информации из хранилищ Amazon S3. В публичном описании фигурируют имена, адреса, даты рождения, сведения о кредитных заявках, номера банковских счетов и другие данные. Объем и состав затронутой информации различались по категориям клиентов.

S3 в этой цепочке был последним звеном, а не первоначной точкой входа. Даже идеально закрытое от прямого публичного доступа хранилище остается доступным тому, кто получил разрешения подходящей IAM-роли. Поэтому проверка только настройки «публичный или приватный бакет» не покрывает весь риск.

Почему защита не сработала

Главный архитектурный дефект здесь — не одна «дырка», а отсутствие независимых ограничителей. SSRF дала сетевой путь, IAM — полномочия, S3 — большой объем данных. Если бы хотя бы один из этих слоев отказал, ущерб был бы меньше.

Что проверять при разборе такого инцидента

1. Сначала зафиксируйте временную шкалу. Сопоставьте запросы приложения, изменения IAM и обращения к хранилищам по UTC-времени. Не ограничивайтесь логами балансировщика: нужные события могут находиться в CloudTrail, журналах приложения и логах доступа к объектам.
2. Отделите факт доступа от факта чтения. Обращение к бакету не доказывает, что каждый объект был выгружен. Ищите операции чтения, размер ответов, повторяемость запросов и последующие действия с данными.
3. Проверьте, какие права были у роли. Снимите фактический набор разрешений на момент инцидента и сравните его с тем, что нужно приложению. Не заменяйте эту проверку просмотром только декларативного файла Terraform или CloudFormation.
4. Закройте путь, а не только текущий адрес. Фильтр одного IP не решает SSRF. Нужно ограничить весь класс назначений: локальные адреса, диапазоны VPC, DNS-резолвинг во внутренние имена и перенаправления.
5. Проверьте исправление безопасным тестом. В staging используйте контролируемый endpoint и журналирование исходящих запросов. Не проверяйте защиту обращениями к чужим облачным ресурсам или боевым метаданным.

Где этот подход ломается

Фильтр по IP не учитывает DNS

Сервис может сначала получить внешний адрес, а затем разрешить имя во внутренний. Адрес также способен измениться после проверки. Поэтому безопаснее строить исходящие запросы через строгий allowlist ресурсов и повторно проверять конечное назначение после разрешения имени.

IMDSv2 не лечит SSRF полностью

Сессионный токен снижает риск простых запросов к метаданным, но приложение все равно может быть использовано для атак на другие внутренние HTTP-сервисы. Защита должна включать сетевые правила, минимальные права IAM и контроль исходящих соединений.

Минимальные права не означают нулевой ущерб

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

Что измерять после исправления

Для веб-сервиса полезно смотреть не только количество ошибок 4xx и 5xx. Добавьте метрики исходящих запросов: долю обращений к разрешенным доменам, число отказов по policy, попытки доступа к локальным и RFC 1918-адресам, количество редиректов и время между запросом приложения и чтением объекта в S3.

В AWS отдельно проверьте, включен ли IMDSv2 для EC2, какие роли назначены экземплярам и какие действия с объектами фиксирует CloudTrail или серверный лог S3. Пересмотрите политики после изменения приложения: новая функция импорта URL или предпросмотра может вернуть SSRF даже после старого исправления.

Что делать дальше

Начните с инвентаризации всех функций, которые принимают URL, имя файла или адрес webhook. Для каждой функции зафиксируйте список допустимых назначений, сетевой маршрут и IAM-роль. Затем включите тесты на SSRF в CI, проверьте режим IMDSv2 на EC2 и поставьте алерт на нетипичное массовое чтение из S3.

^[1] SSRF (Server-Side Request Forgery) — уязвимость, при которой сервер выполняет сетевой запрос по данным, частично контролируемым пользователем. Опасность зависит от того, куда сервер может обратиться и какие ответы он возвращает.