Security researchers at F5 Networks constantly monitor web traffic at various locations all over the world. This allows us to detect “in the wild” malware, and to get an insight into the current threat landscape.
In December 2019, security researchers detected a 100% increase in new threat campaigns as compared to November 2019. This was not surprising since attackers often increase their activity during the busy shopping and holiday season. Here’s an overview of the new threat activity.
- Three campaigns targeting Jenkins servers vulnerable to the Jenkins Script Security Plugin Remote Code Execution (RCE) vulnerability (CVE-2019-1003000).
- Two campaigns targeting ThinkPHP servers vulnerable to an RCE vulnerability (CVE-2019-11043).
- One campaign targeting Elasticsearch servers vulnerable to a Groovy scripting engine sandbox security bypass vulnerability (CVE-2015-1427).
- In addition, the following notable new campaigns were also detected:
- Atlassian Confluence Widget Connector RCE (CVE-2019-3396), web.xml. The campaign aims to identify Confluence servers vulnerable to an Atlassian Confluence Widget Connector RCE vulnerability. The threat actor instructs the server to disclose contents of the sensitive file, web.xml.
- Multiple exploits, Mirai ECHOBOT. The campaign uses ECHOBOT, a Mirai malware variant, to exploit known public vulnerabilities. The threat actor instructs the server to download and execute a malicious file from a domain controlled by the actor. If the exploit succeeds, the server joins a botnet for future use. Further analysis on this malware variant was published to F5 Labs in December 2019.
- Drupal 'Drupalgeddon2' RCE, pido (CVE-2018-7600). The campaign aims to identify Drupal web servers vulnerable to Drupalgeddon2 RCE vulnerability. The threat actor instructs the server to download and execute a malicious bash script.
- Apache Struts2 Jakarta Multipart Parser, YMUCWkU (CVE-2017-5638). The campaign aims to identify Apache Struts 2 based servers vulnerable to the Jakarta Multipart Parser vulnerability. The threat actor instructs the server to add a "YMUCWkU" header to the response with the string 'N9d1GLZpB' as its value.
- DedeCMS savetagfile RCE, shell.lib. The campaign aims to identify DedeCMS servers that are vulnerable to a Remote Code Execution vulnerability. The threat actor instructs the server to create a PHP backdoor.
Jenkins Script Security Plugin Remote Code Execution (CVE-2019-1003000)
Jenkins is a free and open source automation server. Jenkins helps to automate the non-human part of the software development process by providing continuous integration and facilitating technical aspects of continuous delivery. We've written about other threats to Jenkins automation servers, with multiple articles published on F5 Labs, the most recent in October 2019 regarding the installation of cryptominers.
On January 8, 2019, Jenkins released a security advisory1 discussing a vulnerability in Script Security. The sandbox protection could be circumvented during the script compilation phase by applying AST transforming annotations such as @Grab to source code elements. The vulnerability was reported by Orange Tsai from DEVCORE. A detailed analysis of the vulnerability2 was made available and multiple threat campaigns were detected shortly thereafter.
To resolve a URL, Jenkins uses Dynamic Routing. This routing uses a naming convention to resolve the URL and invoke a method dynamically. For example, a URL like http://jenkin.local/adjuncts/whatever/class/classLoader/resource/index.jsp/content gets resolved in the following sequence.
Jenkins also implements an ACL policy that limits the privilege level for a user. A user’s access privilege is checked through a call to function jenkins.model.Jenkins#getTarget(). This function checks against a list of allowlisted URLs. If a user does not have the right access privilege, some pages will not render. A few examples of pages that might be blocked for a user with no read/write privileges are /login, /logout, /signup, etc.
By combining this function with Jenkins dynamic routing, an attacker can bypass the ACL policy check. For example, a URL gadget like: /securityRealm/user/[username]/descriptorByName/[descriptor_name]/ will resolve sequentially like:
All configurable objects in Jenkins extend class hudson.model.Descriptor. Moreover, any class that extends Descriptor is accessible by method hudson.model.DescriptorByNameOwner#getDescriptorByName(String).
To achieve pre-authentication RCE, Orange uses Grape, a built-in JAR dependency management in Apache Groovy. By using processOtherServices() method within class the groovy.grape.GrapeIvy, a constructor call can be made to any class. By creating a malicious JAR file and putting the class name into the file META‑INF/services/org.codehaus.groovy.plugins.Runners, a threat actor can invoke a constructor and execute arbitrary code.
Since the release of the POC exploit, we've seen this vulnerability commonly exploited by threat actors.
The initial request instructs the server to connect to aliyun[.]one and download the webpage.
Aliyun[.]one webpage contains the payload to be executed on a vulnerable server. The downloaded payload is a BASH script that instructs the vulnerable server to create a cron job to ensure its persistence. It then downloads and executes an ELF file disguised as a PNG image file.
This ELF file has been identified by 10 out of 59 antivirus engines on VirusTotal as a cryptominer.
This is notable because it shows that automated analysis tools can only bring you part of the way there when it comes to identifying active threat campaigns and malicious activity generated toward an organization’s network.
ElasticSearch Search Groovy Sandbox Bypass (CVE-2015-1427)
Elasticsearch is a search engine based on the Lucene library. It provides a distributed, multitenant-capable full-text search engine with an HTTP web interface and schema-free JSON documents.1 We chose this attack campaign to highlight because this along with the Apache Groovy issue in Jenkins pair well together. The issue with ElasticSearch is also possible because of how a flaw in the Apache Groovy scripts are executed.
The Groovy scripting engine in Elasticsearch before 1.3.8 and 1.4.x before 1.4.3 allows remote attackers to bypass the sandbox protection mechanism and execute arbitrary shell commands via a crafted script. We've written about campaigns targeting Elasticsearch vulnerabilities before and since January 2019, we've seen Groovy sandbox vulnerabilities exploited by malicious actors.
Elasticsearch exposes REST APIs that are used by the UI components and can be called directly to configure and access Elasticsearch features. One of these exposed REST APIs is the Search API. Although the current version of Elasticsearch no longer allows the scripting module to use scripts in order to evaluate custom expressions, the vulnerable2 versions did. For example, scripts can be used to return "script fields" as part of a search request, or they can be used to evaluate a custom score for a query, and so on.
Starting with version 1.3, these Groovy scripts were executed in a sandbox to control what classes and functions could be executed. By analyzing the file, GroovySandboxExpressionChecker.java,3 one can figure out how the sandbox works. As we can see in the file, during compilation, every expression is passed to the isAuthorized method, which returns true to allow that method and false to block it. To bypass this sandbox, one needs the isAuthorized method to return true.
The isAuthorized method contains two if-else blocks. If an expression is able to bypass these two conditions, the method returns true which allows the expression to bypass the Groovy sandbox. These conditions are:
- The methods included in the "methodBlacklist"1 cannot be a part of the expression.
- The name of the method invoked in the expression is not null and it's an instance of a allowlisted package. One of the few allowlisted packages is Java.lang.Math.
An attacker can satisfy these conditions and execute the expression outside the Groovy sandbox by using Java's Reflection API. Reflection is commonly used by programs that require the ability to examine or modify the runtime behavior of applications running in the Java virtual machine. Since java.lang.Math is one of the allowlisted packages, an attacker can load java.lang.Runtime using Reflection.
A sample payload looks like this:
Since the vulnerability was published in 2015, security researchers have detected multiple campaigns exploiting this vulnerability.
The threat actor instructs the server to download and execute a PERL script.
The downloaded payload is the infamous Perlbot botnet, first detected in 2014. At the time, F5 Labs wrote about Perlbot’s use of UDP flood attacks.
Upon execution, the PERL script joins an IRC channel, which is used to receive commands from the Command & Control (C&C) server.
This IRC botnet is capable of launching different kinds of attacks. Here's a mapping of a few function names and their purpose:
|Send raw information through a socket
|Downloads a file using HTTP
|Connects to an IRC server
|Parses information received on an IRC channel and performs an action accordingly
|Prints helpful commands
|Floods a server with UDP packets
|Floods a server with TCP packets
A common thread among the two vulnerabilities discussed in this article is the use of an open-source programming language, Apache Groovy. A lot of commercial applications utilize third-party plugins/applications to provide compatibility with other applications. Although these third-party applications reduce the need to “reinvent the wheel,” they add another layer of complexity, which is said to be the enemy of security. These third-party applications should be carefully vetted and considered during threat-modeling discussions.
For most organizations, an application firewall serves as the first line of defense for their applications. A well-monitored, configured, and updated web application firewall (WAF) should also be able to stop these threat actors from exploiting vulnerable systems within a network.
F5 security researchers continuously monitor new web application exploits to deliver the latest threat intelligence to our customers, as well as the broader IT security community. Join us in continuing the conversation on social media.
Enterprises should consider implementing the following security controls based on their specific circumstances: