Jenkins Unsafe Deserialization Vulnerability (CVE-2017-1000353)
Jenkins is an open source automation server which can be used to automate all sorts of tasks related to building, testing, and delivering or deploying software.
In April 2017 Jenkins have published a security advisory that revealed an unsafe deserialization vulnerability in Jenkins. Following recent increasing number of attacks on Jenkins servers we decided to publish this blog describing the vulnerability and demonstrating how ASM can help mitigating it.
Figure 1: Part of a request attempting to exploit CVE-2017-1000353 as it was caught in F5’s honeypot.
Vulnerability Analysis
As we saw in other unsafe Java deserialization vulnerabilities, attempting to deserialize untrusted data controlled by the user may lead to harmful consequences like malicious code being executed on the vulnerable server, and this case is no different.
The vulnerable code can be found in the Command.java file in the readFrom function, where Jenkins attempts to read a Command object from an ObjectInputStream instance controlled by the user that may contain a malicious Object that will execute arbitrary code once deserialized.
Figure 2: readFrom function attempts to deserialize a Command object from an ObjectInputStream instance controlled by the user.
To exploit this vulnerability attacker will need to send two HTTP requests. The first request is used for creating a valid Jenkins CLI session which is bi-directional and comprised of two channels, one for receiving data from the Jenkins server and one for sending data to the Jenkins server. The channel is determined by the Side header which is included in the HTTP request and can be set to either upload or download according to the channel that is being used. The Jenkins session is identified by the Session header value which is a randomly generated UUID. The second request will be used to deliver the malicious serialized object and therefor the value of it’s side header will be set to upload.
Figure 3: First HTTP request sent to the vulnerable Jenkins server to create the bi-directional session.
Figure 4: Part of the second HTTP request sent to the vulnerable Jenkins server which contains the malicious serialized Java object.
Mitigating the vulnerability with BIG-IP ASM
BIG-IP ASM customers under any supported BIG-IP version are already protected against this vulnerability. The exploitation attempt will be detected by existing Java code injection attack signatures which can be found in signature sets that include the “Server Side Code Injection” attack type or “Java Servlets/JSP” System.
Figure 5: Exploit blocked with attack signature 200004285.
Figure 6: Exploit blocked with attack signature 200004379.
Figure 7: Exploit blocked with attack signature 200004298.
Figure 8: Exploit blocked with attack signature 200003437.
Figure 9: Exploit blocked with attack signature 200004299.