Cloud Metadata Leakage: Когда облака текут как твой кран на кухне

Ты думал, что облако — это безопасно? Хаха, это как оставить ключ от квартиры под ковриком с надписью «не бери». Cloud Metadata — это служебная инфа, которую AWS, Azure, GCP и прочие гиганты хранят для своих инстансов. Там лежат токены, ключи, IAM-роли, да хоть пароль от Wi-Fi админа, если повезёт. И всё это доступно через эндпоинты типа 169.254.169.254 или /latest/meta-data/. Проблема? Если ты криво настроил сетку или твой код лоханулся, любой, кто добрался до твоей тачки, может слить это добро.

Точка входа
Что вижу: Эндпоинт http://169.254.169.254/latest/meta-data/ или его клоны (Azure — /metadata/instance, GCP — /computeMetadata/v1/). Если сервер отвечает 200 OK, это не баг, это твой личный паспорт в ад.

Как поймал: Запустил curl http://169.254.169.254/latest/meta-data/iam/security-credentials/ с локальной тачки или через SSRF (Server-Side Request Forgery) на уязвимом веб-приложении. Инструмент — простой curl или Burp Suite для проксирования.

Чем пахнет: Класс уязвимости — Information Disclosure с прямым переходом в RCE, если токены IAM дают доступ к S3 или другим сервисам. Вероятность: 9/10, если сервер в облаке и админ рукожоп.

Че почем
Эксплойт: Вот тебе рабочий запрос, братан. Если ты внутри инстанса или через SSRF пробил доступ:

Получил роль? Забирай временные ключи:

Это тебе Access Key, Secret Key и Token. Дальше — твори магию, например, через AWS CLI: aws s3 ls с этими ключами. Если S3 открыт — ты царь.

Обход защиты: Если IMDSv2 (новая защита AWS) включён, тебе нужен заголовок X-Aws-Ec2-Metadata-Token. Как добыть? Через уязвимые приложения, которые делают запросы от имени сервера (SSRF). Пример:

Если токена нет, ищи старые инстансы с IMDSv1 — там защита как твоя бывшая: орёт «403», а внутри пусто.

Доказательство: Видишь JSON с «AccessKeyId»: «AKIA…»? Это не фотка кота, это твой билет на баг-баунти. Скриншоть и готовь отчёт для HackerOne.

Советы:
3 вектора для добивания:

Если прямой доступ к 169.254.169.254 не катит, ищи SSRF в API или уязвимых параметрах типа ?url=http://169.254.169.254. Это твой план Б.

Проверяй заголовки ответа на предмет облачных артефактов (X-Amz-…, Azure-Instance-Metadata: true). Это намёк, где копать.

Если инстанс в Docker, пробуй curl —unix-socket /var/run/docker.sock http://localhost/images/json. Может, через контейнер доберёшься до хоста, а там и до metadata.

План атаки:

Сканируй эндпоинты через curl или автоматизируй с помощью ffuf на предмет вариаций /metadata, /meta-data, /computeMetadata.

Если ключи добыл — используй их для доступа к S3 через aws s3 cp s3://bucket-name/secret.txt . или аналог для Azure/GCP.

Дампь всё, что можно, ищи приватные данные (конфиги, SSH-ключи). Потом пиверти на полный контроль через создание нового IAM-юзера или бэкдора.

Почему это важно, бро?
Cloud Metadata Leakage — это не просто баг, это системный фейл, который тянет за собой целую цепочку эксплойтов. Один токен — и ты в S3, второй — и ты в Lambda, третий — и ты root на всех инстансах. Реальный кейс: Capital One Breach 2019 (CVE-2019-ХХХХ), где через SSRF слили данные 100 млн юзеров из-за доступа к metadata. Эксплойт лежал в открытом доступе на GitHub, просто никто не чухнулся.

Так что, если видишь облачный инстанс, бей в колокол и копай. Это как найти кошелёк на улице: либо донесёшь до хозяина (баг-баунти), либо потратишь на пиццу (ну ты понял). Если застрял — иди спать, бро. Или попробуй ещё раз с другим IP. А если прям пиздец — иди учи Rust. Хакерская жизнь — она такая, через боль и слёзы. Погнали дальше, держи бургер!