vBulletin SSRF Server-Side Request Forgery

An interesting article on a vBulletin SSRF vulnerability. Acunetix describes SSRF (Server-Side Request Forgery) nicely.

Think of it this way, with an SSRF request, you can make requests "on-behalf" of the vulnerable server!

Thus the primary target of an SSRF request if an internal system that you normally wouldn't have access to, but since you can make requests "on-behalf" of the vulnerable server, since that vulnerable server has access to an internal system, you now can make a request to that other internal system. As an example you could
1.) Make SSRF attack request to internet facing Web Server X
2.) If vulnerable, Web Server X would turn around and run your scan/exploit attack against internal non-internet facing Application Server Y


Now the attack you run could vary from this like ...
- Recon (where you try to enumerate all the internal non-accessible devices)
- Scans (where you try identify vulnerabilities that exist on an internal non-accessible device)
- Exploit (where you try to exploit a vulnerabilty and compromise an internal non-accessible device)


All of those requests would come on behalf of the vulnerable server so it would appear as if the vulnerable web server is making the requests when in actuality the external attacker is making the requests.

For this particular vBulletin vulnerability, it can be mitigated by applying the appropriate patches.

At a higher level, to minimize the damage of an SSRF vulnerabilty in your environment, make sure you're applying network segmentation, firewall rules, ip filtering, least privilege, etc. so that even if the attacker finds an SSRF vulnerability and starts making requests on behalf of your vulnerable server, the attacker can only access, scan, and exploit the devices that the vulnerable server has access to ... which hopefully is a small subset of your actual internal environment.

More about neonprimetime

• neonprimetime pastebin
• neonprimetime virustotal
• @neonprimetime twitter
• neonprimetime reddit

Top Blogs of all-time

1. pagerank botnet sql injection walk-thru
2. DOM XSS 101 Walk-Through
3. An Invoice email and a Hot mess of Java

Top Github Contributions

1. Qualys Scantronitor 2.0

Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.

vBulletin 5.1.x #rce walk-through

I saw this vBulletin rce exploit on pastebin written in python by Mauritania Attacker. Thought it was interesting and worth talking thru.

First, let's understand that vBulletin is software used to build website forums. Per wiki, some of the bigger ones are Bodybuilding.com and Gamerzplanet.net.

Next let's understand the exploit. Per the name it's rce (Remote Code Execution) which essentially means you'll be able to run the code you want against the web server remotely (from your laptop if you want for example). It does not appear to require any authentication, so you don't need a username/password, you simply need to know a website/url and that's it. Unauthenticated RCE is perhaps the scariest category of exploit. 0day also is bad because that likely means it was being used and exploited before anybody told the vBulletin developers and thus before they had a chance to patch it and before website owners had a chance to apply a fix.

Now the exploit linked above is written in python. The script simply lets you type in a website ( site = input('Target : ') ) and it'll perform an initial harmless test (mad = inject(site)) to validate if the site is vulnerable to the rce exploit or not. We'll dig a bit deeper into that test in a bit down below. Next, if the test is successful, and the website is vulnerable, it prompts the user for the shell commands you want to run against the web server ( userinput = input("AnonGhost@Target :") ). Then it runs them (bash(site, userinput)). That's it, that's how scarey and how simple this vulnerability is.

So first, the test.

import requests, re, sys
url = ghost + '/ajax/api/hook/decodeArguments?'
r = requests.get( url,
     params = 'arguments=O:12:"vB_dB_Result":2:{s:5:"%00*%00db";O:11:"vB_Database":1:{s:9:"functions";a:1:{s:11:"free_result";s:6:"system";}}s:12:"%00*%00recordset";s:14:"echo Th3Falcon";}', timeout= 50 )

The test is going to exploit a vulnerability in the ajax API calls (Ajax API DecodeArguments) in /core/vb/api/, in the file hook.php, in the function decodeArguments. That function takes 1 parameter which is actually a serialized version of a bunch of arguments in json notation. The code inside hook.php is going to end up de-serializing those arguments from json into objects. Unfortunately the way it was originally written it wasn't properly serializing or deserializing (see below).

If we look at the json in the url parameters above closer (with some nicer indentation and highlighting) we can see that it's a serialized version of the class vB_dB_Result.

vB_dB_Result
O:12:vB_dB_Result:2:{
   s:5:%00*%00db;O:11:vB_Database:1:{
     s:9:functions;a:1:{
       s:11:free_result;
       s:6:system;
     }
   }
   s:12:%00*%00recordset;
     s:14:echo Th3Falcon;
}


Reading the json above can be a bit tricky. Here's some useful information for reading json...
- O is "object", then the length of the class name, then the class name, then the object size (# of properties it has)
- s is "string", then the length (# of characters), and then the string's value, closed by a semicolon (;);
- a is an "array", then the length (# of key/value pairs), and then 2 string for each for both the key and the value.
- %00 is the null byte (single character).


The key things from the exploit code and jason above in red is that it appears the attacker can control both a bash command that gets run plus it's parameters. So he can run "system('echo Th3Falcon')". uh-oh. Why can he run that?

It appears that in the decodeArguments method...

public function decodeArguments($arguments)
{
   if ($args = @unserialize($arguments))


... the way the unserialize/serialize methods work make is possible for the user to control these values. From what I've read, the fix is to change it to json_decode/json_encode to prevent this attack. json_decode is smarter and knows where there are unserialize functions that shouldn't be allowed to be controlled by user input. If you're running the old code and still using the unserialize/serialize combo, then the attacker with input from the url ends up controlling both the bash command and the parameter which ends up being a really bad combination.

function free_result($queryresult)
{
   $this->sql = '';
   return @$this->functions['free_result']($queryresult);
}


It still may be tough to see with the naked eye how this is working, so let's break it down with some pretty colors.

@$this->functions['free_result']($queryresult);


Becomes

@system('echo Th3Falcon');


Which means your web server is now going to be owned because I'm sure the attacker as higher ambitions that simply running an echo.



More about neonprimetime

• neonprimetime pastebin
• neonprimetime virustotal
• @neonprimetime twitter
• neonprimetime reddit

Top Blogs of all-time

1. pagerank botnet sql injection walk-thru
2. ali.txt php injection walk-thru
3. apache struts2 rce walk-thru

Copyright © 2015, this post cannot be reproduced or retransmitted in any form without reference to the original post.