Critical vulnerability in Vbullletin 3.x - Self-Submitting HTML Form Attacks

[Michael Morris]

I submitted this to vb3 but since I have a fix I thought I'd share it.

Vbulletin forums can be attacked from self submitting forms. Basically you write a small html file with a self submitting form to make a post, change signature, maybe change a password. You then submit a link on the post inviting curious board members to follow it. When they do, it does it's evil magic, using their cookie or session variable for authorization.

To block this nasty attack, use the PHPINCLUDE_START template to verify that all attempts to execute a $_POST action originate from your boards.


if (!empty($_POST['do']) AND !strstr($_SERVER['HTTP_REFERER'], "YOURBOARDSURL"))
{
print_no_permission();
}


Replace YOURBOARDSURL with, well, your boards url.

[Floris]

What is the unique support ticket system id - you should get it when you submit it to vbulletin.

[SaN-DeeP]

Do we really need to add/apply the fix to our site/forums ?

Regards,

[Kier]

I submitted this to vb3 but since I have a fix I thought I'd share it.

Vbulletin forums can be attacked from self submitting forms. Basically you write a small html file with a self submitting form to make a post, change signature, maybe change a password. You then submit a link on the post inviting curious board members to follow it. When they do, it does it's evil magic, using their cookie or session variable for authorization.

To block this nasty attack, use the PHPINCLUDE_START template to verify that all attempts to execute a $_POST action originate from your boards.


if (!empty($_POST['do']) AND !strstr($_SERVER['HTTP_REFERER'], "YOURBOARDSURL"))
{
print_no_permission();
}


Replace YOURBOARDSURL with, well, your boards url.
The code you have there is potentially problematic - try replacing it with this:

if (!empty($_POST['do']) AND strpos(strtolower($_SERVER['HTTP_REFERER']), strtolower($_SERVER['HTTP_HOST'])) === false)
{
print_no_permission();
}It should also be noted that if your webserver is one of the rare ones that does not set an HTTP referrer, this code will break vBulletin and prevent just about any kind of interaction with it.

[miz]

so should we do it ?
is it apply for 3.0.3 ?

[Kier]

so should we do it ?
is it apply for 3.0.3 ?
I do not consider it to be a critical problem, as just about every web application out there can be exploited in this manner.

We are looking into ways to combat it for the forthcoming vBulletin release, but for now if you want a temporary fix and you are certain that your server sets the HTTP referer field, then you can use the code posted above.

[SaN-DeeP]

I do not consider it to be a critical problem, as just about every web application out there can be exploited in this manner.

We are looking into ways to combat it for the forthcoming vBulletin release, but for now if you want a temporary fix and you are certain that your server sets the HTTP referer field, then you can use the code posted above.
call me a noob but how to test if server sets the HTTP referer field ?

[Kier]

call me a noob but how to test if server sets the HTTP referer field ?

Copy this code to a file called reftest.php and upload it to your server, then browse to the file and click the button on the page.


<?php

if (!empty($_POST['do']))
{
if ($_SERVER['HTTP_REFERER'] != '')
{
echo "<p>Your HTTP referrer is <em>$_SERVER[HTTP_REFERER]</em>.</p>";
}
else
{
echo "<p>Your server does not appear to set an HTTP referrer. Oh dear.</p>";
}
}

?>
<form action="reftest.php" method="post">
<input type="hidden" name="do" value="moo" />
<input type="submit" value="Click me" />
</form>

[Jaxx]

props to the vB time for a fast response on this. :)

[WotC_Mel]

FWIW, we got hit by this exploit this week. In a matter of an hour there were 113 posts linked to the bad webpage as everytime someone looked at the linked site, it changed your sig to link to the page and created a new post under the viewers account that asked people to evaluate the "art" at said page.

So, yeah, I think it is important to view it as critical.

-Melanie

[WotC_Tech]

I do not consider it to be a critical problem, as just about every web application out there can be exploited in this manner.


I won't argue that many web applications have this vulnerability, but I would like to point out the severity to other vB administrators. If an admin of your forum is tricked into visiting a web site containing one of these self-submitting forms, an attacker can gain administrative privileges on your forum, and perform other administrative tasks in the context of the admin who visited the malicious web site.

While this exploit requires some interaction from a site admin, it is not very difficult to trick someone into visiting a site.

[WotC_Tech]

The code you have there is potentially problematic - try replacing it with this:

if (!empty($_POST['do']) AND strpos(strtolower($_SERVER['HTTP_REFERER']), strtolower($_SERVER['HTTP_HOST'])) === false)
{
print_no_permission();
}

To prevent bypassing this mechanism it might be better to check only the "host" portion of the referer:

$parsed_referer=parse_url($_SERVER['HTTP_REFERER']);
if ((!empty($_POST['do'])) AND
(strtolower($parsed_referer['host']) != strtolower($_SERVER['HTTP_HOST'])))
{ print_no_permission(); }


Otherwise an attacker could simply append the hostname of the forum server to the end of the URL.

-Mike

[SaN-DeeP]

Copy this code to a file called reftest.php and upload it to your server, then browse to the file and click the button on the page.


Done.. clicked the button and i got the proper message
Your HTTP referrer is http://www.tech-arena.com/reftest.php.

My Server aint vulnerable :)
Thank for help

Regards,

[WetWired]

Be aware that some internet privacy programs strip outgoing HTTP_REFFERER information, which will result in a very frustrating situation for some people if you use this fix; many will not even know that the privacy program is doing this.