vBulletin 0-Day critical issue

2015.11.06
Credit: Check Point
Risk: Medium
Local: No
Remote: Yes
CWE: N/A


CVSS Base Score: 7.5/10
Impact Subscore: 6.4/10
Exploitability Subscore: 10/10
Exploit range: Remote
Attack complexity: Low
Authentication: No required
Confidentiality impact: Partial
Integrity impact: Partial
Availability impact: Partial

vBulletin is a commercial forum and blog platform developed by vBulletin Solutions, Inc. It was created over 10 years ago and is written in PHP. It is the world’s most popular forum platform, powering ~78% out of the forums in the top 100K web-sites. Currently there are estimated to be over 40,000 live sites using vBulletin. A month ago, Check Point privately reported a critical unauthenticated RCE vulnerability to vBulletin support. This vulnerability was independently discovered by Netanel Rubin, and assigned CVE-2015-7808. When exploited, the vulnerability allows an attacker to execute PHP code on any vBulletin server without requiring user authentication. It does not require any themes or modules other than the ones installed by default. As widely reported, the main vBulletin.org forum was compromised earlier this week and an exploit for a vBulletin 0-day was up for sale in online markets. A patch later released by vBulletin fixes the vulnerability reported, but fails to neither credit any reporting nor mention the appropriate CVE number. As the vulnerability is now fixed and an exploit exists in the wild with public analyses, we follow with the technical description as submitted to vBulletin. If you administer any vBulletin web site, we urge you to apply the patch as soon as possible, as exploitation risk is imminent. It is important to note the analyzed public exploit shows a different chain than the one we used for our PoC; therefore we cannot link the attacks directly to our report. Disclosure Timeline Oct 4 2015 First contact with vBulletin Oct 5 2015 First response received, asked for PGP key to securely transfer report Oct 6 2015 PGP request denied: “I will hide the response so it’s not publicly available” Oct 10 2015 Sent complete report unencrypted as attached PDF Oct 11 2015 “We cannot accept attachments in our ticket system – please upload this to your server and provide a link to download this.” Oct 11 2015 Uploaded report to a public server and sent a link. Updated with CVE-2015-7808 assignment. Oct 14 2015 Asked vBulletin for confirmation/update Oct 14 2015 “We’re still working to establish the issues and identify any fixes that may be required.” Oct 27 2015 Asked vBulletin for confirmation/update Oct 27 2015 “We’re still working to establish the issues and identify any fixes that may be required.” Nov 2 2015 Patch released by vBulletin Nov 5 2015 Public disclosure Technical Description vBulletin handles a lot of the heavy lifting through an internal API. Unfortunately parts of that API are also used as a gate for Ajax requests, and as a result this API is also accessible through the regular CGI. This API does not validate the origin of the request, allowing us to access any part of its interface. That interface, in fact, allows us to call any public method in any class that inherits from ‘vB_Api’ and located in ‘/core/vb/api/’. This folder contains dozens of classes and hundreds of methods for us to use as an attack surface, and as noted, some of them considered internal methods. Moreover, we can call these methods with any arguments we’d like, as the API doesn’t have any sort of argument white listing. Read more: http://blog.checkpoint.com/2015/11/05/check-point-discovers-critical-vbulletin-0-day/

References:

http://blog.checkpoint.com/2015/11/05/check-point-discovers-critical-vbulletin-0-day/


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