vBulletin 5: 0day from Imperfect Patch
Early this week, popular forum software platform vBulletin faced a brand new remote code execution 0day vulnerability—the culprit: an imperfect patch.
Over the weekend, security researcher Amir Etemadieh released a proof-of-concept necessary to bypass a patch designed to address the same issue indexed under CVE-2019-16759.
The original vulnerability affected vBulletin 5.x through 5.5.4 and “allows remote command execution via the widgetConfig[code] parameter in an ajax/render/widget_php routestring request” (cve.mitre.org).
To better illustrate of how many web servers are affected by this new addition to the vulnerability, the following Google dork displays all the sites running vBulletin forum software:
When this vulnerability was first released, all that was needed to leverage it for an attack was a specially crafted POST request. The request sent to the targeted system would allow anyone to execute any arbitrary command (associated with the “service account” of the user bound to the vBulletin instance). This vulnerability is also “pre-auth”, meaning that a user does not have to be logged in for it to work.
This issue affects vBulletin’s template rendering engine explicitly. Templates allow a vBulletin user to style their forum. The syntax for writing templates resembles front-end code like HTML mixed with inline code, which is rendered back as PHP. It’s during the actual rendering process that the vulnerability is expressed.
Template structure causes filtering problems
The template structure in vBulletin exacerbates the problem. It allows the usage of what’s known as “child templates”. Once the parent template is processed and evaluated, the next series of child templates (if present) is also rendered.
According to Amir Etemadieh, this can cause many filtering problems associated with both XSS (injecting arbitrary client-side script) and the generation of non-escaped PHP, just from how the template functionality is structured. It’s like having to play a constant game of cat-and-mouse, defeating the renderer’s filtering procedures.
What did the patch for CVE-2019-16759 miss? After all, it checks that routestring does not end with a widget_php route before executing the template.
What was missing when the patch was developed was the consideration of loading a child template using a value stored using a different name. The following is the proof-of-concept for executing any arbitrary command (as the service account that manages vBulletin) on the system:
The function parameter of shell_exec() is what executes the command on the system. Any PHP code can replace it as it is unescaped and run.
Amir Etemadieh also made available a Bash, Python, and a Metasploit module for this exploit. More information about this vulnerability can be found on the researcher’s blog: https://blog.exploitee.rs/2020/exploiting-vbulletin-a-tale-of-patch-fail/.
Google dork showing all the websites powered by vBulletin software
Many forums powered by vBulletin will likely face data breaches in the coming days, similar to when the original 2019 vulnerability was disclosed. Jeff Moss has already reported that someone tried using the exploit within just three hours following its release on forum.defcon.org (just right after the yearly conference).
Disable PHP rendering
A short term patch against this is for administrators to disable PHP rendering entirely in vBulletin. Here are the steps to follow:
- Navigate to the vBulletin administrator control panel.
- Click “Settings” in the menu on the left, then “Options” in the dropdown
- Choose “General Settings” and then click “Edit Settings”.
- Look for “Disable PHP, Static HTML, and Ad Module rendering”, Set to “Yes”.
- Click “Save”.
Source: twitter.com
What’s interesting about vBulletin is that it has a long track record of software problems, mostly involving code execution and SQL injection. vBulletin does not have a bug bounty program, which means an extra incentive for some threat hunters to disclose vulnerabilities is missing (see vBulletin’s vulnerability statistics below).
Source: cvedetails.com
What about other forum software?
Content management software, especially for forums, has always been closely scrutinized for vulnerabilities due to the level of impact and the potentially exposed type of data. Forums attract attackers because they store all sorts of information – user names, IP addresses, emails, and passwords – that can be used to deanonymize users and conduct credential stuffing attacks elsewhere.
Many alternatives to vBulletin, such as xenForo, phpBB and MyBB, all face that same risk. Once there is a 0day, you either find a quick fix (and when I say quick, I mean less than an hour to act) or face downtime.
It’s almost trivial for attackers to formulate enumeration techniques to find vulnerable instances of web technology and quickly mass-exploit them. 0days like this are typically not released to the public, so you wouldn’t know they even exist. Is there a better way for forum owners to protect themselves and their online communities?
There is. A setup that involves two trusted endpoints promises the most effective remediation. Both the client and server are validated against each other to only allow for what the website allows users to transmit. To put it another way, arbitrary POST/GET requests are not allowed unless permitted through the front-end’s submission forms.
Suppose the client’s access is entirely restricted. In that case, users have to interact with the website precisely as defined and offered by the front-end – you minimize the web-exploitation attack surface.
*** This is a Security Bloggers Network syndicated blog from Authentic8 Blog authored by Amir Khashayar Mohammadi. Read the original post at: https://blog.authentic8.com/vbulletin-5-0day-from-imperfect-patch/
