Attack Campaign
December 24, 2019

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

article
12 min. read
By Harsh Chawla, Remi Cohen
Previous article in this series
Next article in this series

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.

Figure 1. Calculation of path_info pointer address and insertion of null byte
Figure 1. Calculation of path_info pointer address and insertion of null byte

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.

Figure 2. Screenshot of the exploitation request
Figure 2. Screenshot of the exploitation request

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.

Figure 3. The threat actor tries to execute the 'which which' command
Figure 3. The threat actor tries to execute the 'which which' command

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.

Figure 4. Diff of Widget Connector Macro class within widgetconnector-3.1.3 and widgetconnector-3.1.4
Figure 4. Diff of Widget Connector Macro class within widgetconnector-3.1.3 and widgetconnector-3.1.4

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 5. Different renderers and templates available out of the box
Figure 5. Different renderers and templates available out of the box

Figure 6 shows the getEmbeddedHtml function for most video renderers. Notice how it's different from the YouTube video renderer in Figure 7.

Figure 6: getEmbeddedHtml function
Figure 6: getEmbeddedHtml function

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.

Figure 7. YouTube video renderer allows _template parameter to be input by the user
Figure 7. YouTube video renderer allows _template parameter to be input by the user

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.

Figure 8. Initial request sent by the threat actor
Figure 8. Initial request sent 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.

Figure 9. Script written in VTL to create a process using Java.lang.Process
Figure 9. Script written in VTL 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.

Figure 10. Golang malware that mines Monero cryptocurrency
Figure 10. 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.

Previous article in this series
Next article in this series

Security Controls:

Enterprises should consider implementing the following security controls based on their specific circumstances:

Technical
Preventative
  • Deploy a web application firewall.
  • Implement a patch management program in order to keep systems up to date with patches.
Technical
Detective
  • Continuously monitor the health of critical systems.
Administrative
Preventative
  • Train application developers in secure coding practices.

Need-to-Know

Expertly picked stories on threat intelligence

Hundreds of apps will be attacked by the time you read this.

So, we get to work. We obsess over effective attack methods. We monitor the growth of IoT and its evolving threats. We dive deep into the latest crypto-mining campaigns. We analyze banking Trojan targets. We dissect exploits. We hunt for the latest malware. And then our team of experts share it all with you. For more than 20 years, F5 has been leading the app delivery space. With our experience, we are passionate about educating the security community-providing the intel you need to stay informed so your apps can stay safe.

Every

9 hrs

a critical vulnerability—with the potential for remote code execution—is released.