Информационная безопасность (ИБ)
January 19

Путешествие от Limited Path Traversal к RCE с вознаграждением в $40,000!

Меня зовут Абдулла Наваф, я занимаюсь баг-баунти на полную ставку, активно работаю с BugCrowd и вхожу там в Топ-50, 11-е место по P1 багам с 226 P1. Я охочусь за P1 и P2 ошибками.

В этом документе я подробно расскажу, как я и Орва Атият успешно раскрутили ограниченный обход пути (limited path traversal) в удалённое выполнение кода (RCE), заработав таким образом вознаграждение в 40 000 долларов.

Описание:

Во время проведения разведки и сканирования портов нашей цели мы обнаружили поддомен с открытым портом 8443, http://admin.target.com:8443. Ответ к сожалению был 404, и большинство охотников игнорировали бы такие поддомены, возвращающие 404. Но я не!

При фаззинге http://admin.target.com:8443/FUZZ я обнаружил путь /admin/, который переадресовывал на страницу входа http://admin.target.com:8443/admin/faces/jsf/login.xhtml. После тестирования этой точки входа и не обнаружения уязвимостей, я решил продолжить фаззинг по пути ‘admin’, например http://admin.target.com:8443/admin/FUZZ. Я наткнулся на точку /download/, расположенную по адресу /admin/Download, которая возвращала код состояния 200, но с пустым ответом.

Из имени конечной точки можно сделать вывод о её функции! Однако нам не хватает правильных параметров, и нам нужен 100% действительный файл и путь. Поскольку конечная точка находится под /admin/, мы должны искать файлы, которые обычно функционируют в административной директории. Как правило, я начинаю искать LFI и Path Traversal, используя JavaScript файлы, поэтому я начал свои тесты с файла под названием admin/js/main.js. Этот подход помогает нам определить уязвимости LFI и обхода пути, а также выявить доступные пути. Кроме того, поскольку нам нужно определить правильный параметр, который требует /download, мы должны использовать действительно существующий файл, которым является /admin/js/main.js. Это гарантирует, что, когда мы будем выполнять фаззинг правильного параметра, мы его не пропустим. Команда для фаззинга была структурирована следующим образом:

По результатам фаззинга мы знаем, что /admin/download принимает параметр с именем filename. Таким образом, доступ к http://admin.target.com:8443/admin/download?filename=/js/main.js отображает файл по адресу http://admin.target.com:8443/admin/js/main.js. Первое, что я попробовал – это добиться полного обхода пути, попробовав прочитать /etc/passwd. К сожалению, функция /download работает только для файлов внутри /admin/*; всё, что находится за пределами /admin/, работать не будет. Однако это подтверждает, что у нас действительно есть уязвимость ограниченного обхода пути!

Поскольку мы работаем в Java-среде, я попытался прочитать /WEB-INF/web.xml, потому что этот файл часто содержит много полезной информации. Перейдя по адресу http://admin.target:8443/admin/download?fileName=/WEB-INF/web.xml, я смог получить доступ к некоторой интересной информации!

Обратите внимание, что мы нашли три URL: /download/, /faces/ (которые мы уже знали) и новый: /incident-report. Посещение http://admin.target:8443/admin/incident-report вызвало нечто неожиданное: началось скачивание огромного лог-файла под названием incident-report-xxxxxx.zip. Этот файл оказался логом реального времени!

Лог-файл был таким:

Каждый раз, когда вы посещаете http://admin.target:8443/admin/incident-report, новый лог-файл скачивается, потому что логи генерируются в реальном времени.

Должен ли я остановиться здесь и отчитаться об этом? Многие охотники могли бы завершить своё исследование на этом этапе! Но не я!

Эскалация влияния:

Изучая лог-файлы, я нашёл файл с паролями админов:

21232f297a57a5a743894a0e4a801fc3:admin (md5), не сработал. Как видно из файла - это был старый пароль, следующий был 2a92e4f4ecc321db24c8f389a287d793:Glglgl123.

Я снова перешёл к странице входа, /admin/faces/jsf/login.xhtml, попробовал admin:Glglgl123, и это сработало с полным доступом к панели в качестве администратора!

После входа я нашёл функцию под названием export_step2.xhtml, в которой есть консоль Groovy, поэтому я остановился здесь и отчитался об этом, а затем попросил владельца программы возможности испытать удачу и попробовать докрутить до RCE.

Прежде чем углубиться, давайте поймём, что такое Groovy консоль. Это инструмент разработки и отладки, который предоставляет интерфейс для выполнения скриптов Groovy. Разработчики часто используют его для тестирования фрагментов кода, изучения API и прототипирования функциональности прямо внутри контролируемой среды. Обычно она доступна только доверенным пользователям на внутренних системах, так как позволяет выполнять произвольный код.

Проблемы с безопасностью при доступе без надлежащей аутентификации:

- Произвольное выполнение кода: Если неавторизованное лицо получит доступ к консоли Groovy, оно сможет выполнять любой код Groovy или Java на сервере. Это может привести к удалённому выполнению кода (RCE), что потенциально позволит злоумышленникам украсть данные, скомпрометировать другие приложения или получить полный контроль над сервером.

- Утечка конфиденциальной информации: Злоумышленник может выполнить команды для чтения конфигурационных файлов, переменных окружения или даже учётных данных, хранящихся на сервере. Это предоставит дополнительные возможности для эксплуатации и горизонтального продвижения.

- Эскалация прав: Если консоль Groovy работает с повышенными привилегиями, злоумышленник может выполнять операции, к которым обычные пользователи приложения не имеют доступа. Это может включать создание или удаление файлов, изменение логики приложения или установку вредоносного ПО.

В кратце, несанкционированный доступ к консоли Groovy может эффективно превратить её в бэкдор для злоумышленников, предоставляя им мощный инструмент для компрометации всей системы.

Так что теперь, у меня зелёный свет! Время подготовиться к интересному приключению!

RCE:

Возвращаясь к export_step2.xhtml, где есть консоль Groovy; я использовал этот полезный код:

Но, как вы видите, команда была выполнена, но без вывода!

Я попробовал разные команды:

print "id".execute().text
print "sudo cat /etc/passwd".execute().text

К сожалению, та же проблема сохранялась: команды были выполнены, но никаких результатов не было возвращено.

(Для читателя): Есть предположения о том, где может скрываться вывод этой команды?? Если вы угадаете правильно, вы не только почувствуете себя рок-звездой, но и будете намного ближе к получению масштабного вознаграждения!

Цепочка уязвимостей для достижения полного RCE:

Подождите, вы помните функцию http://admin.target:8443/admin/incident-report?

Как упоминалось ранее…

Посещение http://admin.target:8443/admin/incident-report вызвало нечто неожиданное: началось скачивание огромного лог-файла под названием incident-report-xxxxxx.zip. Этот файл оказался логом в реальном времени!

Да! Это оказалось ключом к получению вывода RCE. Посещая http://admin.target:8443/admin/incident-report, я мог скачать свежие логи – и угадайте, что я там нашёл? Вывод RCE!

Эксплуатация теперь проста:
- Войдите с учётными данными, которые мы обнаружили.
- Перейдите к консоли Groovy.
- Выполните команду, например `print "sudo cat /etc/passwd".execute().text` (или попробуйте любую другую команду).
- Теперь перейдите к конечной точке логов по адресу http://admin.target:8443/admin/incident-report.
- Скачайте актуальный лог-файл, и вот он – вывод RCE!

Почему я не попытался использовать OOB-RCE или создать файл на сервере, чтобы обойти все эти шаги? Я знаю, что у вас возник этот вопрос! Ответ прост :)

По двум причинам:
- OOB-RCE невозможен: Есть какое-то подобие WAF, который блокирует любые исходящие соединения на мой IP или любой внешний IP.
- Низкие выплаты: OOB-RCE обычно приводит к меньшему вознаграждению по сравнению с прямым RCE. Поверьте мне – я достаточно долго в этой области, и знаю!

Программа BugBounty запросила, чтобы мы отправили два дополнительных отчёта: один про RCE и другой про учётные данные, которые мы обнаружили. Общее вознаграждение: 40 000 долларов.

Уроки и выводы:
1. Рассматривайте Bug Bounty как игру: думайте об этом, как о квесте – не останавливайтесь, пока не достигнете своей конечной цели. В моем случае конечной целью было достижение RCE и получение вознаграждения в 40К долларов. Многие охотники могут остановиться на первой уязвимости, которую они найдут, и сразу же сообщить о ней. Как вы видели, я не остановился на конечной точке, которая просто скачивала логи, или даже на обходе пути. Я продолжал исследовать, пока не обнаружил большую награду. Этот подход неизменно приводил меня к крупным выплатам!
2. Когда вы находите уязвимость на поддомене, держите её до завершения всех своих тестов на этом поддомене! Как только вы обнаружите уязвимость на поддомене, раскручивайте ее, пока не завершите все свои тесты. Как вы видели, одно небольшое открытие – например, ограниченный обход пути к лог-файлам – может привести к обнаружению паролей администратора, что затем можно довести до RCE. А иногда вы возвращаетесь к той начальной уязвимости, чтобы получить последнюю часть головоломки!
3. Сосредоточьтесь на качестве, а не на количестве: Изначально мы объединили все эти находки в один отчет. Этот подход не только демонстрирует уважение к команде владельца программы, но и зарабатывает большее доверие и потенциально большие выплаты. На самом деле, владелец программы запросил, чтобы мы разделили отчет на отдельные заявки. Почему? Потому что это позволяет им предлагать более высокие вознаграждения за отдельные находки!

Все эти находки были сделаны с OrwaGodfather, с которым мы сотрудничаем в нашей охоте.

Надеюсь, вам было интересно читать!

Источник

Life-Hack Media:

Life-Hack - Жизнь-Взлом

OSINT

Новости Кибербеза

Курсы по программированию

Юмор