SSD Advisory – CloudBees Jenkins Unauthenticated Code Execution

Want to get paid for a vulnerability similar to this one?
Contact us at: sxsxdx@xbxexyxoxnxdxsxexcxuxrxixtxy.xcom

Vulnerability Summary
The following advisory describes Java deserialization vulnerability found in CloudBees Jenkins version 2.32.1 that leads to a Remote Code Execution.

Jenkins helps to automate the non-human part of the whole software development process with now common things like continuous integration and by empowering teams to implement the technical aspects of continuous delivery. It is a server-based system running in a servlet container such as Apache Tomcat. It supports version control tools, including AccuRev, CVS, Subversion, Git, Mercurial, Perforce, Clearcase and RTC, and can execute Apache Ant, Apache Maven and sbt based projects as well as arbitrary shell scripts and Windows batch commands.

Credit
An independent security researcher has reported this vulnerability to Beyond Security’s SecuriTeam Secure Disclosure program.

Vendor Response
CloudBees Jenkins has released patches to address this vulnerability and issued CVE-2017-1000353 for the vulnerability. For more details: https://jenkins.io/security/advisory/2017-04-26/

Vulnerability Details

Jenkins is vulnerable to a Java deserialization vulnerability. In order to trigger the vulnerability two requests need to be sent.

The vulnerability can be found in the implementation of a bidirectional communication channel (over HTTP) which accepts commands.

The first request starts a session for the bi-directional channel and is used for “downloading” data from the server. The HTTP header “Session” is the identifier for the channel. The HTTP header “Side” specifies the “downloading/uploading” direction.

The second request is the sending component of the bidirectional channel. The first requests is blocked until the second request is sent. The request for a bidirectional channel is matched by the “Session” HTTP header which is just a UUID.

All commands sent to the CLI start with a preamble which is often:

The preamble contains a base64 encoded serialized object. The serialized object of type “Capability” just tells the server which capabilities (e.g. HTTP
chunked encoding) the client has.

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.

The deserialization is code is in the method “readFrom” of class “Command”:

The command is called by the “read()” of class “ClassicCommandTransport”.

The data coming “from” the “upload”-side of the channel is read in a thread of type ReaderThread.

The thread is triggered by the “upload”-method which is called in class “CliEndpointResponse”.

In that method the HTTP body data is read and the “notify” method is called to notify the thread.

Proof of Concept

In order to exploit the vulnerability, an attacker needs to create a serialized payload with the command to execute by running the payload.jar script.

The second step is to change python script jenkins_poc1.py:

• Adjust target url in URL variable
• Change file to open in line “FILE_SER = open(“jenkins_poc1.ser”, “rb”).read()” to your payload file.

By doing the previous steps, you should see the following massage in the log/stdout of jenkins:

jenkins_poc1.py

payload.jar