Home » Security Bloggers Network » MyBB <= 1.8.20: From Stored XSS to RCE

MyBB <= 1.8.20: From Stored XSS to RCE

by Simon Scannell on June 10, 2019

Impact

We discovered a Stored XSS vulnerability that occured due to a parsing error in posts and private messages in MyBB 1.8.20 and prior versions, as well as an authenticated Remote Code Execution vulnerability that can be exploited by administrators of a forum.

An attacker merely needs a user account on a target forum to send an admin a private message containing malicious JavaScript code, which exploits the RCE vulnerability. This leads to a full remote take over of a target board by an attacker, as soon as as an administrator who is at the same time authenticated in the backend context opens the malicious PM. No further user interaction is required.

This gives an attacker full access to all user accounts, private threads and messages stored in the board’s database.

Technical Analysis

In the following, we analyze the security flaws that were partially detected with Static Code Analysis.

Stored XSS through ";1391 1392 $parsed_url = @parse_url(urldecode($url));1393 1394 // [...]
The fact that the video URL is urldecoded allows to bypass the regex protection and inject a `[url]` bbcode as depicted above by URL encoding it. This then leads to an `onload` event handler being injected into the `<iframe>` tag. This event handler triggers as soon as the page within the iframe is loaded, thus no user interaction is required to trigger malicious JavaScript code.

RCE in Admin panel via File Write

Administrators of a MyBB forum can manage stylesheets of the active theme of their installation within the Admin Panel. They can also create new stylesheet files on the server and choose the filename.

An obvious File Write vulnerability would occur if an attacker in the role of an administrator account could simply create a new stylesheet file and call it for example shell.php. However, a quick investigation of the source code behind this functionality revealed that only the .css file extension was allowed:

admin/inc/functions_themes.php

263    foreach($theme['stylesheets']['stylesheet'] as $stylesheet) {264        if(substr($stylesheet['attributes']['name'], -4) != ".css"){265           continue;

What captured our attention was what happened after the extension had been checked. Instead of simply creating the stylesheet file in the file system, MyBB first stores the name of the stylesheet file, as well as the contents in the MySQL database powering the board. When we looked at the mybb_themestylesheets table and how it was structured, we noticed something interesting: the name column which stores the filename of a newly imported stylesheet is defined as a varchar column with a maximum of 30 characters.

Table definition of mybb_themestylesheets

1    MariaDB [mybb]> DESC mybb_themestylesheets;2    +--------------+----------------------+------+-----+---------+----------------+3    | Field        | Type                 | Null | Key | Default | Extra          |4    +--------------+----------------------+------+-----+---------+----------------+5    | sid          | int(10) unsigned     | NO   | PRI | NULL    | auto_increment | 6    | name         | varchar(30)          | NO   |     |         |                |7      [...]8    | stylesheet   | longtext             | NO   |     | NULL    |                |9      [...]10   +--------------+----------------------+------+-----+---------+----------------+

We then noticed that the length of a stylesheet filename is not checked when imported through an XML file, resulting in attackers being able to trick MyBB into inserting a filename with more than the allowed 30 characters. MySQL’s default behavior on many systems is to then truncate the filename to 30 characters.

An attacker could abuse this behavior by setting a filename to for example aaaaaaaaaaaaaaaaaaaaaaaaaa.php.css. This filename is 34 characters long. Since it ends with the .css extension, it passes the security checks of MyBB. However, when that string is then inserted into the database, it is truncated to 30 characters and only aaaaaaaaaaaaaaaaaaaaaaaaaa.php remains stored in the database.

An attacker can then use the admin panel to generate the newly imported stylesheet files and write them to the file system. This would create a PHP shell within the cache directory.

Timeline

Date	What
2019/04/29	Reported multiple vulnerabilities privately to the MyBB team.
2019/04/29	MyBB acknowledges the vulnerabilies.
2019/06/10	MyBB releases version 1.8.21 which includes patches for the vulnerabilities.

Summary

This blog post detailed an exploit chain that can be abused to take over any forum running MyBB prior to version 1.8.21. An attacker could have abused the XSS flaw to take over any forum account on a target forum or to directly try to create a shell on the target system via the File Write vulnerability by sending an administrator a private message on a target forum that contains malicious JavaScript code. Although MyBB has two seperate sessions for the front end and the backend session and an administrator might not always have an active backend session while reading the private message, an attacker can try multiple times, since no user interaction other than the targeted administrator opening the malicious private message is required.