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 get insights into the current threat landscape.
In November 2019, new malicious campaign activity was down 40 percent compared to October 2019. While this seems like a large decline, there was a spike in new campaign activity in October 2019, and the new malicious activity is in line with what we detected in September 2019. Here’s an overview of the new threat activity we saw in November 2019:
- Two campaigns targeting Atlassian Confluence servers vulnerable to Widget Connector RCE vulnerability (CVE-2019-3396)
- One campaign targeting Nginx servers vulnerable to PHP-FPM RCE vulnerability (CVE-2019-11043)
- In addition, the following notable campaigns were also detected:
- MACCMS vod-search RCE (CVE-2017-17733): This campaign aims to exploit servers running MACCMS that are vulnerable to an RCE vulnerability. The threat actor tries to upload a web shell on a vulnerable server.
- Rejetto HTTP File Server RCE (CVE-2014-6287): This campaign aims to identify Rejetto HTTP File Servers vulnerable to Rejetto HTTP File Server RCE vulnerability. The threat actor instructs the server to download and execute a DDoS malware.
- rConfig ajaxServerSettingsChk unauthenticated RCE (CVE-2019-16662): This campaign aims to identify rConfig servers that are vulnerable to rConfig ajaxServerSettingsChk RCE vulnerability. The threat actor instructs the server to calculate the MD5 checksum of the string 'HelloConfig' and send it back to the threat actor.
Nginx PHP-FPM Remote Code Execution (CVE-2019-11043)
Following the trend of malicious activity seen in November 2019, threat actors are exploiting new vulnerabilities. On October 22, a security researcher tweeted1 about a vulnerability found during a Capture the Flag (CTF) competition. The vulnerability affects servers running Nginx with PHP-FPM under certain conditions. The researcher posted a working POC exploit showing how the vulnerability leads to remote code execution (RCE).2
There are multiple ways to configure Nginx. The FastCGI Process Manager (FPM) is an alternative PHP FastCGI implementation with some additional features mostly useful for heavy-loaded sites. Although PHP-FPM is not a core component of Nginx, several web hosting providers, such as Nextcloud, provide it for use. The vulnerability arises due to an improper configuration of PHP-FPM.
Vulnerability Analysis
As mentioned, the vulnerability arises due to misconfiguration when certain preconditions are met:
- The Nginx location directive must forward requests to PHP-FPM.
- The assignment of variable PATH_INFO and SCRIPT_FILENAME must be done using a fastcgi_param directive.
- A fastcgi_split_path_info directive exists and contains a RegExp starting with ^ and ending with $.
- Nginx does not drop requests to non-existing scripts before forwarding to FPM.
Various installations of Nginx contain the following RegEx lines in the configuration file. This is not a problem within Nginx, but a problem with the PHP-FPM configuration, one that developers often copy and paste from other resources and the internet. While it is not in the standard configuration, it is a common configuration for developers to use.
location ~ [^/]\.php(/|$)
{
fastcgi_split_path_info ^(.+?\.php)(/.*)$;
fastcgi_param PATH_INFO $fastcgi_path_info;
fastcgi_pass php:9000;
...
}
The RegExp in the fastcgi_split_path_info directive splits the URI into two groups: the first contains the PHP script name, and the second contains the path within the PHP script. For example, a string like "F5Labs.php/PHP-FPM" will be split into two different strings: "F5Labs.php" and "/PHP-FPM." The second capturing group of the RegExp (/.*), however, does not catch for newline (%0a) characters. For example, a string like "F5Labs.php/%0aPHP-FPM" results in an empty path string. This path string is assigned to the PATH_INFO variable in the configuration file.
The length of PATH_INFO (pilen) variable is later used to calculate the pointer address for variable PATH_INFO. Since the length of PATH_INFO is 0 (due to %0a), the result of PATH_INFO points to a location before the actual location of PATH_INFO.
This vulnerability in the validation of RegEx therefore results in a buffer underflow for character pointer path_info. A few lines later in the same file,3 the value of path_info[0] is set to 0. Since path_info points to an address before the actual address for PATH_INFO, this allows a malicious actor to insert a NULL (0) byte at an address.
This is notable because the CGI environment within PHP-FPM is managed using a data structure called fcgi_data_seg4 and is managed by another data structure called fcgi_hash.5 An attacker can construct a URL path and query string to point at the first byte of fcgi_data_seg data structure. Using path_info[0], an attacker can replace this first byte with a NULL byte. Putting a NULL byte into it moves the structure member fcgi_data_seg→pos to a new location. This new location is in the middle of existing environment variables.
Since the pos pointer now points to an address where the CGI environment variables are, a call to FCGI_PUTENV function by PHP-FPM will overwrite some of these existing variables. As we can see in Figure 1, PHP-FPM calls FCGI_PUTENV to replace the value of ORIG_SCRIPT_NAME and replaces it with the value controlled by an attacker. This allows an attacker to create a fake PHP_VALUE fcgi variable and use a chain of carefully chosen config values to get remote code execution.
Initial Request
Since %0a in URI is necessary to trigger this vulnerability, an exploitation request will contain that along with modified values of CGI environment variables.
The initial few requests are run in a loop by the threat actor. These requests contain a variation of the following commands, as shown here:
"short_open_tag=1",
"html_errors=0",
"include_path=/tmp",
"auto_prepend_file=a",
"log_errors=1",
"error_reporting=2",
"error_log=/tmp/a",
"extension_dir=\"<?=`\"",
"extension=\"$_GET[a]`?>\"",
These requests corrupt the existing CGI environment variables and allow the threat actor to execute commands remotely, including the ‘which which’ command. In this campaign, the threat actor tries to execute the 'which which' command on a vulnerable server. A vulnerable server will respond back with the location of the which command. By remotely executing the ‘which which’ command, the threat actor has shown that they are able to remotely execute code. From there, an attacker may execute a malicious executable or download malware.
Atlassian Confluence Widget Connector Remote Code Execution (CVE-2019-3396)
On March 20, 2019, Atlassian released a Confluence Security Advisory6 that fixed two critical vulnerabilities. One of the vulnerabilities was a Server-Side Template Injection (SSTI). Template engines, such as FreeMarker, Velociy, Smarty, Twig, and Jade, are widely used by many web application developers to present dynamic data SSTI vulnerabilities are caused by improper validation of user input.
According to Atlassian, there was SSTI vulnerability in Confluence Server and Data Center, in the Widget Connector. An attacker is able to exploit this issue to achieve path traversal and remote code execution on systems that run a vulnerable version of Confluence Server or Data Center. This is not the first time F5 researchers have seen this vulnerability exploited, however, this is the first time we are seeing this particular campaign.
Vulnerability Analysis
For this analysis, we downloaded versions 6.14.1 and 6.14.2, which allowed us to compare a vulnerable version of the code and the patched version. Since the vulnerability lies in the Widget Connector plugin, we used a Java decompiler to analyze this plugin. Version 6.14.1 contains a JAR file labeled widgetconnector-3.1.3.jar, and version 6.14.2 contains a JAR file labeled widgetconnector-3.1.4.jar. By running a diff command on the main JAVA files within these JAR files, we are able to analyze the patch.
As we can see in Figure 4, a few notable lines of code were added to patch this vulnerability. First, a new list called sanitizeFields is declared and a call to the function doSanitizeParameters(parameters) is added. This indicates that the parameters passed to renderManager.getEmbeddedHtml were not properly sanitized in the vulnerable version. These parameters are defined here7 and include Web Site's Widget URL, Pixel Height, and Pixel Width.
To render a widget, Widget Connector calls this.renderManager.getEmbeddedHtml(url, parameters) where this refers to the widget being called. Confluence comes with a list of different widget connectors which includes YouTube, Vimeo, Twitter, etc. Each of these widgets has its own renderer, and request parameters are sent to them by the Widget Macro class. These parameters including the renderer template are then embedded in a webpage.
Figure 5 shows the various video renderers that are prepackaged with Atlassian Confluence. To render a widget, the widget renderer class provides its HTML to the WidgetMacro class through the getEmbeddedHtml function.
Figure 6 shows the getEmbeddedHtml function for most video renderers. Notice how it's different from the YouTube video renderer in Figure 7.
Most video renderers call this.velocityRenderService.render(getEmbedUrl(url), params) from getEmbeddedHtml, except a few that specify their own templates to be embedded on a webpage.
The YouTube video renderer checks the request parameters to see if _template key is present, and if it isn't, it uses a predefined template. This parameter _template is not defined in the WidgetMacro docs and it can be controlled by a user. A malicious user can send a request with _template as a parameter and exploit the vulnerability by embedding a sensitive document (Local File Inclusion) in a webpage.
Initial Request
To exploit this vulnerability, a malicious actor needs to send a request to display a widget. The widget should allow a user controlled _template parameter to be used to render the HTML content that will be embedded in a webpage.
As we can see in Figure 8, a malicious actor sends a request to embed a widget. The widget in this request is for a YouTube video which is determined by the url parameter. The threat actor also injects a _template parameter which defines the template that will be embedded in a webpage. The threat actor instructs the server to fetch the template from a Github page controlled by the threat actor.
Payload Analysis
Figure 9 shows the template injected by the threat actor. This template will be used to render the widget object. The script above is written in Velocity Template Language (VTL). Velocity is a Java-based template engine. It permits web page designers to reference methods defined in Java code. The script expects uses the cmd parameter to create a process using Java.lang.Process.
The cmd passed to the template is /bin/bash -c {echo,cm0gLXJmIC92....}|{base64,-d}|{bash,-i}"}}} (clipped for brevity).
The Base64 decoded command is shown in Figure 10. The threat actor instructs the server to first kill all wget, curl, and rm commands and then instructs the server to download a malicious file. In a previous article, we discussed in detail the malicious file downloaded, which is a Golang malware that mines Monero cryptocurrency.
Conclusion
New campaigns detected in November largely targeted vulnerabilities disclosed in this year. Many of these vulnerabilities have exploits that are easily accessible and searchable on the Internet. This makes it easier for a threat actor of any skill level to exploit different servers. Nginx serves 32 percent of all active websites, and Atlassian Confluence is used by over 40,000 different companies. More than ever, it is imperative to ensure a vulnerability and patch management process is in place, and that it is carefully adhered to by the responsible team. It is also equally important to ensure that critical system logs are carefully monitored and retrospective analysis done after a vulnerability has been patched. A stealthy threat actor can create a malicious process that can easily be missed during forensic analysis as it lays dormant for a while before starting.
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.
Security Controls:
Enterprises should consider implementing the following security controls based on their specific circumstances:
- Deploy a web application firewall.
- Implement a patch management program in order to keep systems up to date with patches.
- Continuously monitor the health of critical systems.
- Train application developers in secure coding practices.
