Jackson-Databind - A Story of Blacklisting Java Deserialization Gadgets
Jackson is a popular library for parsing JSON documents in Java. Jackson-Databind is a module of the Jackson library that allows automatic transformation from JSON to Java objects and vice versa. In June 2017, an unsafe deserialization vulnerability was discovered in the Jackson-Databind module (CVE-2017-7525) and was patched by creating a blacklist that doesn’t accept certein dangerous Java classes. The Jackson-Databind module developers created a function named checkIllegalTypes and the only class that was blacklisted was TemplatesImpl which is part of the com.sun.org.apache.xalan package. Figure 1: The checkIllegalTypes function as it was first written in the BeanDeserializerFactory.java file An hour passed, and the blacklist was updated to contain more dangerous classes. Figure 2: More dangerous classes were added to the blacklist. In December 2017 CVE-2017-17485 was allocated for this exact same vulnerability because it was found that the blacklist didn’t contain dangerous classes from the Spring framework. After a while another bypass on the blacklist is discovered, now being tracked as CVE-2017-15095. This is probably not the last change being made on this blacklist because new dangerous classes and gadget chains (Several classes that when combined may lead to Remote Code Execution) are discovered from time to time by security researchers. Mitigation with ASM The Jackson-Databind developers are in a rush after new dangerous Java classes that may lead to remote code execution once deserialized and we keep on updating ASM with those Java deserialization gadgets. As opposed to the Jackson-Databind developers we have additional mitigation layers to rely on, such as Java Server Side Code Injection signatures that detects operating system command execution attempts, for examplebyusing Java's Runtime and ProcessBuilder classes (Signature ids 200003437,200003438,200003439, 200004174) and specific operating system command execution signatures. Today, a new ASM security update was released to cover additional Java deserialization gadgets discovered recently: org.apache.tomcat.dbcp.dbcp2.BasicDataSource com.sun.org.apache.bcel.internal.util.ClassLoader org.hibernate.jmx.StatisticsService org.apache.ibatis.datasource.jndi.JndiDataSourceFactory org.springframework.context.support.FileSystemXmlApplicationContextJenkins 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 sessionis 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.
