Uiga Fan Club - 'index.php' SQL Injection Explained

What this paper is

This paper details a SQL injection vulnerability found in the index.php file of the "Uigafanclub" PHP script. The vulnerability allows an attacker to manipulate database queries by injecting malicious SQL code into the id parameter. This can lead to the disclosure of sensitive information, such as administrator usernames and passwords.

Simple technical breakdown

The index.php script, when accessed with the view=photos and id= parameters, likely queries a database to fetch photo information based on the provided id. The vulnerability arises because the script doesn't properly sanitize the input from the id parameter before using it in a SQL query.

An attacker can exploit this by appending SQL commands to the id value. In this case, the attacker uses a UNION SELECT statement. This statement allows them to combine the results of their injected query with the results of the original, legitimate query. The injected query specifically targets the admin table and attempts to extract the admin_name and admin_password columns, concatenating them with a colon (:) as a separator. The -- at the end comments out the rest of the original SQL query, preventing syntax errors.

Complete code and payload walkthrough

The provided paper does not contain any executable code or shellcode in the traditional sense. Instead, it presents a URL pattern and a specific SQL injection payload.

URL Pattern:
www.site.com/Uigafanclub/index.php?view=photos&id=

• www.site.com/Uigafanclub/index.php: This is the target script.
• ?view=photos: This is a GET parameter likely indicating the action to be performed (displaying photos).
• &id=: This is another GET parameter, which is the vulnerable input point. The script is expected to use the value provided after id= to query the database.

Exploitable URL and Payload:
www.site.com/Uigafanclub/index.php?view=photos&id=-9999+Union+Select+1,2,concat(admin_name,0x3a,admin_password),4,5+from+admin--

Let's break down the injected part:

• -9999: This is a placeholder for an id that likely doesn't exist in the database. This is a common technique to ensure the original query returns no results, making the UNION SELECT results more prominent.
• +: In URLs, + is often used to represent a space. So, this is equivalent to (space).
• Union: This is the SQL keyword to combine the result-set of two or more SELECT statements.
• Select: This is the SQL keyword to retrieve data from a database.
• 1,2,concat(admin_name,0x3a,admin_password),4,5: This is the core of the injected SELECT statement.
  • 1,2,4,5: These are placeholder columns. The number of columns in the UNION SELECT statement must match the number of columns in the original SELECT statement that the script is executing. The attacker is guessing that the original query selects 5 columns.
  • concat(admin_name,0x3a,admin_password): This is a SQL function that concatenates (joins) strings.
    • admin_name: This is likely the name of the column in the admin table that stores administrator usernames.
    • 0x3a: This is the hexadecimal representation of the ASCII character :. It's used as a separator between the username and password.
    • admin_password: This is likely the name of the column in the admin table that stores administrator passwords.
• from admin: This specifies that the data should be retrieved from a table named admin.
• --: This is a SQL comment. It tells the database to ignore any characters that follow it in the query. This is crucial for commenting out the rest of the original SQL query, which would otherwise cause a syntax error.

Mapping:

• www.site.com/Uigafanclub/index.php?view=photos&id= -> Target script and vulnerable parameter.
• -9999 -> Non-existent ID to ensure original query yields no results.
• + -> URL-encoded space.
• Union Select -> SQL statement to combine query results.
• 1,2,4,5 -> Placeholder columns to match original query's column count.
• concat(admin_name,0x3a,admin_password) -> Injected SQL to extract and format admin credentials.
• from admin -> Target table containing administrator credentials.
• -- -> SQL comment to terminate the original query.

Practical details for offensive operations teams

• Required Access Level: Network access to the target web server. No elevated privileges on the server itself are initially required, as this is a web application vulnerability.
• Lab Preconditions:
  • A local or remote lab environment with a vulnerable PHP web application that mimics the structure of "Uigafanclub."
  • A database backend (e.g., MySQL) configured for the web application.
  • Knowledge of the target application's URL structure and common parameter names.
  • A way to interact with the web application (e.g., a web browser, Burp Suite, curl).
• Tooling Assumptions:
  • Web Browser: For initial reconnaissance and manual testing.
  • Proxy Tool (e.g., Burp Suite, OWASP ZAP): Essential for intercepting, modifying, and replaying HTTP requests. This allows for precise manipulation of the id parameter.
  • SQL Injection Tools (e.g., sqlmap): While the paper provides a manual payload, automated tools can significantly speed up discovery and exploitation, especially for complex injection scenarios or when the exact column names/counts are unknown.
  • Database Client: To verify extracted credentials if direct access is gained or to understand the database schema.
• Execution Pitfalls:
  • Incorrect Column Count: The UNION SELECT statement requires the number of columns to match the original query. If the attacker guesses incorrectly, the query will fail. This can be discovered through trial and error or by observing error messages.
  • Database Specific Syntax: SQL syntax can vary slightly between database systems (e.g., MySQL, PostgreSQL, SQL Server). The concat function and hexadecimal encoding (0x3a) are common but might need adjustment.
  • WAF/IDS Evasion: Web Application Firewalls (WAFs) or Intrusion Detection Systems (IDS) might detect the malicious SQL patterns. URL encoding, using different SQL functions, or breaking up the payload can be necessary.
  • Output Encoding: The extracted data might be further processed or encoded by the web application before being displayed, making it appear garbled.
  • Authentication/Authorization Bypass: This specific exploit focuses on data exfiltration. If the goal is to gain administrative access, further steps would be needed after obtaining credentials.
  • Error-Based vs. Blind SQLi: This exploit relies on error-based or union-based SQL injection, where results are directly returned. If the application suppresses errors or doesn't display query results directly, blind SQL injection techniques would be required, which are more complex.
• Tradecraft Considerations:
  • Reconnaissance: Understand the application's functionality, identify potential input vectors, and map out the URL structure.
  • Payload Crafting: Develop and test payloads incrementally. Start with simple probes to confirm SQL injection is possible, then move to data extraction.
  • Stealth: Avoid overly aggressive scanning or payloads that generate excessive noise, which could trigger alerts. Use URL encoding and obfuscation techniques if necessary.
  • Post-Exploitation: Once credentials are exfiltrated, plan for how to use them to achieve the engagement's objectives (e.g., gaining access to the admin panel).
  • Documentation: Meticulously record all successful and failed attempts, payloads used, and observed results for reporting.

Where this was used and when

• Context: This vulnerability was found in a PHP web application named "Uigafanclub," likely a fan club website or similar community platform.
• Timeframe: The paper was published on February 28, 2010. This indicates the vulnerability was discovered and reported around that time. Such vulnerabilities were common in web applications developed with less stringent security practices during that era.

Defensive lessons for modern teams

• Input Validation and Sanitization: This is the cornerstone of preventing SQL injection. All user-supplied input, especially data used in database queries, must be rigorously validated and sanitized.
  • Parameterized Queries/Prepared Statements: Use these exclusively. They separate SQL code from data, preventing malicious input from being interpreted as commands.
  • Whitelisting: Only allow known-good characters or patterns for input.
  • Escaping: Properly escape special characters that have meaning in SQL.
• Least Privilege: Ensure the database user account used by the web application has only the minimum necessary permissions. It should not have access to sensitive tables like admin unless absolutely required for its function.
• Web Application Firewalls (WAFs): While not a sole solution, WAFs can provide a layer of defense by detecting and blocking common SQL injection patterns. However, they can be bypassed.
• Regular Security Audits and Code Reviews: Proactively identify vulnerabilities through static and dynamic analysis of the codebase.
• Error Handling: Configure web applications to display generic error messages to users instead of detailed database errors, which can leak information to attackers.
• Keep Software Updated: Ensure the web server, database, and any frameworks or libraries used are kept up-to-date with security patches.

ASCII visual (if applicable)

This vulnerability is best represented by a flow diagram showing how user input bypasses security controls and reaches the database.

+-----------------+      +-----------------------+      +-----------------+
| User Input      |----->| Web Application       |----->| Database Query  |
| (id parameter)  |      | (index.php)           |      | (SQL Injection) |
+-----------------+      +----------+------------+      +--------+--------+
                                    |
                                    | (Vulnerable: No Sanitization)
                                    v
                           +-----------------+
                           | Malicious SQL   |
                           | injected into   |
                           | query           |
                           +-----------------+

Source references

• PAPER ID: 11600
• PAPER TITLE: Uiga Fan Club - 'index.php' SQL Injection
• AUTHOR: Easy Laster
• PUBLISHED: 2010-02-28
• PAPER URL: https://www.exploit-db.com/papers/11600
• RAW URL: https://www.exploit-db.com/raw/11600

Original Exploit-DB Content (Verbatim)

----------------------------Information------------------------------------------------
+Name : Uigafanclub index.php SQL Injection
+Autor : Easy Laster
+Date   : 28.02.2010
+Script  : Uigafanclub
+Language :PHP
+Discovered by Easy Laster
+Security Group 4004-Security-Project
+Greetz to Team-Internet ,Underground Agents
+And all Friends of Cyberlive : R!p,Eddy14,Silent Vapor,Nolok,
Kiba,-tmh-,Dr Chaos,HANN!BAL,Kabel,-=Player=-,Lidloses_Auge,
N00bor,Damian,novaca!ne.

---------------------------------------------------------------------------------------
                                                                                     
 ___ ___ ___ ___                         _ _           _____           _         _   
| | |   |   | | |___ ___ ___ ___ _ _ ___|_| |_ _ _ ___|  _  |___ ___  |_|___ ___| |_ 
|_  | | | | |_  |___|_ -| -_|  _| | |  _| |  _| | |___|   __|  _| . | | | -_|  _|  _|
  |_|___|___| |_|   |___|___|___|___|_| |_|_| |_  |   |__|  |_| |___|_| |___|___|_|  
                                              |___|                 |___|            


----------------------------------------------------------------------------------------
+Vulnerability : www.site.com/Uigafanclub/index.php?view=photos&id=
+Exploitable   : www.site.com/Uigafanclub/index.php?view=photos&id=-9999+
Union+Select+1,2,concat(admin_name,0x3a,admin_password),4,5+from+admin--
-----------------------------------------------------------------------------------------