Attackers Are Quick to Exploit vBulletin’s Latest 0-day Remote Code Execution Vulnerability

Imperva’s Cloud WAF has identified instances of a new 0-day vulnerability being exploited within a matter of hours of the exploit being published.

On Monday 23rd September 2019, an exploit was published for a vulnerability found within vBulletin (versions 5.0.0 to 5.5.4), allowing malicious attackers to perform authentication-free Remote Code Execution on the origin server. Alongside the exploit, “google dorks” – which allow attackers to find potentially vulnerable instances of the service in the wild – were also published.

The vulnerability exists where URL parameters are passed to a widget file within the forum software itself. These parameters are then parsed on the server without any security checks – the malicious attacker can then inject commands and is able to remotely execute code on the application server.

The exploit for this vulnerability enables an attacker to generate a post request to the vulnerable instance of vBulletin, containing the parameter ‘widgetConfig’ which is parsed on the server and evaluated without being sanitized. For example:

The attack pattern triggered mitigation rules on our Cloud WAF, based on known existing attack patterns as well as on data we’ve collected on malicious source IPs. This allowed Imperva to observe and block the attack as it occurred, within 24 hours of the vulnerability’s publication. The rules in question matched against known malicious Remote Code Execution patterns present in the body of the request.

A Python-based exploit, which can easily be used by low skilled attackers is now publicly available for anyone to exploit this 0-day vulnerability, which has been assigned CVE-2019-16759.

Below are some examples of the payloads observed since the exploit’s release, along with a brief explanation of the perceived attacker intent.

Example 1:

Number of similar observed requests: 7,000+
Explanation: The attacker is using the shell_exec function to execute shell commands on the server.

Example 2:

Number of similar observed requests: 3,000+
Explanation: The attacker is likely testing the exploit by executing the md5 function on a given string. If the server returns the md5 hash the exploit has worked.

Example 3:

Number of similar observed requests: 70+
Explanation: The eval function is used to run base64 decoded, obfuscated php.

Example 4:

Number of similar observed requests: 50+
Explanation: Attempts to read a remote file, demonstrating that the server can execute an attacker code.

Example 5:

Number of similar observed requests: 1
Explanation: The attacker is using the shell_exec to use wget to retrieve a php file from a remote location, and write it to the server. In this instance the php code is a backdoor, enabling uploads of additional files.

vBulletin RCE Vulnerability: Timeline of Events

At the time of writing, Imperva has observed over 10,000 instances of rules triggered by the payload generated by the published exploit.

1. 23/09/19 – 23:05: vBulletin 5.x 0day pre-auth RCE exploit published on seclists.org.
2. 24/09/19 – 08:15: First malicious requests similar to the payload from the published exploit triggers blocking rules on Imperva Cloud WAF.
   These initial payloads were not generated directly from the published exploit, however,  as ‘echo shell_exec(‘”+cmd+”‘);’ is passed in the parameter in the published exploit so shell commands can be executed.
3. 25/09/19 – 03:02: First malicious payloads matching exactly those generated by the published exploit trigger blocking rules on Imperva Cloud WAF.
   
   
4. 25/09/19 – 05:15: Mass-Pwn-vBulletin scanner published on Github
5. 25/09/19 – 10:17: vBulletin security patch released on forums.
6. 25/09/19 – 13:38: First malicious requests matching those generated by the Mass-Pwn-vBulletin scanner observed and blocked.
7. 25/09/19 – 14:58: Specific rule matching the published exploit added globally to Imperva Cloud WAF.
8. 26/09/19 – 04:50: Nmap script for CVE-2019-16759 released on Github.

Another valuable insight provided by the functionality in the Imperva Cloud WAF was the ability to track the volume of malicious requests from IPs of known threat actors, which is constantly updated. The Imperva Cloud WAF has unique ways of gathering this data and, in this case, we were able to observe that a number of the requests originated from IPs which had already been listed as malicious in previous activities such as remote file inclusion. 

The Security Research Team at Imperva are continuing to monitor this attack as it develops.