With the release of MyBB 1.8.22, over one hundred vulnerabilities have been addressed in the 1.8 branch. In this post we look into what the numbers can tell us so far, and how the trends are expected to change in the future.

Since the announcement of the first stable package in 2005, over 270 security flaws were fixed in the 87 versions starting with MyBB 1.0 (some of which overlapped when two supported branches received security updates simultaneously), making 88% of all releases related to security fixes. Additional information tracked within the 1.8.x branch surfaces the most common means of reporting, types, and practical impact of 103 vulnerabilities that have been addressed five years in.

Discovery

Unlike regular bugs affecting open-source software, exploitable weaknesses are not solved publicly to prevent opportunistic offenders from attacking live installations, before appropriate patches are made available. Such high-profile issues usually attract hackers and researchers as an opportunity to prove their skills for future reference, advance their knowledge, or simply challenge themselves. As a result, software vendors are expected to have security programs in place: to assure frictionless communication, and to incentivize coordination between the reporters and maintainers to keep sites, data, and end users secure while the problems are investigated and resolved.

The 103 documented vulnerabilities that have been mitigated so far in the 19 security releases of MyBB 1.8.x were disclosed through the MyBB’s security program (74%) as well as discovered internally (19%) or by other means (detection of zero-day exploitation or ineligibility for definite attribution).

The reports were submitted by 50 people, with 40% of them having revealed 2 or more valid 1.8.x security issues, showing a lead of first-time reporters for the branch. Twenty were identified by members of the MyBB Team (at the time of reporting), while 13 were affiliated with an external group or organization and the majority of 63 emerged from independent individuals.
 
 

The greater part of security reports was submitted through the Forums — with the second preferred option being e-mail — and only a handful of parties chose to use PGP keys to secure the content. Unsurprisingly for a project with an established community, their experience with security varied from forum operators noticing unexpected behavior to professional bug hunters offering exhaustive analyses and providing feedback on planned patches.
 

Breakdown by Type

The vulnerabilities were classified using the Common Weakness Enumeration (CWE) and assigned the closest type basing on the root cause.

Almost half of studied problems related to Cross-site Scripting (XSS; 49 cases): 36 cases of Persistent XSS, 12 cases of Reflected XSS, and one case of DOM-Based XSS — involving unfiltered presentation of data that was user-supplied or fetched remotely. Other leading classes included Improper Access Control (7 cases), where users’ posts and moderation tools could have been be accessed bypassing associated permissions, and forum content disclosed without the knowledge of configured forum passwords, and SQL Injection (7 cases), with some issues described as carrying theoretical risk only, and others as very easy to exploit and cause serious damage.

Those were followed by Code Injection issues (6 cases), where malicious PHP code may have been executed during installation or through the Admin Control Panel; Information Exposure (6 cases), where sensitive details could have been accessible to third party visitors; Cross-Site Request Forgery (CSRF; 5 cases), allowing threat actors to perform actions originally requiring authorization with the use of seemingly benign interaction of victim users; Path Traversal (4 cases) allowing one to read, write, or delete files in unexpected locations; and Improper Input Validation (3 cases) related to usernames, Private Message export feature, and MyCode parsing.

There were two cases each for: Small Space of Random Values — tied to security tokens, Server-Side Request Forgery (SSRF) — with MyBB unexpectedly sending requests to its own server revealing details about its network and services, Insufficient Verification of Data Authenticity — linked to verification of e-mail addresses, and Deserialization of Untrusted Data, where reliance on PHP’s unserialize() function proved to be dangerously problematic.

The remaining flaws patched in MyBB 1.8.x — one case each — were categorized as PHP Remote File Inclusion (tricking the software into executing external files), Open Redirect (showing a trusted forum URL before an external website is displayed, which phishing attacks may build upon), PHP External Variable Modification (changing internal behavior on misconfigured servers), Encoding Error (circumventing data escaping through discrepancies in multibyte support), Improper Restriction of Rendered UI Layers or Frames (clickjacking affecting the Admin CP), Information Exposure Through Directory Listing (displaying sensitive file names in given directory), Improper Authentication (skipping the verification of password reset codes), and Incorrect Comparison (false positives when using PHP’s weak comparison operator == to check access codes).
 

The most common modules to be patched are the Admin CP, affected by Cross-site Scripting issues and weak validation of input submitted by forum administrators, on the (currently) blurry line between a bug and a feature; and the Regular Expression-based MyCode parser, where 8 XSS- and validation-related vulnerabilities have been found.

The statistics specific to MyBB are consistent with more broad observations from web software, having XSS, access control issues, and injection the most common categories of vulnerabilities to be reported.
 

Practical Impact

Prior to release, vulnerabilities are assessed by attack complexity, required permissions and potential impact, placing them on a simple “risk” scale. This resulted in a grand total of 12 High Risk (12%), 33 Medium Risk (32%), and 58 Low Risk (56%) problems. Even with the Risk factors present, the vulnerabilities often depend on the individual server environment, forum configuration, and enabled features: Low Risk vulnerabilities may be exploited to complete more complex intrusions and some High Risk ones may be not applicable to certain forums at all.

To help understand the practical exposure of MyBB installations to attacks, we applied a None / Low / High scale of Privileges Required to trigger each vulnerability (a part of the universal CVSS scoring system). Security holes that required administrative permissions for successful exploitation were classified as requiring High Privileges (most of which were limited to the Admin CP, rather than the front-end section), and the ones relying on moderator and user permissions (usually limited to Mod CP, User CP, and other account-related functionality) as Low. Affected components that may have been available to guest users (including the install & upgrade script, sign up, login, session controllers, or the MyCode parser), or those technically triggered by users with permissions, but causing leaks of sensitive information to uncertain third parties, were assigned None. The last turned out to be most common, followed in frequency by High and Low privileges.
 
 

A rundown of recently remediated weaknesses suggest that MyBB forums with a common configuration, running on version 1.8.20 or older, can be breached with minimal interaction of unsuspecting forum administrators, through the exploitation of an XSS & Code Injection weakness (the reporter has published a more detailed analysis of this chain). Moreover, boards running 1.8.18 or older may be damaged with no interaction whatsoever by attackers escalating permissions of their own accounts to the administrator user group, as a result of an especially fatal SQL Injection vulnerability within the sign-up process. These points of peak exposure underline the importance of keeping live MyBB forums easy to update (e.g. by avoiding core file modifications, in favor of plugin hooks) and performing actual upgrades as soon as they’re released.
 

Pest Control

Addressing vulnerabilities in “patch” releases is primarily limited to correcting faulty local code fragments, and preventing similar mistakes from being introduced again. Some global changes and features, however, allow developers to tackle vulnerabilities at scale. In the case of MyBB 1.9 and later, there are four significant changes on the horizon:

• Twig templating, requiring an explicit declaration to parse HTML in displayed content,
• Non-RegEx MyCode (BBCode) parser, for clear validation and control of nested tags to limit XSS issues,
• strict Content Security Policy by separation of inline styles and scripts, mitigating XSS attack attempts,
• parametrized SQL statements, removing the possibility of changing the meaning of database queries and securing against SQL Injection attempts.

Swapping the template engine and the parser allows to remove potentially vulnerable modules altogether, and is expected to reduce vulnerabilities application-wide. Converting inline elements and SQL statements will require more time through a continuous effort as MyBB’s code is (re)written during regular development.

Being a web-based application, MyBB’s security also increasingly relies on mechanisms implemented in web browsers. New cookie flags help with problems related to client-side attacks (XSS, CSRF) and unencrypted transmission; new HTTP headers allow to limit referrer URL leaks; and the mentioned Content Security Policy and checksums of external files will let forum administrators control what code can be executed and to what extent, depending on used features. Widely adopted standards will continue to be added to MyBB, further reducing the attack surface created by client-bound vulnerabilities, which in 1.8.x account for 54% of issues in question.
 

Do Your Part

Security improvements under consideration are not just limited to the internal workings of MyBB. We expect future MyBB versions to require less technical knowledge and experience to manage boards effectively and securely — this will involve automating certain tasks and checks, making administrators aware of suspected problems and misconfigurations, and offering inbuilt actions in place of running code or SQL queries manually.

If you administrate MyBB 1.8.x boards, make sure to review the new MyBB Security Guide with best practices for protecting your website, in addition to keeping MyBB and its extensions up to date. If you think some security-related features could be improved, share your ideas with the developers and the Community in the Suggestions and Feedback forum.

To learn more about how we work with researchers, visit the Security Research page and follow @mybbsecurity to stay up to date with news on keeping MyBB forums secure.