Утечка Capital One 2019 года: как ошибка в настройке WAF в AWS открыла данные около 106 млн человек

В марте 2019 года посторонний человек через неправильно настроенный веб-файрвол (WAF) на сервере Capital One в AWS получил учётные данные роли этого сервера и скопировал из облачного хранилища данные заявок на кредитные карты — около 100 млн человек в США и около 6 млн в Канаде. Банк узнал об этом только в июле, из письма постороннего человека, который увидел данные на GitHub.

Ни пароли, ни ключи никто не публиковал. Документы Минюста США описывают цепочку так: из-за ошибки в настройке WAF команды снаружи доходили до сервера и выполнялись им, первая команда получала учётные данные роли, вторая перечисляла бакеты, третья копировала данные. Именно от такого класса атак — через открытые файрволы, обратные прокси и SSRF — AWS в ноябре 2019 года добавила защищённую версию сервиса метаданных, IMDSv2.

Главное об утечке в одной таблице

Хронология утечки Capital One

Отдельно 6 августа 2020 года Управление контролёра денежного обращения США (OCC) оштрафовало Capital One на 80 млн долларов. Причина по версии регулятора — банк не выстроил эффективную оценку рисков до переноса значительной части IT в публичное облако и вовремя не исправил недостатки.

Как работала атака

В обвинительном заключении схема описана по шагам.

1. Сканеры проверяли публичную часть серверов, которые клиенты арендовали у облачного провайдера, и искали такие, где ошибка в настройке WAF позволяла командам снаружи дойти до сервера и выполниться.
2. На найденные серверы отправлялись команды, которые получали учётные данные конкретных учётных записей или ролей клиента.
3. С этими учётными данными атакующая получала список бакетов, а затем копировала из них всё, на что у роли хватало прав, на свой сервер.

Документы суда описывают механику общими словами, но инженеру она знакома: так работают атаки через открытый прокси и SSRF (Server-Side Request Forgery), когда приложение можно заставить сделать HTTP-запрос туда, куда нужно атакующему. Самая ценная цель на EC2 — сервис метаданных инстанса по адресу 169.254.169.254. Он отдаёт программам на сервере временные ключи IAM-роли, привязанной к машине. В первой версии сервиса, IMDSv1, для этого хватало обычного GET:

$ curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/
app-role
$ curl -s http://169.254.169.254/latest/meta-data/iam/security-credentials/app-role
{
  "Code" : "Success",
  "LastUpdated" : "...",
  "Type" : "AWS-HMAC",
  "AccessKeyId" : "ASIA...",
  "SecretAccessKey" : "...",
  "Token" : "...",
  "Expiration" : "..."
}

Если WAF или прокси готов переслать такой запрос по просьбе снаружи, ключи роли уходят наружу. Дальше всё решают права роли. Роль, которая нужна файрволу, умела перечислить больше 700 бакетов и читать заявки на кредитные карты.

Шифрование на стороне хранилища здесь не спасает: владелец ключей роли с правом чтения получает данные уже расшифрованными. В жалобе сказано, что часть полей, например SSN, была токенизирована или зашифрована, а имена, адреса, даты рождения и кредитная история — нет.

Что изменил IMDSv2

19 ноября 2019 года AWS выпустила вторую версию сервиса метаданных. Теперь сессия начинается с PUT-запроса за токеном, а каждый следующий запрос несёт токен в заголовке:

$ TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" \
    -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
$ curl -s -H "X-aws-ec2-metadata-token: $TOKEN" \
    http://169.254.169.254/latest/meta-data/iam/security-credentials/

Против чего это работает:

• Открытые WAF и обратные прокси почти никогда не пропускают PUT.
• Типичная SSRF позволяет управлять адресом, но не методом и не заголовками запроса. Получить токен и потом подставить его она не может.
• Заголовок X-Forwarded-For. Если он есть в запросе, IMDSv2 токен не выдаёт. Его добавляет большинство прокси.
• TTL пакета с ответом равен 1. Токен не уйдёт дальше самой машины, даже если она по ошибке настроена как маршрутизатор.

Важная оговорка: в 2019 году обе версии остались включены по умолчанию. Защита работает, только когда IMDSv1 на инстансе выключен:

$ aws ec2 modify-instance-metadata-options --instance-id i-0abc123 \
    --http-tokens required --http-put-response-hop-limit 1

В Terraform то же самое задаётся блоком metadata_options с http_tokens = "required". Перед переключением проверьте метрику CloudWatch MetadataNoToken: она считает обращения без токена, то есть софт, который ещё ходит по IMDSv1 и сломается. Когда она держится на нуле, IMDSv1 можно выключать.

Уроки для DevOps

1. Роль сервера — это ключ, и ключ должен быть маленьким

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

2. IMDSv2 обязателен, IMDSv1 выключен

Включите http_tokens = "required" в шаблонах запуска, модулях Terraform и образах. Для контейнеров на EC2 hop limit 1 обычно означает, что под до метаданных не достучится, — и это правильно, если роль нужна только узлу. Роли подам лучше выдавать отдельно, а не через роль всей машины.

3. Аномалии видны в логах, если их кто-то смотрит

Capital One сообщила следствию, что роль *****-WAF-Role в обычной работе не вызывает List Buckets. Эти вызовы шли с выходных узлов TOR и адресов VPN, и всё это было в логах. Роль сервера, которая вдруг перечисляет все бакеты, или ключи инстанса, которые используются не с него, — повод для алерта в тот же час, а не находка при расследовании через четыре месяца.

4. Секреты утекают не только из облака

В 2021 году атакующие собирали переменные окружения из CI через подменённый скрипт Codecov, а в 2016 году данные 57 млн человек утекли у Uber через ключ AWS в приватном репозитории. Во всех трёх историях один ключ давал доступ к слишком многим данным.

5. Программа раскрытия уязвимостей работает

Capital One узнала об утечке не от мониторинга, а из письма на адрес для сообщений об уязвимостях. Без понятного адреса вроде security@ и файла security.txt человек, нашедший ваши данные, может не найти, кому написать.

Что проверить у себя завтра:

• на каких инстансах ещё разрешён IMDSv1;
• какие права у ролей серверов, которые принимают запросы из интернета;
• есть ли алерт на необычные вызовы API от ролей инстансов;
• куда внешний человек напишет, если найдёт ваши данные.

Реши сам

Вопрос 1. Ключи никто не публиковал. Как у постороннего оказались учётные данные роли?

1. Ключи лежали в коде на GitHub
2. Неправильно настроенный WAF выполнял команды снаружи, и одна из них получила учётные данные роли сервера
3. Пароль администратора подобрали перебором
4. Их выдал AWS по запросу в поддержку

Вопрос 2. Почему при IMDSv2 типичная SSRF уже не достаёт ключи?

1. IMDSv2 шифрует ключи роли
2. Нужен токен сессии, который выдают только на PUT-запрос со специальным заголовком, а SSRF обычно не управляет ни методом, ни заголовками
3. IMDSv2 отключает роли у серверов
4. IMDSv2 доступен только по SSH

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

Сколько людей пострадало от утечки Capital One? Около 100 млн человек в США и около 6 млн в Канаде. Среди данных около 140 000 номеров SSN, около 80 000 номеров банковских счетов и около 1 млн канадских номеров SIN. Номера кредитных карт и учётные данные для входа, по заявлению банка, не пострадали.

Взломали ли AWS? Нет. По обвинительному заключению, атакующая искала и использовала ошибки в настройке WAF на серверах, которые клиенты арендовали у облачного провайдера. Сама Capital One называет причину уязвимостью конфигурации в своей инфраструктуре.

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

Что стало с атакующей? В июне 2022 года присяжные признали её виновной в мошенничестве с использованием электронных средств связи и несанкционированном доступе к компьютерам. В октябре 2022 года суд назначил отбытый срок и пять лет пробации.

Пройти похожий сбой самому

В симуляторе DevOps KAI Lab разбор Capital One стоит в девятом месяце, посвящённом облаку и Terraform. Там же — «Дежурство по облаку» и постмортем о бакете с отчётами продавцов, который 22 минуты был открыт всему интернету.

Начать можно бесплатно: тест навыков и первые задания первого месяца.

Источники

• Capital One. Information on the Capital One cyber incident — даты, пострадавшие, состав данных.
• Минюст США. United States v. Paige Thompson — страница дела: жалоба от 29.07.2019 и расширенное обвинительное заключение от 17.06.2021.
• Минюст США. Сообщение о вердикте, 17.06.2022, и о приговоре, 04.10.2022.
• OCC. OCC Assesses $80 Million Civil Money Penalty Against Capital One, 06.08.2020.
• AWS. Transition to using Instance Metadata Service Version 2 — метрика MetadataNoToken и порядок перехода.
• AWS Security Blog, Colm MacCárthaigh. Add defense in depth against open firewalls, reverse proxies, and SSRF vulnerabilities…, 19.11.2019 — как устроен IMDSv2.