Инциденты и уязвимости
Утечка Capital One (2019) — как один SSRF привёл к компрометации 100M+ записей и как защититься
В 2019 году из Capital One утекло ~106 млн записей. Один SSRF достиг облачного endpoint метаданных, украл переизбыточные учётные данные IAM и скопировал S3. Цепочка атаки как карта обороны, плюс исправления: список разрешённых адресов назначения, IMDSv2, минимальные привилегии IAM.
Мы читаем реальные публичные инциденты не как повторный прогон новостей, а через призму «как бы вы от этого защитились». Эта статья основана на публичных материалах (регуляторы, журналистика, академический анализ, официальные заявления), ссылки приведены в конце.
- Цель
- 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 метаданных был защищён предположением «недостижим снаружи». Но 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
- Защита: Встройте минимальные привилегии и мониторинг машин в эксплуатацию
FAQ
QВ чём была первопричина утечки Capital One?
Не одна причина, а несколько слоёв защиты, отказавших последовательно. Точкой входа стала уязвимость SSRF (сервер можно было заставить проксировать запрос к произвольному адресу назначения). Отсюда стал достижим облачный endpoint метаданных, а стоявшая за ним роль IAM имела широкие права, поэтому временные учётные данные позволили злоумышленнику прочитать всё хранилище.
QИмеет ли это значение для моего небольшого сервиса?
Да. SSRF возникает из обычных функций, которые «принимают URL и загружают его» (превью, вебхуки). В облаке кража учётных данных с endpoint метаданных происходит независимо от масштаба. Три исправления из этой статьи (IMDSv2, минимальные привилегии IAM, список разрешённых адресов назначения) работают и для инди-проектов.
QПомог бы WAF предотвратить это?
Нет. В этой утечке компонент, выполнявший роль WAF, сам стал плацдармом для SSRF. WAF блокирует часть атак, но при неправильной настройке сам становится дырой. «У нас есть WAF, значит мы в безопасности» — это заблуждение: валидация ввода, минимальные привилегии и защита метаданных — вот настоящая защита.