WP Zero-Day Attack Strikes Again - Java Zero Day Vulnerability CVE-2015-4852 Tracked by Imperva | Imperva

Archive

Zero-Day Attack Strikes Again – Java Zero Day Vulnerability CVE-2015-4852 Tracked by Imperva

On November 6th, 2015 security researchers of FoxGlove Security released zero-day exploits for WebSphere, WebLogic, JBoss, Jenkins, and OpenNMS, facilitating in some cases Remote Code Execution attacks on application servers using these technologies. The popularity of these software products, which are used by many organizations, combined with the severity of the attack, allowing attackers to obtain control over the server, earns this vulnerability a slot right next to the likes of Shellshock.
The vulnerability used for the exploit has been around for two years and resides in code that processes serialized objects coming to the server, deserializes them for application logic.The vulnerability exists because the Apache Commons Collections library fails to sanitize user-provided input thoroughly, opening a window for an attacker to append malicious code to the input and perform remote code execution. Breen and Kennedy have documented the complete details of the vulnerability and how the exploit works in their blog post.
Analyzing  CVE-2015-4852 revealed a surprising and disturbing fact that in the years since the publication of the vulnerability, the attack surface has not reduced, but, in fact, has become larger given the increasing number of the vulnerable web applications.
java-vulnerability-figure-1-jenkins-growth
Figure 1- Jenkins growth publication (https://www.cloudbees.com/press/jenkins-community-reaches-milestone-more-100000-active-installations-worldwide )

Zero Day Mitigation by Imperva WAF

Soon after the zero-day exploit  CVE-2015-4852 was published, Imperva sensors detected 645 web servers being attacked from 503 different IPs.
java-vulnerability-figure-2-attackers-ips-geolocation
Figure 2- Attackers IPs Geolocation
java-vulnerability-figure-3-attack-volume
Figure 3- Attacks volume per country
 
SecureSphere’s built-in security mechanisms were designed to distinguish between legitimate to abnormal traffic patterns, had detected these attacks on the protected applications. We tracked these attacks in the days since the public exposure of the vulnerability and recorded several attack campaigns using these zero-day exploits. While in the days following the publication we noticed only hundreds of attacks per day, a week later we witnessed massive attack campaigns, reaching 4,000 attacks per day, hinting on the exploit being amplified by several by web scanners. Since this is highly unusual/suspect behavior, we decided to analyze and dig deeper into the attacks.
java-vulnerability-figure-4-zero-day-attacks-since-nov-2015
Figure 4– Amount of Zero Day Attacks since the beginning of November 2015
 

Real life attacks analysis

96% of the attacked URLs contained the “invoker” word (for example: “/invoker/JMXInvokerServlet”, “/invoker/EJBInvokerServlet”)
java-vulnerability-figure-5-attack-urls
Figure 5 – Attacked URLs
Also, we were able to monitor malicious payloads used to download a WAR file that contained a backdoor client code. The downloaded file was used to infect the web server and gain persistent access and remote command execution capability.
Payload analysis
The following shows an example of a payload we encountered during our research:
java-vulnerability-figure-6-attack-url-request
The above example shows a request that was seen few days after the vulnerability was published. The source IP has been scanning for the Java serialization vulnerabilities. The marked URL contains a malicious WAR file that includes a backdoor code. The backdoor implementation uses the common code found in many hosts acting as download servers.
Browsing this server, which has bad IP reputation and is blacklisted by several security vendors, we saw additional suspicious files in the UI.
java-vulnerability-figure-7-attack-ip-reputation
Recommendations and Mitigation

  • Java Common-Collections Frameworks users should manually fix the library by hand, by removing class files leveraged by the exploit from the Jar file. See “The Fix” section of thispost for more details.
  • Finding the parts of the applications that take a serialized object as input (if any), and verify whether they are properly sanitizing it.
  • Applications using Imperva SecureSphere WAF enjoys out-of-the-box mitigation to this vulnerability as part of WAF generic mechanisms for mitigation of zero-day attacks. In addition, Imperva ADC published specific mitigation guidelines to prevent unwanted access to the vulnerable Java applications.