Cloud Metadata Leakage: Как облака сливают твои секреты

Залетаем в тему, бро. Ты думаешь, что твой облачный сервер — это крепость? Ага, как мой старый ноут с Kali, который виснет на nmap -A. Cloud metadata leakage — это когда твой AWS, GCP или Azure отдаёт ключи от королевства любому, кто знает, куда глянуть. Это не баг, это фича, которую ты забыл закрыть. Погнали разбирать, как это работает, и как ты можешь либо слить, либо защитить свою задницу.

Точка входа: Где живёт этот слив?

• Что вижу: Эндпоинт типа http://169.254.169.254/latest/meta-data/ (AWS IMDSv1) или похожие пути на GCP/Azure. Если сервер в облаке, то этот IP — магический шлюз к внутренностям твоей инстанции.

• Как поймал: Скан через curl -s http://169.254.169.254/latest/meta-data/identity-credentials/ec2/security-credentials/ec2-instance или тупо с помощью wget. Инструменты? Да хоть netcat, если ты олдскул. Метод — прямой запрос к незащищённому API.

• Чем пахнет: Полный доступ к IAM-ролям, токенам и ключам (RCE через creds, вероятность 9/10, если IMDSv1 открыт). Это как оставить пароль на стикере под клавиатурой.

Чё почём: Как слить или как защитить?

• Эксплойт: Если ты на баг-баунти, просто делай запрос:

Если в ответе JSON с AccessKeyId и SecretAccessKey — поздравляю, ты только что получил билет на AWS-консоль жертвы. Хочешь больше? Вытяни временные токены и крути через aws cli:

• Видишь S3-ведра? Это не твой плейлист, это их данные.

• Обход защиты: Если IMDSv2 включён (AWS требует токен), то байпасим через SSRF. Находишь уязвимый эндпоинт на сайте (например, открытые параметры url=), шлёшь туда:

• WAF? Да пох, юзай HTTP-заголовки вроде X-Forwarded-For: 127.0.0.1 или энкодинг URL, чтобы пробить фильтры.

• Доказательство: Получил ключи? Сделай скрин вывода aws sts get-caller-identity с их токенами. Это тебе не мем с котиком, это PoC на миллион.

Векторы добивания

Если ты на баг-баунти или просто роешься в чужом облаке, вот три пути для добивания:

1. IAM-эскалация: Используй слитые ключи для проверки прав. Пробуй aws iam list-users или aws ec2 describe-instances. Если повезёт — создай нового юзера или инстанцию.

2. S3-дамп: Сканируй S3-бакеты через aws s3 ls. Часто там лежат бэкапы, конфиги или прям пароли в secrets.txt (да, люди тупые).

3. RCE через инстанции: Если есть доступ к EC2, пробуй запустить команду через aws ssm send-command или крути reverse shell из новой инстанции.

Если ты админ и хочешь защититься, то:

1. Включи IMDSv2 (AWS): aws ec2 modify-instance-metadata-options --instance-id i-1234567890abcdef0 --http-tokens required.

2. Поставь фаерволл на уровне инстанции, блочь доступ к 169.254.169.254.

3. Ограничивай IAM-роли: минимум прав, никаких AdministratorAccess для EC2.

План атаки (если ты в деле)

1. Сканируй цель на предмет SSRF или миссконфигов: ffuf -u http://target.com/proxy?url=FUZZ -w wordlist.txt.

2. Пробуй доступ к metadata: curl http://169.254.169.254/latest/meta-data/ (или другие пути для GCP/Azure).

3. Если ключи в кармане — дампи всё через AWS CLI или аналог. Потом пиши репорт и готовься к payout.

Советы

• Смотри robots.txt и sitemap.xml на вебках, часто там валяются пути к админкам или бэкапам, где можно найти облачные creds.

• Если есть JWT в запросах — ломай через jwt_tool -I -pc role -pv admin, ищи слабый алгоритм (alg: none).

• Сканируй на предмет Docker, если видишь заголовки типа X-Docker-Token — бей в /var/run/docker.sock через curl --unix-socket /var/run/docker.sock http://localhost/images/json. Это твой билет в контейнер.

Реальный кейс: CVE и мясо

Возьмём старый добрый баг, типа уязвимости в AWS IMDSv1, где до 2019 года не было токенов (IMDSv2 ввели позже). Эксплойт: прямой запрос к 169.254.169.254 через SSRF в связке с CVE-2019-11043 (PHP-FPM RCE, если оно на серваке). Ссылка на мясо: https://www.exploit-db.com/exploits/47575. Если PHP-FPM открыт, ты в системе за 5 минут.

Cloud metadata leakage — это как твоя бывшая: кричит «403», а внутри всё открыто. Копай глубже, не тупи, и помни: облако — это не безопасность, это иллюзия.