Приветствую, друзья!
В новой статье обсудим уязвимость web-приложений File Inclusion на примере кейса с платформы Hack The Box Academy. Приступим к разбору!
Немного теории
Включение файлов (File Inclusion) — это тип уязвимости, который возникает, когда веб-приложение позволяет пользователю загружать и исполнять файлы. Такие уязвимости особенно опасны, так как дают злоумышленнику возможность выполнить произвольный код на сервере.
Локальное включение файлов (Local File Inclusion, LFI) происходит, когда приложение загружает файлы с сервера, при этом в процессе выбора файла используются данные, которые ввел пользователь.
Эту уязвимость можно использовать для доступа к конфиденциальной информации — например, можно запросить файл с настройками или с паролями. А еще таким образом можно запустить размещенный на сервере скрипт.
Разберем простой пример уязвимого кода:
<?php
$file = $_GET['file'];
include($file);?>
Здесь злоумышленник может передать в параметре file путь к любому файлу на сервере:
http://target.com/index.php?file=/etc/passwd
Это приведет к включению содержимого файла /etc/passwd в ответ, который отобразится на уязвимой странице:
Решаем Skills Assessment
На уязвимом сайте есть 3 страницы с разным функционалом. Home — главная страница, Contacts — страница для обращения к сервису и расписание работы, Apply — страница загрузки резюме.
При просмотре кода корневой страницы видим /api/images.php с параметром p. Это можно исследовать на предмет LFI:
Чтобы видеть обращения к изображениям, зайдём в фильтр запросов Burp Suite и тыкнем галочки у Images:
Таким образом, в истории запросов у нас появляются GET-запросы к картинкам.
Перебираем LFI при помощи Intruder и списка пейлоадов Seclist:
Фильтруем запросы по длине ответа (тыкаем на столбик Length) и видим, что из пейлоадов сработало:
Какая-то базовая защита тут есть, но её оказалось недостаточно. Эндпоинт /api/images.php?p= явно содержит LFI.
Вспоминаем про другие страницы страницы и попробуем вывести их содержимое при помощи LFI:
При изучении кода contact.php можно увидеть параметр region. Если в значении этого параметра есть "." или "/", то запрос не пройдёт. Также важно обратить внимание, что при создании запроса путь один раз декодируется из URL-кодировки. Это важно было узнать на будущее.
Также не забываем, что тут есть страница загрузки резюме.
Смотрим и исходник apply.php и видим ещё файл /api/application.php.
application.php рассказывает нам о том, как происходит загрузка файлов в форму с резюме.
Все файлы грузятся в /uploads/, и имена файлов кодируются в md5.
Создаём PHP-файл shell.php с содержимым <?php system($_GET['cmd']); ?> (код принимает системную команду в параметре cmd и далее выполняет её) и грузим в форму в качестве резюме. Никакой защиты от вредоносных расширений файлов мы не видели в исходнике, а значит то, что он принимает .docx и .pdf — уловка для особо доверчивых.
Успешно закидываем наше резюме:
Теперь нам нужно через параметр region в contact.php обратиться к shell.php. Помним, что все запросы декодируются один раз из URL в исходное сообщение и то, что нельзя использовать "." и "/" в чистом виде, т. к. они блокируются неким внутренним WAF.
В таком случае воспользуемся старым, но проверенным способом — двойная URL-кодировка для WAF Bypass.
../uploads/fc023fcacb27a7ad72d605c4e300b389 превращаем в %252E%252E%252Fuploads%252Ffc023fcacb27a7ad72d605c4e300b389. Для удобства можно воспользоваться CyberChef.
%252E - ../ (в URL)
Ffc023fcacb27a7ad72d605c4e300b389 - shell.php (в md5)
К запросу добавим &cmd=id и наблюдаем выполнение системной команды самим сервером.
Меняем в параметре cmd команду на чтение флага cat /*.txt при помощи простого регулярного выражения (прочитать в корневой директории всё, что с расширением .txt).
И теперь кейс решён! Флаг у нас!
Для того чтобы не запутаться, как проходила атака, я нарисовал простую схему:
Выводы
LFI сейчас не так часто попадается в реальном ПО, но при ненадлежащей фильтрации путей и возможности напрямую обращаться к файлам системы вполне имеет место быть.
В CTF любят писать якобы WAF, который заменяет вредоносные конструкции по типу ..// на .. ..\\ и пути становятся невалидными и не понятными системе, что и делает приложение защищённым, но это точно не панацея. Такие замены можно попробовать обойти при помощи кодировки или построения такого запроса, что замена пойдёт только на пользу злоумышленнику.
Адекватные WAF при виде спецсимволов, используемых для LFI просто блокируют запрос для пользователя или редиректят на главную страницу с очищением пути. Такое поведение наблюдается чаще всего.
LFI остаётся актуальным по сей день и уметь её эксплуатировать будет не лишним.
Спасибо за внимание! Не забывайте оценивать моё творчество лайком. Всех благ!