Перевод: Как я нашел свой первый RCE!

Удаленное выполнение кода (RCE) - это мечта всех, но только некоторые из них смогли его найти. Эта история о том, как я смог найти свою RCE, используя простые методы fuzzing и немного разведки. Итак, начнем....

Моя методология:

1. Собрать домены, входящие в зону охвата.
2. Начать активное и пассивное перечисление субдоменов. Инструменты, используемые для перечисления пассивных субдоменов: subfinder (с API-ключами различных сервисов, таких как Shodan, Chaos, GitHub, Sublist3r и т.д.). Для активного перечисления поддоменов использовался Best DNS Wordlist от Assetnote Wordlist.
3. Было найдено около 219 поддоменов

4. Следующим шагом была фильтрация живых доменов на основе кода состояния.

5. Я быстро нашел поддомен accounts.example.com с кодом состояния 403 Forbidden.

6. И вот тут начинается настоящее путешествие.

Итак, я вооружился FFuF и словарем из знаменитого Seclists и начал сканирование. Нашел конечную точку /fileupload/toolsAny, которая, как оказалось, была уязвима к CVE-2022-29464.

CVE-2022-29464 - это критическая уязвимость в WSO2, обнаруженная Orange Tsai. Уязвимость представляет собой неограниченную произвольную загрузку файлов, которая позволяет неаутентифицированным злоумышленникам получить RCE на серверах WSO2 через загрузку вредоносных JSP файлов.

Уязвимой конечной точкой была /fileupload, используя которую злоумышленник мог загрузить .jsp файл, что могло привести к обратному shell на машине жертвы.

Как только я подтвердил уязвимость, следующей задачей было найти подходящий эксплойт. Для этого было два подхода: либо перехватить запрос в Burp и изменить его, либо использовать готовый эксплойт. Давайте разберем шаги для обоих вариантов

Метод 1: Использование Burp

1. Захватите запрос конечной точки в Burp Suite
2. Измените метод с GET на POST
3. Вместе с заголовком Content-Disposition введите имя конечной точки, а также имя и название файла. Например:

Content-Disposition: form-data; name=".../.../.../.../repository/deployment/server/webapps/authenticationendpoint/MyShell.jsp";filename="MyShell.jsp"

4. В теле POST введите команду, которая должна быть выполнена файлом file.jsp. Например:

<% out.print("MyShell Uploaded here"); %>.

5. Перейдите на конечную точку accounts.example.com/authenticationendpoint/MyShell.jsp, и ваши команды будут выполнены

Способ 2: Использование эксплойта

1. Перейдите по адресу https://github.com/hakivvi/CVE-2022-29464
2. Клонируйте файл с помощью git clone на локальную машину
3. запустите эксплойт с помощью python3 exploit.py https://accounts.example.com MyShell.jsp
4. Посетите конечную точку https://accounts.example.com/authenticationendpoint/MyShell.jsp.
5. В результате вы сможете выполнить любую команду

Тем временем я эксплуатировал RCE, используя waybackurls на том же домене accounts.example.com, и следующая конечная точка привлекла мое внимание. https://accounts.example.com/shindig/gadgets/proxy?container=default&url=https://google.com.

Я быстро открыл клиент Interactsh и вставил полезную нагрузку.

И БУМ SSRF! Оказалось, что тот же WSO2 тоже был уязвим для SSRF.

Временная шкала

• Обнаружены обе уязвимости: 10 июля 2022 года
• Сообщено: 10 июля 2022 г.
• Первоначальная реакция: 11 июля 2022 г.
• Награжден Залом славы + рекомендательное письмо: 13 июля 2022 г.

Оригинал статьи - здесь.
Поддержите автора хлопками на Medium.

Перевод статьи был выполнен проектом перевод энтузиаста:

• 📚 @Ent_TranslateIB - Телеграмм канал с тематикой информационной безопасности
• 🔥 @Ent_Translate - Инстаграм проекта