Today SonarSource is pleased to share with you a guest contribution to our Code Security blog series. The following blog post is authored by Simon Scannell and Carl Smith -two independent security researchers- joining us in sharing their findings of real world vulnerabilities and how they directly relate to Code Security. Over to you Simon and Carl!
A sophisticated attacker could develop an exploit for the Stored XSS vulnerability and then send a private message to a targeted administrator of a MyBB board. As soon as the administrator opens the private message, on his own trusted forum, the exploit triggers. An RCE vulnerability is automatically exploited in the background and leads to a full takeover of the targeted MyBB forum.
This feature must be carefully implemented, as untrusted users could abuse it to modify the contents of the forum in undesired ways if the constraints of this feature are not strict enough. Worst case, a user could gain the ability to inject arbitrary JavaScript code into the HTML documents served by the trusted forum.
Whenever a user creates for example a private message containing such codes, the MyBB parser encodes the entire input and then utilizes a regex to find and replace all MyCodes with their respective HTML code.
Problems in such parsers can occur when the regex patterns used to find and replace e.g. MyCodes are too relaxed which could lead to nested HTML tags being rendered, as is the case with the XSS we are breaking down here.
Another, less explicit, step of the MyBB rendering process is to automatically detect URLs which were not wrapped with the [URL] MyCode and to convert them into HTML links. The following snippet shows how the $message variable is passed to the mycode_auto_url() method of the renderer class:
The $message variable in line 527 contains the already rendered HTML result of the user supplied message and thus must be carefully handled so that no HTML tags or attributes could be corrupted. The condition for this is that only URLs that are not part of an HTML tag are allowed to be converted into tags.
MyBB utilized the following regex to try to securely parse only URLs that are not part of an HTML tag (the regex was simplified by stripping away all parts that were not relevant for understanding this vulnerability):
When such an image tag is constructed, the URL that is going to form the src attribute is stripped of all whitespaces and is HTML and URL encoded. The idea was that these transformations would remove all characters that could be matched by the second alternative of the regex which is used for the auto URL encode. Therefore the second part assumes that the first transformation has already cleaned the URL.
However, both URL encoding and HTML encoding do not modify parentheses (). Thus, it was possible to craft an [img] tag such as the one shown below, which invalidates this assumption thus confusing the second regex.
In the next step, the mycode_auto_url() method matches the second URL in the image as it begins with a closing parenthesis which has not been escaped or encoded. The final HTML that is created then looks like this:
As you can see, an tag has been inserted into the existing tag. Since both of these tags contain double quotes, they corrupt each other. Browsers such as Chrome or FireFox are going to construct a final element containing an attacker controlled onerror event handler. This allows the attacker to execute arbitrary JavaScript code in the browser of a victim who reads the malicious post or private message.
The XSS vulnerability described in the previous section enables an attacker to target administrators of a MyBB forum. If the attacker succeeds in injecting malicious JavaScript code into the browser of an administrative user with an active session, he can perform arbitrary actions with admin privileges. MyBB actively prevents even administrator users from executing arbitrary PHP code on the underlying server, thus we will present an authenticated RCE vulnerability that can be reached with administrative privileges.
One of the features MyBB admins can access is the theme manager of a MyBB forum. A MyBB theme consists of a list of key-value pairs. The key is a component of the current page, for example, a welcome back message that should be displayed.
As you can see, the contents are enclosed in double quotes and the PHP variable $mybb->user['username'] is interpolated into the string. The reason that this feature does not enable remote code execution (RCE) immediately is that MyBB escapes double quotes in template values when they are stored into the database. Thus, it is impossible to break out of the double quoted string. Another PHP trick exists, that could have resulted in RCE, which is that an attacker could have modified the template and added a $ to the variable that becomes string interpolated, like the following:
MyBB themes can be imported through XML files which contain a set of theme properties such as the image directory or the version. Additionally, a list of key value pairs is read where the name correlates to the key of the theme component and the value to the contents. Here is an example:
Whenever an administrator imports such a theme, the XML is parsed and the properties of the theme are stored into the database. As it turned out, the templateset property was susceptible to a second order SQL injection.
We already touched on how the values of MyBB template components are passed to eval() calls, thus leading to arbitrary PHP code execution should an attacker be able to control the value of a theme property. The following paragraphs describe an SQL injection, which enables an attacker to inject malicious template codes into eval() calls.
At the beginning of each page load, MyBB fetches all possible template values from the database and stores them in a cache. The SQL query that fetches all template values, uses the templateset property, which is embedded unsanitized into the query string. Therefore an SQL injection vulnerability occurs:
As shown, the query simply interposes the templateset attribute. With a malicious theme, one can control this attribute and let this cache function return attacker controlled values. Here is an example of such a crafted theme with a SQL injection payload:
Through this SQL injection, it is possible to poison the template cache with attacker controlled values, which do not undergo any escaping or sanitization. As these template values that are now completely attacker controlled are passed to eval inside the double quoted string we can execute arbitrary PHP code within the $... syntax. As a result, an attacker can execute arbitrary PHP code and compromise the underlying server.
Multi-step parsers and HTML renderers can always run into the risk of corrupting their own output, sometimes with security implications. We disclosed similar vulnerabilities in the past to WordPress and Magento. It is advisable to not let regexes grow too complex in these parsers, especially when they are meant to prevent security issues. We hope that the SonarSource community can learn from these mistakes to develop secure code and we enjoyed sharing our findings as a guest blog post at SonarSource. Last but not least, we would like to thank the MyBB team for their great cooperation on resolving these issues very quickly.
MyBB, formerly MyBBoard and originally MyBulletinBoard, is a free and open-source forum software developed by the MyBB Group. It is written in PHP, supports MySQL, PostgreSQL and SQLite as database systems and, in addition, has database failover support.[3] It is available in multiple languages[4] and is licensed under the LGPL.[5] The software allows users to facilitate community driven interaction through a MyBB instance.
Founded as DevBB in 2002 by Chris Boulton from a fork of XMB, the first public release (RC1) of MyBB was published on 10 December 2003. It wasn't until two years later, on 9 December 2005, that MyBB 1.0 was released.
On 2 September 2006, with a revised and rewritten code base and over 40 new features, MyBB 1.2 was released. Support for the 1.2 series officially ended on 1 June 2009, although security updates were available until 31 December 2009.[6]
The final version of the 1.2 series, 1.2.14, was a security and maintenance update published on 17 July 2008.[7] Several security patches were available in consequent security updates for users still using the 1.2 series.
On 12 October 2008, MyBB 1.4.2 was released. This version changed MyBB's license from proprietary to GNU GPL v3.[8] The change in license was driven from a request from KDE who, in a related announcement, launched their first web-based community using MyBB as an alternative to a mailinglist.
On 2 May 2009, due to time constraints, founder Chris Boulton left the day-to-day responsibilities to Dennis Tsang (previously the Support Team Manager) who took over as Product Manager of MyBB. Matt Rogowski would later take over Dennis' responsibilities as Support Team Manager.[9]
So far, much of MyBB's development happened internally on a closed cycle. After switching to an open source license, on 19 August 2009, the MyBB Group opened development access so that users had access to the official bugtracker and read access to the subversion repository.[10]
On 3 August 2010, on the two year anniversary of MyBB 1.4's release, MyBB 1.6 was released with over 40 new features and included many tweaks, fixes and performance optimizations. The 1.6 series is distributed under the GNU LGPL v3[5] and requires at least PHP 5.1.[13]
During the 1.6 series, several senior members of the MyBB Group changed positions. On 3 October 2010, Tim Bell was promoted to Product Manager with responsibilities of running the day-to-day operations of MyBB as well as the marketing aspect of the MyBB product. Dennis Tsang took a position as Technical Advisor, helping with software design and development of MyBB.
On 5 December 2010 Ryan Gordon, the lead developer of MyBB for the past five years, resigned to pursue new challenges. As a result, Tom Moore took over Ryan's responsibilities for development and Dylan M took over management of the MyBB Merge System.
795a8134c1