dungsocool/cve-2017-10271Пошаговое лабораторное руководство по эксплуатации CVE-2017-10271 (десериализация WebLogic XMLDecoder с удаленным выполнением кода) с ручной сборкой полезной нагрузки, обходом слепого RCE и техниками пост-эксплуатации, включая проверку привилегий и эксфильтрацию данных.
AdminServer, принадлежащий base_domain, работающий в Development Mode).7001.http, t3, iiop, ldap, snmp.t3 через порт 7001. Эта конфигурация по умолчанию несет высокий риск, если версия WebLogic не исправлена от уязвимостей, связанных с Java-десериализацией через RMI (Remote Method Invocation).http на порту 7001, что делает его восприимчивым к сканированию каталогов для поиска чувствительных конечных точек, таких как /console/login/LoginForm.jsp.После того как мы определили открытые порты цели, мы используем nmap для сканирования порта и выяснения его запущенного сервиса.
Таким образом, на цели запущен HTTP-сервис с версией Oracle WebLogic Server 10.3.6.0 — хорошо известный корпоративный Java-сервер приложений, известный серией критических CVE (например, десериализация, обход аутентификации). Однако только этой информации недостаточно, чтобы определить, к какой именно уязвимости восприимчива система. Нам необходимо просканировать глубже сопутствующие компоненты веб-сервисов.
Приступим к идентификации её чувствительных конечных точек с помощью инструмента dirsearch. Поскольку WebLogic работает на платформе Java, файлы .jsp и .xml являются наиболее чувствительными целями. Мы сосредоточимся на конечных точках, возвращающих код состояния 200.
dirsearch -u http://192.168.3.137:7001/ -e jsp,xml,html
/console/login/LoginForm.jsp: Портал входа в веб-интерфейс консоли администрирования WebLogic. Это важная цель для сценариев перебора учетных данных по умолчанию или уязвимостей обхода аутентификации (например, CVE-2020-14882)./bea_wls_internal/: Каталог внутреннего веб-приложения WebLogic Server по умолчанию. Этот компонент обеспечивает доступ к статическим системным файлам и взаимодействие с ними./wls-wsat/CoordinatorPortType: Это самое критическое обнаружение. Наличие этого пути с кодом состояния 200 OK подтверждает, что компонент Web Services Atomic Transactions (wls-wsat) включен и готов к приему данных./uddiexplorer и /uddi/uddilistener: Это компонент UDDI Explorer (Universal Description, Discovery, and Integration), интегрированный по умолчанию в WebLogic Server для управления и регистрации веб-сервисов. Этот компонент чрезвычайно известен уязвимостью SSRF (Server-Side Request Forgery) — CVE-2014-4210. Атакующий может использовать интерфейс поиска публичных реестров UDDI по адресу /uddiexplorer/SearchPublicRegistries.jsp, чтобы заставить сервер WebLogic отправлять произвольные HTTP-запросы во внутреннюю сеть бэкенда.⇒ Вывод: Сосуществование /wls-wsat (риск RCE через XMLDecoder) и /uddiexplorer (риск SSRF) указывает на то, что поверхность атаки этого сервера WebLogic чрезвычайно широка.
После выявления двух независимых поверхностей атаки, сосуществующих на сервере WebLogic 10.3.6.0, мы анализируем два направления:
/uddiexplorer:
/wls-wsat:
⇒ Решение: В модели кибератаки RCE всегда является конечной целью, поскольку обеспечивает прямой и полный контроль над системой (Full System Compromise). Как только достигнута возможность RCE, эксплуатация SSRF через приложение UDDI становится избыточной. Это связано с тем, что из оболочки RCE мы можем активно выполнять запросы к внутренней сети прямым, гибким и более мощным способом (используя системные команды, такие как curl, wget), не ограничиваясь параметрами интерфейса UDDI.
Поэтому с точки зрения логики приоритизации эксплойтов мы решаем исключить второстепенный путь (SSRF на /uddiexplorer) и полностью сосредоточиться на исследовании: удаленное выполнение кода (RCE) через уязвимость десериализации XMLDecoder на /wls-wsat/CoordinatorPortType.
Корневая уязвимость CVE-2017-10271 возникает из-за того, что класс WorkContextXmlInputAdapter в WebLogic использует объект java.beans.XMLDecoder для разбора данных в теге <work:WorkContext>. По умолчанию этот класс XMLDecoder автоматически создает экземпляр любого Java-класса, определенного в форме XML-тега. Отсюда мы выполняем верификацию на основе пошагового взаимодействия с поведением системы.
Чтобы быстро проверить фактическое активное состояние этого сервлета, отправляем обычный HTTP GET пробный запрос:
curl -i -s http://192.168.3.137:7001/wls-wsat/CoordinatorPortType
Ответ возвращает HTTP/1.1 200 OK вместе с классом реализации CoordinatorPortTypePortImpl, что подтверждает успешную загрузку сервлета в память JVM.
Поскольку сервлеты веб-сервисов предназначены для обработки данных SOAP XML методом POST, мы выполняем сравнительное тестирование с двумя POST-запросами, чтобы продемонстрировать конвейер обработки данных системы:
1. Стандартный SOAP POST-запрос
Мы отправляем стандартную SOAP XML-оболочку (с полными пространствами имен, но без содержимого для выполнения), чтобы протестировать нормальную способность парсера к разбору.
curl -i -s -X POST "http://192.168.3.137:7001/wls-wsat/CoordinatorPortType" \
-H "Content-Type: text/xml;charset=UTF-8" \
-d "<soapenv:Envelope xmlns:soapenv='http://schemas.xmlsoap.org/soap/envelope/'>soapenv:Header/soapenv:Body/</soapenv:Envelope>"
Cannot find dispatch method).Анализ:
Сервер имеет исправно работающий XML-читатель на POST-порту, готовый принимать и декодировать всю структуру XML-дерева, отправленную пользователем. Это подтверждает, что конвейер данных от клиента в память WebLogic работает в полном объеме.
2. Некорректный XML POST-запрос
Затем мы намеренно ломаем структуру XML (например, отсутствие пространств имен), чтобы наблюдать механизм обработки исключений парсера.
curl -i -s -X POST "http://192.168.3.137:7001/wls-wsat/CoordinatorPortType" \
-H "Content-Type: text/xml;charset=UTF-8" \
-d "soapenv:Envelopesoapenv:Headerwork:WorkContextinvalid_xml_structure</work:WorkContext></soapenv:Header></soapenv:Envelope>"
com.ctc.wstx.exc.WstxParsingException: Undeclared namespace prefix "soapenv".Анализ: