Три GET-запроса до полного доступа: как SSRF превращается в ключи от облака

Представьте: обычный PDF-генератор в финтех-приложении принимает URL для рендера документа. Подставляем http://169.254.169.254/latest/meta-data/iam/security-credentials/ — и через одиннадцать минут уже выполняем aws s3 ls с credentials IAM-роли, у которой права на S3 и DynamoDB.

Это не лабораторный сценарий. В марте 2025 года F5 Labs зафиксировала массовую кампанию: атакующие перебирали шесть вариантов параметров (dest, file, redirect, target, uri, url) в сочетании с четырьмя путями к metadata endpoint. Автоматизированно, по всему интернету.

🔑 Почему в облаке всё иначе?

На классическом сервере SSRF — это чтение /etc/passwd или сканирование внутренних портов. Неприятно, но терпимо. В облаке та же уязвимость открывает доступ к временным токенам IAM-роли, а это — путь ко всему аккаунту. Разница как между ключом от подсобки и мастер-картой от целого здания.

Instance Metadata Service v1 в AWS не требует вообще ничего — ни токенов, ни заголовков. Простой GET на link-local адрес 169.254.169.254 возвращает всё. SSRF делает запрос от имени сервера, то есть изнутри — приложение само ходит за своими credentials и отдаёт их вам.

⚡️ Цепочка эксплуатации — три шага:

1. Подставляем в уязвимый параметр путь к metadata — получаем имя IAM-роли (например, webapp-prod-role)
2. Запрашиваем credentials конкретной роли — получаем JSON с AccessKeyId, SecretAccessKey и SessionToken
3. Экспортируем переменные окружения, запускаем aws sts get-caller-identity — если в ответе ARN роли, credentials рабочие

Бонус: endpoint /latest/user-data часто содержит скрипты инициализации с паролями баз данных и API-ключами, которые разработчики вписали «для удобства при запуске». Удобно всем — особенно атакующему.

🛡 А что с GCP и Azure?

Google Cloud требует заголовок Metadata-Flavor: Google, Azure — Metadata: true. Это усложняет атаку, но не закрывает её: если SSRF позволяет контролировать заголовки или есть CRLF-инъекция в URL-параметре, барьер обходится. А в ECS-контейнерах credentials живут по другому адресу — 169.254.170.2, и путь к ним лежит в /proc/self/environ.

По MITRE ATT&CK цепочка выглядит так: SSRF как initial access (T1190) → кража credentials через metadata (T1552.005) → аутентификация в облачном API → перечисление ресурсов → выгрузка данных. Шесть шагов от веб-формы до полного компрометирования аккаунта.

Полный разбор с командами, байпасами IMDSv2 и постэксплуатацией — в статье на форуме.

https://codeby.net/threads/ssrf-ataka-na-oblachnyye-credentials-ekspluatatsiya-metadata-endpoint-ot-imdsv1-do-post-ekspluatatsii.93011/