Imperva’s research group is constantly monitoring new web application vulnerabilities. In doing so, we’ve noticed at least four major insecure deserialization vulnerabilities that were published in the past year.
Our analysis shows that, in the past three months, the number of deserialization attacks has grown by 300 percent on average, turning them into a serious security risk to web applications.
To make things worse, many of these attacks are now launched with the intent of installing crypto-mining malware on vulnerable web servers, which gridlocks their CPU usage.
In this blog post we will explain what insecure deserialization vulnerabilities are, show the growing trend of attacks exploiting these vulnerabilities and explain what attackers do to exploit them (including real-life attack examples).
The process of serialization converts a “live” object (structure and/or state), like a Java object, into a format that can be sent over the network, or stored in memory or on disk. Deserialization converts the format back into a “live” object.
The purpose of serialization is to preserve an object, meaning that the object will exist outside the lifetime of the local machine on which it is created.
For example, when withdrawing money from an ATM, the information of the account holder and the required operation is stored in a local object. Before this object is sent to the main server, it is serialized in order to perform and approve the needed operations. The server then deserializes the object to complete the operation.
There are many types of serialization available, depending on the object which is being serialized and on the purpose. Almost all modern programming languages support serialization. In Java for example an object is converted into a compact representation using byte stream, and the byte stream can then be reverted back into a copy of that object.
Other types of serialization include converting an object into a hierarchical format like JSON or XML. The advantage of this serialization is that the serialized objects can be read as plain text, instead of a byte stream.
In the OWASP top 10 security risks of 2017 insecure deserialization came in at eighth place and rightfully so as we argued in our previous blog about the state of web application vulnerabilities in 2017.
In 2017, major new vulnerabilities related to insecure serialization, mostly in Java, were published (see Figure 1).
Name | Release Date (Day/Month/Year) | Vulnerability details
CVE-2017-12149 | 01/08/2017 | Vulnerability in the JBoss Application Server allows execution of arbitrary code via crafted serialized data because the HTTP Invoker does not restrict classes for which it performs deserialization
CVE-2017-10271 | 21/06/2017 | Vulnerability in the Oracle WebLogic Server allows execution of arbitrary code due to insufficient sanitizing of user supplied inputs in the wls-wsat component
| 21/06/2017 | The REST Plugin in Apache Struts uses an XStreamHandler with an instance of XStream for deserialization without any type filtering, which can lead to remote code execution when deserializing XML payloads.
CVE-2017-7504 | 05/04/2017 | The HTTPServerILServlet.java in JMS allows remote attackers to execute arbitrary code via crafted serialized data because it does not restrict the classes for which it performs deserialization
Figure 1: CVEs related to insecure deserialization
In order to understand the magnitude of these vulnerabilities, we analyzed attacks from the past three months (October to December of 2017) that try to exploit insecure deserialization. A key observation is the steep increase of deserialization attacks in the past few months, as can be seen in the Figure 2.
Figure 2: Insecure deserialization attacks over the course of three months
Most of the attackers used no attack vectors other than insecure deserialization. We noticed that each attacker was trying to exploit different vulnerabilities, with the above-mentioned CVEs being the most prevalent.
For a full list of CVEs related to insecure deserialization from the past few years see Figure 3.
Name | Relevant System | Public Exploit | Name | Relevant System | Public Exploit
CVE-2017-9844 | SAP NetWeaver | Yes | CVE-2016-2170 | Apache OFBiz | No
CVE-2017-9830 | Code42 CrashPlan | No | CVE-2016-2003 | HP P9000, XP7 Command View Advanced Edition (CVAE) Suite | No
CVE-2017-9805 | Apache Struts | Yes | CVE-2016-2000 | HP Asset Manager | No
CVE-2017-7504 | Red Hat JBoss | Yes | CVE-2016-1999 | HP Release Control | No
CVE-2017-5878 | Apache OpenMeetings | Yes | CVE-2016-1998 | HP Service Manager | No
CVE-2017-5645 | Apache Log4j | No | CVE-2016-1997 | HP Operations Orchestration | No
CVE-2017-5641 | Apache BlazeDS | Yes | CVE-2016-1986 | HP Continuous Delivery Automation | No
CVE-2017-5586 | OpenText Documentum D2 | Yes | CVE-2016-1985 | HP Operations Manager | No
CVE-2017-3159 | Apache Camel | Yes | CVE-2016-1487 | Lexmark Markvision Enterprise | No
CVE-2017-3066 | Adobe ColdFusion | Yes | CVE-2016-1291 | Cisco Prime Infrastructure | Yes
CVE-2017-2608 | Jenkins | Yes | CVE-2016-0958 | Adobe Experience Manager | No
CVE-2017-12149 | Red Hat JBoss | Yes | CVE-2016-0788 | Jenkins | Yes
CVE-2017-11284 | Adobe ColdFusion | No | CVE-2016-0779 | Apache TomEE | No
CVE-2017-11283 | Adobe ColdFusion | No | CVE-2016-0714 | Apache Tomcat | No
CVE-2017-1000353 | CloudBees Jenkins | Yes | CVE-2015-8765 | McAfee ePolicy Orchestrator | No
CVE-2016-9606 | Resteasy | Yes | CVE-2015-8581 | Apache TomEE | No
CVE-2016-9299 | Jenkins | Yes | CVE-2015-8545 | NetApp | No
CVE-2016-8749 | Jackson (JSON) | Yes | CVE-2015-8360 | Atlassian Bamboo | No
CVE-2016-8744 | Apache Brooklyn | Yes | CVE-2015-8238 | Unify OpenScape | No
CVE-2016-8735 | Apache Tomcat JMX | Yes | CVE-2015-8237 | Unify OpenScape | No
CVE-2016-7462 | VMWare vRealize Operations | No | CVE-2015-8103 | Jenkins | Yes
CVE-2016-6809 | Apache Tika | No | CVE-2015-7501 | Red Hat JBoss | Yes
CVE-2016-5229 | Atlassian Bamboo | Yes | CVE-2015-7501 | Oracle Application Testing Suite | No
CVE-2016-5004 | Apache Archiva | Yes | CVE-2015-7450 | IBM Websphere | Yes
CVE-2016-4385 | HP Network Automation | No | CVE-2015-7253 | Commvault Edge Server | Yes
CVE-2016-4372 | HP iMC | No | CVE-2015-6934 | VMWare vCenter/vRealize | No
CVE-2016-3642 | Solarwinds Virtualization Manager | Yes | CVE-2015-6576 | Atlassian Bamboo | No
CVE-2016-3461 | Oracle MySQL Enterprise Monitor | Yes | CVE-2015-6555 | Symantec Endpoint Protection Manager | Yes
CVE-2016-3427 | JMX | Yes | CVE-2015-6420 | Cisco (various frameworks) | No
CVE-2016-3415 | Zimbra Collaboration | No | CVE-2015-5348 | Apache Camel | No
CVE-2016-2510 | Red Hat JBoss BPM Suite | No | CVE-2015-5254 | Apache ActiveMQ | No
CVE-2016-2173 | Spring AMPQ | No | CVE-2015-4852 | Oracle WebLogic | Yes
CVE-2016-2170 | Apache OFBiz | No | CVE-2015-3253 | Jenkins | Yes
CVE-2016-2003 | HP P9000, XP7 Command View Advanced Edition (CVAE) Suite | No | CVE-2012-4858 | IBM Congnos BI | No
Figure 3: CVEs related to insecure deserialization
Most of the attacks that we saw are related to byte-stream serialization of Java objects. Also, we saw some attacks related to serialization to XML and other formats, see Figure 4.
Figure 4: Distribution of vulnerabilities over different serialization formats
In the following attack (see Figure 5) the attacker is trying to exploit CVE-2017-10271. The payload is sent in the HTTP request’s body using a serialized Java object through XML representation.
Figure 5: Attack vector containing a serialized java array into an XML
The fact that this is a Java array can be seen by the hierarchical structure of the parameters, with the suffix of “java/void/array/void/string”. The attacker is trying to run a bash script on the attacked server.
This bash script tries to send an HTTP request using “wget” OS command, download a shell script disguised as a picture file (note the jpg file extension) and run it. Few interesting notes can be made examining this command:
The next script (see Figure 6) tries to exploit the same vulnerability, but this time the payload is targeting Windows servers using cmd.exe and Powershell commands to download the malware and run it.
Figure 6: Attack vector trying to infect Windows server with crypto mining malware
This indicates that there are two different infection methods for Windows and Linux server, each system with its designated script.
Another example is the following payload (Figure 7) that we pulled from an attack trying to exploit a deserialization vulnerability with a Java serialized object.
Figure 7: Attack vector containing a Java serialized object trying to download a crypto miner
The “bad” encoding is an artifact of Java serialization, where the object is represented in the byte stream.
Still, we can see a script in plain text marked in yellow. Shown as an image below is a variable that defines an internal field separator, where in this case it is just a variable for space. The variable is probably used instead of a space to try to make the payload harder to detect.
Just as in the previous examples, this Bash script targets Linux servers that send an HTTP request using “wget” to download a crypto miner.
The common denominator of the attacks above is that attackers are trying to infect the server with a crypto mining malware by using an insecure deserialization vulnerability. However insecure deserialization is not the only method to achieve this goal.
Below (Figure 8) we see an example of another attack payload, this time at the “Content-Type” header.
Figure 8: Attack vector using an RCE vulnerability of Apache Struts
This attack tries to exploit CVE-2017-5638, a well-known RCE vulnerability related to Apache Struts which was published in March 2017 and was covered in a previous blog post.
When it was originally published we saw no indications of crypto miners in the attacks’ payloads related to this CVE, and most of the payloads were reconnaissance attacks.
However, in this attack the payload (marked in yellow above) is very similar to the payload from the previous example. Using the same remote server and the exact same script, it infected the server with crypto mining malware.
This old attack method with a new payload suggests a new trend in the cyber arena – attackers try to exploit RCE vulnerabilities, new and old, to turn vulnerable servers into crypto miners and get a faster ROI for their “effort”.
Given the many new vulnerabilities related to insecure deserialization that were discovered this year, and its appearance in the OWASP top 10 security risks, we expect to see newer related vulnerabilities released in 2018. In the meantime, organizations using affected servers are advised to use the latest patch to mitigate these vulnerabilities.
An alternative to manual patching is virtual patching. Virtual patching actively protects web applications from attacks, reducing the window of exposure and decreasing the cost of emergency patches and fix cycles.
A WAF that provides virtual patching doesn’t interfere with the normal application workflow, and keeps the site protected while allowing the site owners to control the patching process timeline.
Learn more about how to protect your web applications from vulnerabilities with Imperva WAF solutions.