Critical vulnerability in Vbullletin 3.x - Self-Submitting HTML Form Attacks
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.
PHP Code:
if (!empty($_POST['do']) AND !strstr($_SERVER['HTTP_REFERER'], "YOURBOARDSURL"))
{
print_no_permission();
}
Replace YOURBOARDSURL with, well, your boards url.
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.
PHP Code:
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:
PHP Code:
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.
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.
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 ?
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 Code:
<?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>";
}
}
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.
12-09-2004, 08:04 PM
Critical vulnerability in Vbullletin 3.x - Self-Submitting HTML Form Attacks
Linear Mode
