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

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. Unlike in recent months when the focus was on deploying cryptominers, September’s threat actors were detected trying to exploit newer vulnerabilities that could lead to Remote Code Execution (RCE). New campaigns in September were up 20% from August.

 Here’s an overview of the new threat activity we saw in September 2019:

• An active exploitation campaign targeting vBulletin servers vulnerable to an RCE vulnerability (CVE-2019-16759).
• A reconnaissance campaign targeting Fortinet SSL VPN servers vulnerable to a FortiOS system file leak vulnerability (CVE-2018-13379).
• In addition to these, we also detected the following notable campaigns targeting a variety of existing vulnerabilities:
  • Bash ShellShock (CVE-2014-6271): This campaign aims to first identify web servers vulnerable to the ShellShock vulnerability. The threat actor then instructs the server to download and execute an Internet Relay Chat (IRC) bot malware.
  • Drupal Drupalgeddon2 RCE (CVE-2018-7600): This campaign first aims to identify Drupal web servers vulnerable to a Drupalgeddon2 RCE vulnerability. The threat actor then instructs the server to download and execute a malicious file.
  • JBoss ReadOnlyAccessFilter of HTTP Invoker Deserialization (CVE-2017-12149): This campaign aims to identify Windows-based JBoss application servers vulnerable to a JBoss ReadOnlyAccessFilter of HTTP Invoker Deserialization vulnerability. The threat actor then instructs the server to download and execute a malicious file.
  • Oracle WebLogic WLS Security Component RCE (CVE-2017-10271): This campaign aims to identify WebLogic servers vulnerable to Oracle WebLogic WLS Security Component RCE vulnerability. In order to conduct reconnaissance, the threat actor instructs the server to create a text file in the web folder. This is the first step in a larger attack effort.

vBulletin Remote Code Execution (CVE-2019-16759)

On September 23, 2019, an anonymous researcher posted on SecLists.org a proof-of-concept (PoC) zero-day exploitZero-day vulnerabilities are those that are unknown or unaddressed by the vendor. targeting servers running vBulletin (v5.0.0-v5.5.4) content management system (CMS).¹ The researcher simply published the PoC without indicating whether he or she had attempted to contact vBulletin or follow a responsible disclosure process. With the exploit PoC being available, threat actors wasted no time trying to exploit this vulnerability. According to ZoomEye, threat actors had plenty of targets since over 20,000 servers worldwide are running vBulletin CMS.

Initial Request and Vulnerability Analysis

Since the vulnerability was a zero-day and the exploit was posted without warning, it took vBulletin maintainers more than 24 hours to post a public announcement¹ that a patch was available.

Before the patch was available, F5 researchers detected at least one malicious actor targeting this vulnerability. The actor used a unique method, crafting an HTTP POST request that patched the vulnerability by adding a password. This ensured that the vulnerability could only be exploited if a request contained the password set by the threat actor.

The threat actor sends a POST request to index.php with a query parameter, routestring set to ajax/render/widget_php. Upon analyzing the source code for vBulletin v5.4.1, we found that it uses the value of the routestring parameter to execute a streamlined function. The application attempts to find whether the route to this function is predefined through the isQuickRoute() function.

Within the isQuickRoute() function, the application checks to see if the query prefix has a handler attached to it. In the case of ajax/render, the handler is callRender.

The callRender() function renders a template based on the third string after ajax/render. In this case, the third string is widget_php. It sends this information in a JSON format to the staticRenderAjax() function.

The staticrenderAjax() function within the template.php file extracts information from the JSON file and sends it to staticRender() function to render the relevant data using the template.

Once within the render() function, the application calls the eval() function with templateCode as the parameter. This value within templateCode is initialized using vb5_Template_Cache which is defined in the cache.php file.

The body of the POST request is then sent to the evalCode function within controller/bbcode.php. It’s important to note here that the evalCode function does not conduct any input validation and simply executes the commands passed to it. Input validation is an essential security step needed in code development in order to stop malicious input and protect internal databases and infrastructure. The fact that the evalCode function is insecure is a known issue and, when reverse engineering any program, is a good place for analysts to start.

Payload

In this particular campaign, the threat actor sends the following code to be executed on a vulnerable vBulletin server.

echo shell_exec('sed -i \'s/eval(\$code);/if (isset(\$_REQUEST[\"epass\"]) \&\& \$_REQUEST[\"epass\"] == \"2dmfrb28nu3c6s9j\") { eval(\$code); }/g\' includes/vb5/frontend/controller/bbcode.php && echo -n exploited | md5sum'); exit;

This command instructs the server to modify the vulnerable code and add a password check on it. The password in this case is 2dmfrb28nu3c6s9j.Therefore, the threat actor patches the vulnerability by ensuring that only a request that contains the valid password is able to exploit this vulnerability.

Figure 9 shows the contents of the evalCode function after a successful exploitation. Notice how the evalCode function is now different from what’s shown in Figure 8.

Once the payload is executed in this function. The malicious actor will be able to send remote arbitrary commands to the server and conduct further exploitation by RCE.

Fortinet SSL VPN Credentials Disclosure (CVE-2018-13379)

At Black Hat 2019, security researchers from Devcore delivered a presentation about critical vulnerabilities in SSL VPN servers, one of which was Fortinet's FortiGate SSL VPN. The researchers were able to conduct reconnaissance and read credentials in clear text by exploiting a pre-auth arbitrary file reading vulnerability.

Fortinet's FortiGate is a popular SSL VPN server and, according to Google, over 600 FortiGgate servers are publicly accessible.

In September, F5 threat researchers detected a threat actor running a reconnaissance campaign against vulnerable FortiGate VPN servers. The initial GET request is shown in Figure 11.

A vulnerable FortiGate SSL VPN server responds to this request with contents of the sslpvpn_websession file, which contains the username and password of a user. This information can be used or sold to threat actors in order to compile brute force and credential stuffing lists. While reconnaissance campaigns do not actively exploit systems, they enable threat actors to gain valuable information about users.

According to the researchers, the vulnerability was responsibly reported to Fortinet in December 2018 and was fixed in March 2019. This gave users ample time to update their systems before the vulnerability was publicly discussed at Black Hat USA in August 2019.

Conclusion

The campaigns detected in September point to the importance of vendors having a vulnerability disclosure program in place so that good-faith security researchers can report security issues they discover. In the case of Fortinet, the researchers who discovered the vulnerability followed a responsible disclosure process before publicly presenting their research at a major security conference. But in the case of vBulletin, it’s not known whether the anonymous researcher reached out to the company before disclosing the vulnerability online, but it’s pretty certain that many organizations were thrown into panic when they saw the proof of concept exploit posted online. Having a vulnerability disclosure program shows a willingness on the part of the vendor to work well with external security researchers, and more importantly, to have processes in place for handling those vulnerabilities. The goal is to minimize the impact to organizations using those vulnerable products by making patches available as quickly as possible.

As always, there are many defenses enterprises can put in place, and defense in depth is the security approach many organizations use. For most, a web application firewall (WAF) serves as the first line of defense for their applications. One that’s well-monitored, configured, and updated should also be able to stop 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.

Countermeasures

The following security controls are recommended: