By exploitdb papers bot•February 12, 2005•
papers
MercuryBoard 1.1.1 SQL Injection Explained for Offensive Operations
MercuryBoard 1.1.1 SQL Injection Explained for Offensive Operations
What this paper is
This paper details a SQL injection vulnerability in MercuryBoard version 1.1.1, a web application. The exploit allows an attacker to extract user credentials (specifically, the password and username) by manipulating a GET request.
Simple technical breakdown
The vulnerability lies in how the application handles user input for the qu parameter in the index.php script. By injecting SQL commands into this parameter, an attacker can trick the database into returning data it shouldn't. Specifically, the exploit uses a UNION SELECT statement to combine the results of a legitimate query with a malicious query that retrieves user information from the mb_users table.
Complete code and payload walkthrough
The "code" provided is actually a URL with a crafted GET request. Let's break down the exploit string:
http://www.site.com/mercuryboard/index.php?a=post&s=reply&t=1&qu=10000%20UNION%20SELECT%20user_password,user_name%20from%20mb_users%20where%20user_group%20=%201%20limit%201/*
http://www.site.com/mercuryboard/index.php: This is the target URL, pointing to the main script of the MercuryBoard application.?a=post&s=reply&t=1: These are legitimate parameters that likely trigger the application to process a post or reply action. The specific values might be chosen to ensure the application reaches the vulnerable code path.&qu=10000%20UNION%20SELECT%20user_password,user_name%20from%20mb_users%20where%20user_group%20=%201%20limit%201/*: This is the core of the exploit.qu=10000: This is the original, likely intended value for thequparameter. The10000is probably a numerical identifier that the application uses in its database query.%20: This is the URL-encoded representation of a space character. Spaces are crucial for separating SQL keywords and identifiers.UNION: This SQL keyword allows combining the result set of two or moreSELECTstatements. The application is expected to execute its original query, and theUNIONwill append the results of the injected query.SELECT user_password,user_name: This is the malicious part of the query. It instructs the database to retrieve theuser_passwordanduser_namecolumns.from mb_users: This specifies that the data should be fetched from themb_userstable, which is a common place to store user account information.where user_group = 1: This filters the results to only include users belonging touser_groupwith an ID of1. This is likely an administrator or a privileged user group.limit 1: This restricts the output to a single row. This is often used in SQL injection to make the exploit more manageable and to avoid overwhelming the attacker with too much data, or to target a specific record./*: This is the start of a SQL comment. It effectively comments out any remaining part of the original query that the application might have appended after thequparameter's value. This prevents syntax errors and ensures only the injected query is executed.
Mapping list:
http://www.site.com/mercuryboard/index.php?a=post&s=reply&t=1&qu=-> Target script and legitimate parameters.10000-> Likely original numerical value forqu.%20-> URL-encoded space, crucial for SQL syntax.UNION SELECT user_password,user_name-> Injected SQL command to extract credentials.from mb_users-> Target table for credential extraction.where user_group = 1-> Filter to target privileged users.limit 1-> Limit results to one record./*-> SQL comment to terminate the original query.
Payload/Shellcode:
There is no executable shellcode or payload in this paper. The "payload" is the crafted URL itself, which, when sent to the vulnerable web server, causes the database to return sensitive information directly in the HTTP response.
Practical details for offensive operations teams
- Required Access Level: Unauthenticated. This exploit targets a web application accessible from the internet or internal network without requiring login credentials.
- Lab Preconditions:
- A vulnerable instance of MercuryBoard 1.1.1 must be deployed.
- The web server (e.g., Apache, IIS) and PHP interpreter must be configured to run the application.
- A database (e.g., MySQL) must be accessible by the web application and populated with user data.
- Network connectivity to the target web server is required.
- Tooling Assumptions:
- A web browser for manual testing.
- A web proxy (e.g., Burp Suite, OWASP ZAP) to intercept and modify HTTP requests.
- A command-line tool like
curlfor automated testing or scripting. - Potentially, a SQL injection specific tool could automate the discovery and exploitation, but the provided exploit is simple enough for manual execution.
- Execution Pitfalls:
- URL Encoding: Incorrect URL encoding of spaces or special characters can break the injection.
- Application Firewall/WAF: Modern Web Application Firewalls (WAFs) are likely to detect and block this type of
UNION SELECTinjection. The exploit might need obfuscation or evasion techniques if a WAF is present. - Database Schema Variations: If the
mb_userstable name or the column names (user_password,user_name) are different in the target environment, the exploit will fail. - Error Handling: The application's error handling might reveal too much or too little information. If the application suppresses database errors, it might be harder to confirm the injection's success.
user_group = 1Condition: If no users exist withuser_group = 1, or if themb_userstable is empty, the exploit will not return any data.- Output Interpretation: The extracted credentials will appear in the HTTP response body. An operator needs to parse this response to find the username and password.
Where this was used and when
This exploit was published in February 2005. At that time, web applications were less mature in their security practices, and SQL injection was a prevalent vulnerability. MercuryBoard was a forum/bulletin board software, so this vulnerability would have been relevant for attackers targeting websites running this specific software for user data theft.
Defensive lessons for modern teams
- Input Validation and Sanitization: All user-supplied input, especially that which is incorporated into database queries, must be rigorously validated and sanitized. This means ensuring input conforms to expected formats and removing or escaping potentially malicious characters.
- Parameterized Queries (Prepared Statements): This is the most effective defense. Instead of building SQL strings with user input, use parameterized queries where the SQL command and the data are sent separately to the database. The database engine then treats the data strictly as data, not as executable SQL code.
- Least Privilege Principle: Database accounts used by web applications should have only the minimum necessary privileges. They should not be able to access sensitive tables like user credential stores unless absolutely required for core functionality.
- Web Application Firewalls (WAFs): While not a silver bullet, WAFs can provide a layer of defense by detecting and blocking common attack patterns like SQL injection. However, they rely on signatures and can be bypassed.
- Regular Patching and Updates: Keeping web applications and their underlying components (web server, database, CMS) updated with the latest security patches is crucial to fix known vulnerabilities.
- Error Handling: Avoid revealing detailed database error messages to end-users, as these can provide attackers with valuable information about the database structure and vulnerabilities.
ASCII visual (if applicable)
This exploit is a direct interaction with the web server and database. An ASCII visual can illustrate the flow of the malicious request and the data exfiltration.
+-----------------+ +-----------------+ +-----------------+
| Attacker's |----->| Web Server |----->| Database Server |
| Browser/Tool | | (MercuryBoard) | | (MySQL) |
+-----------------+ +-----------------+ +-----------------+
^ |
| Malicious GET Request |
| (with UNION SELECT) |
| |
| v
| +-----------------+
| | mb_users table |
| | (user_password, |
| | user_name) |
| +-----------------+
| |
| | Returns
| | user_password,
| | user_name
| |
+---------------------------------------------------+
HTTP Response containing credentialsSource references
- PAPER ID: 814
- PAPER TITLE: MercuryBoard 1.1.1 - SQL Injection
- AUTHOR: Zeelock
- PUBLISHED: 2005-02-12
- PAPER URL: https://www.exploit-db.com/papers/814
- RAW URL: https://www.exploit-db.com/raw/814
Original Exploit-DB Content (Verbatim)
# little late posting this /str0ke
Exploit:
http://www.site.com/mercuryboard/index.php?a=post&s=reply&t=1&qu=10000%20UNION%20SELECT%20user_password,user_name%20from%20mb_users%20where%20user_group%20=%201%20limit%201/*
# milw0rm.com [2005-02-12]