Vulnerabilities, Exploits, and Malware Driving Attack Campaigns in April 2019

Security researchers at F5 Networks constantly monitor web traffic at various locations throughout the world. This allows us to detect current “in the wild” malware, and to get an insight into a threat actor’s attack pattern. Here’s a recap of what we saw April 2019.

Over the course of the month, we detected 12 new attack campaigns:

• Six campaigns targeted two separate Oracle WebLogic server vulnerabilities. Both CVEs (CVE-2017-10271 and CVE-2019-2725) make WebLogic servers vulnerable to unsafe deserialization, leading to remote code execution (RCE).
• Two campaigns targeting Apache Struts servers, vulnerable to an RCE in the Jakarta Multipart Parser (CVE-2017-5638). Published in 2017, this vulnerability (which resulted in the massive Equifax data breach¹) is still a very common threat vector, even though a patch has been available since March 2017.
• One campaign targeting Drupal RESTful Web Services unserialize RCE (CVE-2019-6340).
• Other notable campaigns included:
  • Joomla Component JBcatalog—Arbitrary File Upload: The threat actor tried to create a back door by piecing together a PHP shellcode on the vulnerable server.
  • ThinkPHP Remote Code Execution (CVE-2018-20062): The threat actor instructed the server to create a PHP back door.

Oracle WebLogic Server WLS Security Component RCE (CVE-2017-10271)

Oracle WebLogic Server is a Java EE application server currently developed by Oracle Corporation. According to ZoomEye, WebLogic is deployed on over 100,000 servers all over the world. As Figure 1 shows, most are located in the United States and China.

In October 2017, Oracle published a patch¹ for a vulnerability in Oracle WebLogic Server and assigned CVE-2017-10271² to it. As expected, within a few days of the patch being available, Proof-of-Concept (PoC) exploits were published online. We don’t know how many of these servers are still vulnerable (unpatched), but our guess is that many are since threat actors are still targeting them and the impact of an RCE vulnerability can be very high.

The vulnerability exists in the XMLDecoder class within the WLS Security subcomponent. Before the patch for this CVE was released, weblogic/wsee/workarea/WorkContextXmlInputAdapter.java file contained a method ‘validate’. This function threw an exception when an element with Object as its type was present while parsing XML. However, this function did not contain checks for element types: new, void, array, and method. This allowed threat actors to inject serialized XML with these four element types that were not caught by exceptions in the Java file.

As we can see in Figure 2, which illustrates a new campaign we detected in April, the threat actor uses the ProcessBuilder class to download and execute a malicious file. This threat actor was previously detected exploiting Jenkins CLI SignedObject Deserialization (CVE-2017-1000353) with the same payload—a cryptominer, in this case. To read more about the payload, please refer to our February attack campaigns article.

Oracle WebLogic WLS Security Component RCE (CVE-2019-2725)

On April 21, 2019, information regarding a deserialization vulnerability in Oracle WebLogic Server was published by KnownSec 404 Team. According to the CVE, the vulnerability exists in the Web Services subcomponent of Oracle WebLogic. Similar to the previous Oracle WebLogic vulnerability discussed above, this new vulnerability also stems from unsafe deserialization that leads to RCE. Threat actors wasted no time in adding this zero-day threat vector in their arsenals, and we started detecting campaigns with the payload for CVE-2017-10271 but the endpoint for CVE-2019-2725.

Various PoC exploits were posted online, but initially none of them targeted the newly found vulnerability. Instead, they used an older Java code injection gadget. Oracle had released a patch for this vulnerability in October 2017. Therefore, if the correct patches had been applied to an installation of Oracle WebLogic servers, the initial few threat campaigns would not have been fruitful for the threat actors.

On April 26, Oracle released an out-of-band security alert for CVE-2019-2725 clarifying that this is a different vulnerability from CVE-2017-10271 and recommending that affected systems be patch as soon as possible. The vulnerability exists in the wls9_async_response.war package. This package is included by default in some versions of Oracle WebLogic Server and provides asynchronous communication for the WebLogic Server service. The unsafe deserialization vulnerability exists within weblogic.wsee.async.AsyncResponseBean class.

To exploit this vulnerability, a threat actor needs to construct a normal SOAP message. Within the message, the threat actor then needs to assign values to weblogic.wsee.addressing.RelatesTo to reach the unsafe deserialization point. The most commonly detected classes to exploit this vulnerability are:

• oracle.toplink.internal.sessions.UnitOfWorkChangeSet
• com.sun.rowset.JdbcRowSetImpl
• org.slf4j.ext.EventData
• java.lang.ProcessBuilder
• com.bea.core.repackaged.springframework.context.support.FileSystemXmlApplicationContext

As shown in Figure 3, the threat actor sends this request to a WebLogic server. If the server is vulnerable, it will send an HTTP 202 response back indicating that it’s vulnerable.

Drupal RESTful Web Services Deserialize RCE (CVE-2019-6340)

On February 20, 2019, Drupal released a security advisory for Drupal core. According to the advisory, a site is vulnerable if one of the following conditions is met:

• The site has the Drupal 8 core RESTful Web Services (rest) module enabled and allows PATCH or POST requests, or
• The site has another web services module enabled, like JSON:API in Drupal 8, or Services or RESTful Web Services in Drupal 7.

Drupal’s recommendation to mitigate against this vulnerability was to not allow PUT/PATCH/POST requests to web services resources. However, a couple of days after Drupal released its advisory, various researchers confirmed that the RCE can also be triggered by a GET request.

According to Standard REST behavior, to edit a node in Drupal, an authorized user would send a request like the one shown in Figure 4.

Content-Type: application/json+hal is an Internet standard convention for defining hypermedia such as links to external resources within JSON. In the case of the request shown in Figure 4, Drupal will JSON deserialize the request and create properties title, type, body for the node mentioned in the request.

The vulnerability lies in the processing part of this request. An unauthorized user should not be able to modify or create new pages/articles in a Drupal website. However, when an unauthorized user sends a request like the one above to a nonexistent href value, the response received is : HTTP/1.1 422 Unprocessable Entity {"message":"Type http:\/\/127.0.01\/drupal-8.6.9\/rest\/type\/node\/INVALID_VALUE does not correspond to an entity on this site."}.

Let’s analyze the patch¹ to understand what Drupal changed.

As we can see in Figure 5, a new trait, SerializedColumnNormalizerTrait was added. This indicates that the vulnerability is a serialization vulnerability as the module now checks for serialization within a string. To further investigate and find out which particular property can be used to send a serialiazed string, let’s look at another modified file.

As shown in Figure 6, the LinkItem.php file has been modified to not allow any deserialization within the ‘link options’ property. Therefore, to exploit this vulnerability, a threat actor needs to send serialized content in the link options property. Drupal will unsafely deserialize the serialized string, which leads to RCE.

One of the detected threat campaigns instructs a vulnerable website to download and execute a malicious DDoS malware. The malware file has been detected as AESDDoS malware by various antivirus companies.

Conclusion

Deserialization vulnerabilities are not a new kind of vulnerability and have existed since the inception of serialization. The core issue behind unsafe deserialization stems from improper input validation. Therefore, as a developer it is important to consider the different channels through which an input to a deserialization function can be received. It is also equally important to have a well informed vulnerability and patch management team. All of the vulnerabilities mentioned in this article were promptly patched by the vendors, and it’s important to ensure that the patches are applied on the vulnerable systems.

For most organizations, a firewall is the first line of defense. A well-monitored and updated web application firewall (WAF) should also be able to stop these threat actors from exploiting vulnerable systems within your network.

F5 security researchers will continue monitoring new web application exploits to deliver the latest threat intelligence to its customers, and to share it with the broader IT security community.