Quick Take: Jenkins Java Deserialization Unauthenticated Remote Code Execution
- Security Risk: Severe
- Exploitation Level: Easy/Remote
- Affected Versions: Jenkins 2.56, Jenkins LTS 2.46.1 and prior versions
- Vulnerability: Remote Code Execution
- CVE: CVE-2017-1000353
Today I’ll dig into Jenkins Java Deserialization vulnerability that was disclosed roughly 2 months ago, and currently even after the patch was released, the vulnerability is still exploitable in the wild and there are over 3000 vulnerable servers out there that have not updated their systems yet, which can be found with the help of Shodan.
Jenkins is the most popular open source automation server, it is maintained by CloudBees and the Jenkins community.
The automation server supports developers build, test and deploy their applications, it has more than 133,000 active installations worldwide with more than 1 million users.
Jenkins can be installed through native system packages, Docker, or even run standalone by any machine with the Java Runtime Environment installed.
About the Vulnerability: Jenkins Java Deserialization Unauthenticated Remote Code Execution
Jenkins 2.56 & Jenkins LTS 2.46.1 and all prior versions are vulnerable to a Java deserialization attack.
This vulnerability resides inside the implementation of the bi-directional communication channel over HTTP and in order to trigger the vulnerability the attack need to send only 2 http “POST” requests to the CLI.
The HTTP “Side” header specifies the direction of the communication, in our case it will be either “download” or “upload”.
The HTTP “Session” header is used as the identifier for the communications channel.
The first request will start a session of the bi-directional communication and is used for downloading data from the server.
The second request is the message sending component of the bi-directional channel. The first request is blocked until the second request is sent. The request for the bi-directional channel is matched by the “Session” HTTP header which is just a UUID.
The second request includes a command that is sent to the CLI, which is often starts with
<===[JENKINS REMOTING CAPACITY]===>rO0ABXNyABpodWRzb24ucmVtb3RpbmcuQ2FwYWJpbGl0eQAAAAAAAAABAgABSgAEbWFza3hwAAAAAAAAAH4=
This preamble contains a base64 encoded java serialized object of type “Capability” and it just tells the server which capabilities the client has (e.g. HTTP chunked encoding).
After the preamble and some additional bytes, a serialized object of type “Command” is expected by the Jenkins server. Since Jenkins does not validate the serialized object, any serialize object can be sent thus exploiting a java deserialization vulnerability.
This java code can be used in order to create a java serialized malicious payload for the exploit,
You can compile the java code and execute it in the following manner:
java -jar payload.jar BadObject.ser “$”
Just substitute the $ sign with your desired CMD that you would like to execute on the exploited server.
For this PoC i will simply remove a folder from /tmp e.g: “rmdir /tmp/test”
After generating a payload our final exploit will be:
Exploitation & Twistlock’s Mitigation
Before executing the exploit lets make sure that our target directory is present on the test system:
Once we fire up our exploit, Jenkins will execute our malicious payload with the supplied command that we choose when we generated the payload, in our example we can witness the removal of the test folder in /tmp:
One of the latest Twistlock features allows us to stop any Java deserialization exploits by extracting system calls from java executable files and creating an intelligent white-list for the actions that the executable is allowed to perform.
This is performed by our state on the art AI algorithms, below you can see the system calls model that our AI built for the Jenkins executable:
You can see in the audits tab that Twistlock Runtime Radar detected the anomalous “rmdir” system call that was executed by our exploit:
Notice that it was not blocked as my policy was set on “alert” only, in the example below i have modified the policy to block such events, let’s try to execute the exploit one more time:
We now can see that our exploit failed to execute and we can confirm it on our dashboard:
Jenkins Java Deserialization vulnerabilities are extremely dangerous and are not about to go away anytime soon, take for example the Mad Gadget bug that lurks the internet since 2015 and was used in a number of high profile breaches.
Although this specific Jenkins vulnerability was disclosed roughly 2 months ago, and a patch was released fixing it and 20 other security vulnerabilities – it seems that there are a lot of folks that do not rush to update their systems and by this they open up a big hole on their servers.
Stay tuned to our blog and Twitter account to get the latest container security and cloud native news.
Breaking out of Docker via runC – Explaining CVE-2019-5736Read the Blog
T19 Challenge – Twistlock Lab’s first security challenge summary and solutionsRead the Blog
Kubernetes emergency survival: Hotfix patching running podsRead the Blog
Demystifying Kubernetes CVE-2018-1002105 (and a dead simple exploit)Read the Blog