Мы читаем реальные публичные инциденты не как повторный прогон новостей, а через призму «как бы вы от этого защитились». Эта статья основана на публичных материалах (регуляторы, журналистика, академический анализ, официальные заявления), ссылки приведены в конце.
- Цель
- Capital One (крупный банк США)
- Раскрытие
- 29 июля 2019 (обнаружено 19 июля / проникновение в марте)
- Класс
- кража облачных учётных данных через SSRF и эксфильтрация
- Масштаб
- ~106 млн человек в США/Канаде (в т.ч. ~140k номеров SSN, ~80k связанных номеров банковских счетов)
- Первопричина
- уязвимость SSRF + незащищённый endpoint метаданных + переизбыточная роль IAM
- Основные меры
- эшелонированная оборона: список разрешённых адресов назначения, IMDSv2, минимальные привилегии IAM
Что произошло (простыми словами)
Capital One вёл часть обработки заявок в облаке. Стоявший перед ним компонент (работавший как обратный прокси / WAF) имел уязвимость SSRF: его можно было заставить отправить запрос от имени сервера к адресу назначения, выбранному снаружи.
У облачных ВМ есть особый endpoint метаданных, доступный только изнутри, который возвращает временные учётные данные, назначенные этой машине. С помощью SSRF злоумышленник достиг этого внутреннего endpoint и получил ключи. Стоявшая за ними роль IAM (в публичных материалах фигурирует как ISRM-WAF-Role) имела широкие права на чтение хранилища, поэтому содержимое ~700 бакетов хранилища (S3) было скопировано как есть.
При SSRF endpoint, «доступный только изнутри», можно достать снаружи
Endpoint метаданных был защищён предположением «недостижим снаружи». Но SSRF заставляет сам сервер проксировать доступ, разрушая это предположение. «Только внутреннее, значит безопасно» перестаёт быть правдой, как только появляется хотя бы одна уязвимость SSRF.
Этапы атаки и как остановить каждый из них
Важно, что это была цепочка из четырёх шагов, и на каждом шаге было место для остановки. Читайте это не как рецепт атаки, а как «где её можно было остановить».
① Отправная точка: SSRF
Уязвимость позволяет серверу проксировать запрос к произвольному адресу назначения.
⊘ остановка: список разрешённых адресов назначения
② Достижение внутреннего endpoint метаданных
«Только внутренний» endpoint становится достижим через SSRF.
⊘ остановка: IMDSv2 (требуется токен + лимит хопов)
③ Получение временных учётных данных IAM
Роль машины возвращает временные ключи.
⊘ остановка: роль с минимальными привилегиями (без права чтения всего хранилища)
④ Массовое копирование хранилища (S3)
~700 бакетов скопированы напрямую.
⊘ остановка: контроль исходящего трафика + обнаружение аномального чтения
Хронология (по раскрытым данным)
2019-03
Несанкционированный доступ к облачной среде (установлено позже).2019-07-17
Внешняя наводка (пост на GitHub) сигнализирует об аномалии.2019-07-19
Capital One подтверждает утечку во внутреннем расследовании.2019-07-29
Публичное раскрытие; ФБР арестовывает бывшего инженера AWS.2019-11
AWS объявляет IMDSv2 как эшелонированную защиту от SSRF.2020-08
OCC налагает штраф ~$80 млн, ссылаясь на недостаточную оценку рисков перед миграцией в облако.
Первопричина: не хватало сразу нескольких защит
Списать всё на «SSRF» — и это повторится. На деле три слоя отказали последовательно.
Как было (на тот момент)
- Отсутствие валидации адреса назначения на входе (возможен любой проксируемый запрос)
- Endpoint метаданных возвращал ключи без токена (легаси-режим)
- Роль IAM машины могла широко читать хранилище (переизбыточные права)
Как должно быть (профилактика)
- Список разрешённых адресов назначения и запрет проксируемого доступа к внутренним адресам
- Метаданные через IMDSv2: обязательный токен сессии + лимит хопов блокируют проксируемый доступ
- Роль IAM с минимальными привилегиями: только реально нужные бакеты и действия
Разделённая ответственность: что должен защищать клиент облака
Облачный провайдер защищает фундамент, но исправление SSRF, проектирование прав IAM и защита метаданных — ответственность клиента. Сам штраф ссылался на «недостаточную оценку рисков перед миграцией в облако». Проблема не в использовании облака; важно, спроектировали ли вы полностью ту часть, за которую отвечаете сами.
Как предотвратить это в вашей среде
Исправления в порядке приоритета, работающие в любом масштабе. Если у вас есть хотя бы одна функция, которая «принимает URL и загружает его» или «доставляет вебхук/изображение», — это про вас.
Список разрешённых адресов для исходящих запросов (остановите SSRF на первом шаге)
Там, где сервер проксирует доступ к URL, предоставленному пользователем, ограничьте его только разрешёнными адресами назначения. По умолчанию запретите доступ к внутренним адресам (endpoint метаданных, частные сети). В статье об SSRF разобраны ловушки валидации, которые люди упускают (следование за редиректами, DNS rebinding).
Принудительно используйте IMDSv2 для метаданных
Ограничьте облачный endpoint метаданных режимом с обязательным токеном и лимитом хопов (IMDSv2 в AWS). Уже одно это сильно затрудняет кражу учётных данных через SSRF. Суть — отключить легаси-режим.
Минимальные привилегии IAM (ограничьте ущерб)
Чтобы утёкшие ключи причинили ограниченный ущерб, ограничьте права машины/сервиса только нужными целями и действиями. «Просто разрешим всё хранилище» превращает одну утечку в тотальную эксфильтрацию.
Контроль исходящего трафика и обнаружение аномалий
Ограничьте исходящий трафик нужными адресами назначения и обнаруживайте аномалии вроде всплеска крупных чтений. Даже если первый шаг не остановлен, держите слой, замечающий эксфильтрацию.
Где это пересекается с устройством этого сайта
Этот сайт проектирует функции работы с URL вокруг только проверенных доменов (SSRF-безопасно по дизайну). Эта утечка ясно показывает, почему необходимы принципы, на которых мы строим: проверять ввод, давать минимальные привилегии и не считать «внутреннее» безопасным. Даже на удобной облачной платформе ту часть, за которую отвечаете вы, нужно проектировать самим.
Источники (публичные материалы)
Факты здесь основаны на следующей публичной информации. Мы не описываем шаги воспроизведения или payload-ы — только уроки защиты.
- Krebs on Security, "What We Can Learn from the Capital One Hack" (2019) — krebsonsecurity.com
- ACM Transactions on Privacy and Security, "A Systematic Analysis of the Capital One Data Breach" — dl.acm.org
- CyberScoop, "US financial regulator fines Capital One $80 million over data breach" (2020) — cyberscoop.com
Читать дальше
- Глоссарий: Что такое SSRF (отправная точка этой утечки, с ловушками валидации)
- Инцидент: Удар по запущенному CVSS 10.0
- Защита: Встройте минимальные привилегии и мониторинг машин в эксплуатацию