В реальной практике существует несколько кейсов, с которыми можно столкнуться при повышении от AFW к RCE в веб-приложениях. Их можно обобщенно разделить на следующие категории:
🔘Контроль полного пути файла или только имени загружаемого файла, но не его содержимого.
В зависимости от разрешений, применяемых к целевой директории и целевому приложению, последствия могут варьироваться от DoS до вмешательства в логику приложения с целью обхода потенциально уязвимых функций.
🔘Контроль только над содержимым загружаемого файла, но не над его путем. В этом случае последствия могут сильно различаться из-за множества факторов.
🔘Полная произвольная запись файла: контроль и над путем, и над содержимым файла. Это часто приводит к RCE с использованием различных методов.
Тактики для достижения RCE через AFW:
1️⃣ Перезапись или добавление файлов, обрабатываемых сервером:
— Конфигурационные файлы (
.htaccess, .config, web.config, httpd.conf)— Исходники, доступные для выполнения (
.php, .jsp)— Временные/сессионные файлы, файлы с секретами
2️⃣ Манипуляции с procfs для выполнения произвольного кода
3️⃣ Перезапись системных файлов:
— Cron, bash-скрипты (
.bashrc, .bash_profile)— Файлы
authorized_keys и authorized_keys2 для получения доступа через SSH👉 Еще один интересный кейс
Предположим, что уязвимость позволяет загружать и изменять файлы через функцию экспорта в PDF.
Приложение работает на uWSGI, который поддерживает различные способы конфигурации, включая загрузку конфигов через обычные
.ini файлы. uWSGI поддерживает «магические» переменные (
@exec://), которые позволяют выполнять произвольные команды.При включенной опции
py-auto-reload перезагрузка конфигурации может быть вызвана изменением Python-файлов, что дает шанс выполнить команду.💪 Собираем в цепочку
1️⃣ Генерируем и проверяем PDF-файл:
uwsgi --ini payload.pdf
2️⃣ Загружаем payload.pdf в
/app/console/uwsgi-sockets.ini3️⃣ Ждем перезапуск сервера или принудительно перезагружаем uWSGI, перезаписав все
.py файлы4️⃣ Проверяем коллбэк и сдаем багу