MyBB Global Variable overwrite exploitation

By Taylor Christian Newsome You can contact me via email Frugaze@gmail.com or Via linkedin.com/in/clumsy/

Today we are going to show you how the path on a example.mybbforum.com can be exploited through global.php where in_mybb is not defined on every forum this is how you can exploit it and fix it. P.S I got GPT to explain this for me and also included the old vulner for it as well

Explaining how the global.php file in MyBB could potentially be exploited through global variable overwrite leading to an SQL injection, it's essential to first understand how MyBB handles global variables and imports external input.

Background Understanding

MyBB uses a file called global.php which initializes various components and configuration settings that are required globally throughout the application. This file typically includes essential setup procedures, such as database connection settings, fetching configuration from the database, and setting up user sessions.

A key security aspect in PHP applications, like MyBB, is the handling of external variables (from GET, POST, or COOKIE data). If global.php processes external inputs improperly or lets external inputs overwrite global variables without proper validation, it might expose the application to various vulnerabilities, including SQL injections.

The Potential Vulnerability
Global Variable Overwrite: If the global.php file uses external input (such as GET or POST data) to set global variables without sanitizing them, an attacker might be able to overwrite these variables to manipulate SQL queries executed later in the script or other scripts included after the variable initialization.
Inadequate Checking of IN_MYBB: The IN_MYBB constant is often defined in MyBB scripts to ensure that the PHP files are being executed in the proper context (i.e., within the MyBB environment). If IN_MYBB is not properly defined and checked before including global.php, an attacker could potentially include global.php directly in their malicious scripts, using its functionality to initialize the application environment in a way that benefits the attacker.
Example of an Attack Vector
Assume a hypothetical situation where global.php includes database connection settings and uses a global variable $db_prefix to define table prefixes in SQL queries. Suppose this variable is initially set from a configuration file but can be overwritten if a specific GET parameter is passed.

Attack Scenario:

An attacker crafts a URL that includes the parameter db_prefix=sometable%20WHERE%201=1%20 — %20. This parameter causes $db_prefix to be overwritten.
The attacker accesses a MyBB script that constructs a SQL query using the $db_prefix variable. For example

$query = “SELECT * FROM {$db_prefix}users WHERE userid = 1”;

Given the attacker’s input, this becomes

SELECT * FROM sometable WHERE 1=1 — users WHERE userid = 1

This SQL effectively comments out the remainder of the original SQL query, changing the logic and potentially exposing all data from a different, unintended table.
Defensive Measures:

Secure Configuration: Ensure that global.php does not blindly accept external inputs for critical settings. Configuration variables like $db_prefix should only be set from secure, internal sources.
Constant Verification: Always check for IN_MYBB or similar constants to ensure that global.php is not directly included in a way that bypasses the intended script flow.
Use Prepared Statements: Use prepared statements with parameterized queries to prevent SQL injection, rather than constructing queries directly with variables.
Sanitization and Validation: Properly sanitize and validate all incoming data, even if it’s indirectly affecting the application flow or database queries.

To mitigate the risks identified in the scenario I previously described, where an attacker could exploit the global.php file in a MyBB installation by manipulating global variables, we’ll need to implement some strategic code enhancements. The following fixes will focus on securing the file against unauthorized access and ensuring that external inputs do not compromise application integrity.

1. Protecting global.php from Direct Access
First, it’s essential to ensure that no external script or user can directly access global.php. We achieve this by defining a constant in all entry scripts and checking this constant in global.php.

In every entry script (e.g., index.php, forumdisplay.php, etc.), you should have

define(‘IN_MYBB’, true);

Then, at the very beginning of global.php, add

if (!defined(‘IN_MYBB’)) {
exit(‘This file cannot be accessed directly.’);
}

This ensures that global.php can only be executed as part of a MyBB environment.

2. Securing Global Variable Assignments
Next, we ensure that critical global variables like $db_prefix cannot be overwritten by user input. This can be achieved by strictly controlling how such variables are assigned and ensuring they do not rely on unsanitized external input.

Old vulnerable code snippet in global.php

// Hypothetical vulnerable setup
$db_prefix = $_GET[‘db_prefix’] ?? $config[‘database’][‘prefix’];

Revised secure code snippet

// Secure setup
$db_prefix = $config[‘database’][‘prefix’];

Here, $db_prefix is strictly set from the configuration settings and not from any external input.

3. Using Prepared Statements
To prevent SQL injection vulnerabilities in SQL queries, use prepared statements with parameterized queries instead of concatenating variables directly into SQL strings.

Before (vulnerable)

$query = “SELECT * FROM {$db_prefix}users WHERE userid = “ . intval($_GET[‘userid’]);
$result = $db->query($query);

After (secure)

$userid = intval($_GET[‘userid’]);
$query = “SELECT * FROM {$db_prefix}users WHERE userid = ?”;
$preparedQuery = $db->prepare($query);
$result = $preparedQuery->execute([$userid]);

Note: Ensure your database abstraction layer supports prepared statements. MyBB uses a class for database operations, so the exact method names (prepare, execute) might differ based on the version or the specific database class methods available.

4. General Improvements and Best Practices
Input Sanitization and Validation: Always sanitize and validate all incoming data, especially data that will interact with the database or affect the control flow of the application.
Error Handling: Implement proper error handling that does not expose sensitive information but still logs errors for administrative review.
Regular Updates: Keep MyBB and all associated plugins up-to-date to ensure that any security patches and improvements are applied.