Как был найден RCE в одной из публичных программ на Bugcrowd

Всем привет, cегодня я расскажу, как получил RCE на одной из публичных программ Bugcrowd.

Выбирая программу для взлома, я всегда обращаю внимание на программы с широким скоупом, так как они дают мне большую свободу для поиска активов, которые соответствуют моим навыкам. После того как я решил начать взлом одной из публичных программ и провел сбор поддоменов, я решил заглянуть в Shodan для поиска активов, принадлежащих компании, используя этот запрос org:"Company. Inc"

Потратив некоторое время, я нашел интересный актив для начала взлома. Причина выбора этого актива заключалась в том, что я нашел открытые необычные порты, и оба использовали Tomcat/8.5.32

Первое, что я делаю - это провожу полный скан портов на этом IP и передаю вывод в httpx для проверки HTTP сервисов:

naabu -host <ip> -p - -Pn -o portscan | httpx -sc -td -server 

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

Теперь мы нашли порт 8333 с другой версией Tomcat. Отлично, давайте начнем исследование.

Сначала давайте поищем CVE, связанные с этой версией, используя searchsploit

searchsploit "tomcat 7"

К сожалению, ни один из них не сработал на мою цель, включая CVE-2017–12617 и CVE-2020–1938.

Вернувшись на домашнюю страницу, я решил начать фаззинг директорий и файлов. Сначала я попробовал dirsearch с дефолтным словарем

dirsearch -u http://x.x.x.x:8333

Однако, ничего интересного не нашлось, кроме директорий manager и host-manager, которые вернули 401, поэтому я решил проверить стандартные учетные данные с помощью Hydra

hydra -L ~/tomcat-usernames -P ~/tomcat-passwords x.x.x.x -s 8333 http-get /manager/html

Опять же, не найдено действительных пользователей.

Вернулся к фаззингу снова, но на этот раз я использовал словарь из https://github.com/six2dez/OneListForAll.

dirsearch -u <http://x.x.x.x:8333/> -w ~/wordlist/OneListForAll/onelistforallshort.txt

и на этот раз я нашел новую директорию с формой входа

/sdp/ >> 302 >> /sdp/validateUser.action 

Я сразу же начал тестирование на SQL-инъекции, но безуспешно.

Тогда я вспомнил про CVE-2017–5638 и использовал шаблоны nuclei на этом эндпоинте, но снова результатов не было.

Я опять вернулся к фаззингу директорий после эндпоинта /sdp/ , и на этот раз я нашел новую директорию /sdp/struts/webconsole.html?debug=console

В тот момент я был очень рад, думая, что получил RCE, но снова, в сотый раз, я столкнулся с множеством JS ошибок в консоли, и каждый раз, когда я исправлял одну, появлялась другая. И в итоге я выводил код в консоли OGNL без выполнения команд.

Я вернулся к вкладке History в Burp Suite и, прокручивая запросы, нашел новый файл showLogin.action. Из-за отчаяния я решил попробовать один payload, который нашел, изучая лабораторные работы и отчеты, связанные с Apache Struts 2 и OGNL Injection.

Payload был таким:

Он выполняет команду id на сервере. Я добавил этот payload в showLogin.action и отправил его как GET-запрос.

Вдруг случилось то, чего я никак не ожидал.

Я сообщил об этой уязвимости в BugCrowd, и они сразу же ее обработали, но программа позже понизила ее до P2, заявив, что это был устаревший актив, и решили проблему, удалив этот IP.

Спасибо за просмотр, надеюсь, вы узнали что-то новое.

Оригинал статьи на английском тут.

Подпишись на канал - @shadow_group_tg.