Serious security flaws found in vBulletin 4.0.x branch

[Floren]

Hi all,

I had the chance to look a little to the new vBulletin code. I realized there are some major security flaws with the product, even on latest 4.0.3 version. For example, if you give FAQ editing permissions to your staff, they can easily read your MySQL database, username, password, etc. Basically, any variable present into config.php file can be outputted.

To test it in vBulletin 4.0.3, edit a FAQ entry and add inside this following code:

{$vbulletin->config['Database']['dbname']},
{$vbulletin->config['MasterServer']['servername']},
{$vbulletin->config['MasterServer']['port']},
{$vbulletin->config['MasterServer']['username']},
{$vbulletin->config['MasterServer']['password']}

You will be able to see right away vital information a hacker needs to take over your site. After more investigation, the above code will pull the data on any vBulletin version, starting with 3.0.0 branch.

Things are getting worst, the styles and phrases are also affected. I will not post how to pull data from those areas, because the damage is way bigger. I could drop your database easy.

The solution for now is to simply remove any permissions related to FAQ, styles and phrases, from people you don't trust 100%.

Unfortunately, I cannot report those issues to vBulletin site because I was banned. I care a lot about the product, that is why I continue to help others and publish this information on my forums. I simply hope that vBulletin administration will reconcile their opinion about myself and allow me to take back my place into community.

[Mikey]

If this is present in 3.0, how was it missed for so long? Is it because PHP is allowed in the aforementioned areas?

[Floren]

I talked to Scott MacVicar about it, the old developers were aware of this issue.
I guess nobody thought of it as being an issue, they thought a staff member "would never" take down your board.

[hornstar]

they made an annoucement on this a couple of days ago.

Security Tips Regarding Admin Permissions

Although it should be apparent that no one should be given Admin access unless they are completely trustworthy, we do recognized that sometimes these things do occur. While we still strongly recommend that you only give Admin access to people you thoroughly trust, you can still minimize potential security issues by limiting the permissions you make available to your Admins. The place to do that is here:

Admin CP -> Usergroups -> Administrator Permissions

You may need to make yourself a Super Admin in order to do this. Edit this section of config.php:

// ****** SUPER ADMINISTRATORS ******
// The users specified below will have permission to access the administrator permissions
// page, which controls the permissions of other administrators
$config['SpecialUsers']['superadministrators'] = 'x';

...and replace x with your userid (not user name.)

In addition to the more obvious permissions that can pose a risk, here are some other areas that are not as obvious but can result in security breaches for a knowledgeable user:

Can Administer Styles
Can Administer Languages
Can Administer FAQs
Can Administer Plugins

You should not allow these permissions for any Admin that is not 100% trustworthy.

I used to have other admins, but these days I just feel it is best to be the only Admin as security can just get out of control when you give it away to people who you think you can trust (they could be keylogged for one).

Anyway, thanks for bringing it up again, I have a better idea why I should not give those permissions away now.

[Mikey]

Ah, well yes, common sense is required in situations such as these, I don't think the title is appropriate anymore as it doesnt just affect the vBulletin 4.0.x branch.