juanschallibaum/cve-2024-38473-nuclei-templateШаблон Nuclei для обнаружения серверов Apache, уязвимых к CVE-2024-38473
Шаблон Nuclei, предназначенный для обнаружения уязвимых серверов Apache к CVE-2024-38473. Сначала он определяет серверы, работающие на Apache < 2.4.60 с настройками PHP-FPM по умолчанию. Затем он фаззит потенциальные PHP-файлы, защищённые ACL, которые можно обойти из-за этой уязвимости.
Для использования этого шаблона Nuclei необходимо клонировать репозиторий. Вы можете сделать это, выполнив следующую команду:
git clone https://github.com/juanschallibaum/CVE-2024-38473-Nuclei-Template
Перейдите в каталог клонированного репозитория:
cd CVE-2024-38473-Nuclei-Template
Запуск шаблона nuclei для одного хоста:
nuclei -t CVE-2024-38473.yaml -u http://example.com
Запуск шаблона nuclei для списка хостов:
nuclei -t CVE-2024-38473.yaml -l hosts.txt
Запуск шаблона nuclei для одного хоста с указанием валидного .html или .php файла:
nuclei -t CVE-2024-38473.yaml -u http://example.com/valid.php
Запуск Nuclei таким образом может повысить уровень обнаружения. Вы также можете включить URL-адреса в этом формате в файл hosts, чтобы запустить шаблон против этого списка.
Чтобы легко протестировать уязвимость CVE-2024-38473, вы можете поднять уязвимое окружение с помощью Docker. Выполните следующие шаги для быстрой проверки эффективности шаблона Nuclei:
Убедитесь, что Docker Daemon запущен: Убедитесь, что демон Docker запущен на вашей системе. Вы можете запустить его следующей командой, если он ещё не запущен:
sudo systemctl start docker
Запустите Docker-контейнер: В каталоге репозитория используйте следующую команду Docker для запуска контейнера с уязвимой конфигурацией Apache и PHP-FPM:
docker run -p 8787:80 -v "$(pwd)/test-env-webroot:/app" webdevops/php-apache:7.1
Проверьте уязвимость:
Вручную: Откройте веб-браузер и перейдите по адресу http://localhost:8787, чтобы взаимодействовать с сервером Apache, работающим в контейнере Docker. Перейдите по адресу http://localhost:8787/info.php для тестирования уязвимости. Этот файл защищён ACL, и если обход ACL успешен, вы увидите вывод phpinfo():
Используя шаблон Nuclei: Выполните следующую команду Nuclei для тестирования сервера с помощью шаблона:
nuclei -t CVE-2024-38473.yaml -u http://localhost:8787
8 августа 2024 года исследователь безопасности Orange Tsai выступил с докладом на Black Hat USA 2024 под названием: Confusion Attacks: Exploiting Hidden Semantic Ambiguity in Apache HTTP Server!. В этом докладе он сообщил о множестве уязвимостей, затрагивающих Apache HTTP Server. Он объяснил, что Apache имеет высокомодульную архитектуру, состоящую из сотен модулей, каждый из которых выполняет свою функцию, читая и записывая данные в общую структуру request_rec, содержащую почти 100 полей.
Коренная причина уязвимостей, о которых сообщил исследователь, заключается в несогласованности обработки различных полей этой общей структуры разными модулями Apache. Например, mod_authz_core интерпретирует поле r->filename как файл, тогда как mod_proxy интерпретирует его как URL-адрес, что приводит к расхождениям и множеству уязвимостей.
В своём докладе Orange Tsai определяет тип атаки под названием "Filename Confusion". Хотя поверхность этой атаки разнообразна, CVE-2024-38473, которую мы рассматриваем в этом шаблоне, относится к тому, как применить атаку "Filename Confusion" для обхода ACL Apache и получения доступа к ограниченным файлам.
Проблема возникает, когда модуль аутентификации Apache mod_authz_core интерпретирует атрибут r->filename как файл, в то время как mod_proxy интерпретирует его как URL-адрес. Из-за этого установки Apache с PHP-FPM в конфигурации по умолчанию подвержены этой уязвимости. Представьте, что сервер, работающий на Apache и PHP-FPM, имеет настроенный ACL, подобный следующему, для защиты доступа к файлу admin.php с учётными данными:
<Files "admin.php">
AuthType Basic
AuthName "Admin Panel"
AuthUserFile "/etc/apache2/.htpasswd"
Require valid-user
</Files>
Из-за уязвимости можно обойти ACL, подобный приведённому выше, который защищает отдельный файл. Фактически, это можно сделать, просто отправив такой запрос: http://server/admin.php%3fooo.php.
Чтобы понять это в деталях, важно учесть, что когда Apache обрабатывает подобный запрос, модуль mod_authz_core читает значение admin.php?fooo.php из поля r->filename общей структуры. Он интерпретирует это значение как имя запрашиваемого файла, и при сравнении с ACL оно не совпадает, потому что admin.php?fooo.php отличается от admin.php.
Затем, поскольку admin.php?fooo.php заканчивается на .php, запрос передаётся в PHP-FPM. PHP-FPM удаляет всё после ? в имени файла, полученном от Apache, перед обработкой, интерпретируя его как URL-адрес, а не как файл. В результате PHP-FPM обработает непосредственно admin.php. Поскольку проверка ACL была пройдена ранее, злоумышленник может получить доступ к admin.php без аутентификации.
Текущий шаблон Nuclei направлен не только на обнаружение защищённых файлов методом перебора, но и включает логику для определения, когда сервер имеет уязвимую конфигурацию Apache < 2.4.60 с PHP-FPM, даже если случаи файлов, защищённых ACL, не обнаружены. В базовом потоке он сначала пытается определить, имеет ли сервер уязвимую конфигурацию, а затем, если это так, пытается выявить общие файлы, которые могут быть защищены ACL.
Идея обнаружения уязвимых конфигураций с Apache < 2.4.60 и PHP-FPM основана на двух основных предпосылках:
В уязвимой конфигурации, если file.php существует на сервере, то запрос к http://server/file.php%3fooo.php вернёт тот же статус 200 и ту же длину тела, что и запрос к http://server/file.php (поскольку после удаления %3fooo.php PHP-FPM запрашиваемый файл будет тем же самым).
В уязвимой конфигурации, если file.html существует на сервере, то запрос к http://server/file.html%3fooo.php вернёт 403 Access Denied. Это происходит потому, что PHP-FPM попытается загрузить файл с расширением .html вместо .php, что по умолчанию не разрешено.
Поток шаблона состоит из 7 групп запросов. Они должны выполняться последовательно и должны соответствовать соответствующим условиям для перехода к следующей группе запросов. Это помогает минимизировать количество запросов, отправляемых впустую, если условия уже не выполняются.
Шаблон отправляет запрос к index.phpooo.php%3fooo.php, который является несуществующим файлом. Идея — отсеять ложные срабатывания в случаях, когда index.php%3fooo.php возвращает статус 200 и то же тело, что и index.php, даже если PHP-FPM не настроен. Это может произойти, например, при наличии правил, которые переписывают любой запрошенный файл или файлы, начинающиеся с "index", на index.php, как:
RewriteRule . /index.php [L]
RewriteRule ^index\.php(.*)$ index.php [L]
RewriteRule ^index(.*)$ index.php [L]
Этот запрос должен вернуть статус 200, если на сервере есть такие правила, или статус 404 в обычных случаях, когда PHP-FPM может быть настроен. Если этот запрос не возвращает статус 404, шаблон прекратит обработку этого хоста.