fipsGallery 1.5 'index1.asp' SQL Injection Explained for Offensive Operations

What this paper is

This paper describes a SQL injection vulnerability in fipsGallery version 1.5. Specifically, it targets the index1.asp file. The vulnerability allows an attacker to inject malicious SQL code into the which parameter, potentially leading to unauthorized access to sensitive data like usernames and passwords from the admin table.

Simple technical breakdown

The web application fipsGallery uses an Active Server Pages (ASP) file named index1.asp. This file handles requests based on the what parameter. When what is set to artists, the application expects a value for the which parameter. The vulnerability lies in how the application processes the which parameter: it directly incorporates the user-supplied input into an SQL query without proper sanitization. This allows an attacker to manipulate the query by appending SQL commands. The example provided demonstrates using a UNION SELECT statement to extract username and password from an admin table.

Complete code and payload walkthrough

The provided exploit is not a full code exploit in the traditional sense of a compiled program. Instead, it's a description of a web vulnerability and a proof-of-concept URL. The "code" is the crafted URL itself, which leverages the application's flawed input handling.

Here's a breakdown of the exploit URL structure and its components:

• http://[target]/[path]//index1.asp: This is the base URL pointing to the vulnerable ASP script.

  • [target]: Placeholder for the IP address or hostname of the vulnerable server.
  • [path]: Placeholder for the directory where fipsGallery is installed on the web server.
  • index1.asp: The specific ASP file containing the vulnerability.

• ?what=artists: This is a GET parameter.

  • what: The name of the parameter.
  • artists: The value assigned to the what parameter. This likely tells index1.asp to display artist-related information.

• &which=[SQL]: This is the critical parameter where the SQL injection occurs.

  • which: The name of the parameter.
  • [SQL]: This is a placeholder for the malicious SQL code.

Example Payload Breakdown:

//index1.asp?what=artists&which=-1%20union%20select%200,username,password%20from%20admin

• which=-1: This part of the which parameter likely represents a valid ID or index that would normally be used to fetch a single artist. By providing -1, the attacker aims to ensure that no legitimate record is returned by the original query. This is a common technique to make the UNION SELECT statement's results more prominent, as the original query will return no rows, leaving only the injected query's results.

• %20: This is the URL-encoded representation of a space character. Spaces are crucial in SQL syntax.

• union: This is the SQL keyword used to combine the result sets of two or more SELECT statements.

• select: This is the SQL keyword used to query data from a database.

• 0,username,password: These are the columns being selected in the injected SELECT statement.

  • 0: This is a placeholder value. In a UNION SELECT statement, the number of columns and their data types must match the original SELECT statement. The attacker doesn't know the exact structure of the original query, so they use a placeholder like 0 for a numeric column.
  • username: This is the name of the column in the admin table that likely stores usernames.
  • password: This is the name of the column in the admin table that likely stores passwords (or password hashes).

• from admin: This specifies the table from which to retrieve the username and password columns. The attacker assumes a table named admin exists and contains these sensitive details.

Mapping of code fragment/block -> practical purpose:

• http://[target]/[path]//index1.asp?what=artists&which= -> Base URL and vulnerable script entry point.
• what=artists -> Parameter to trigger specific application logic.
• which= -> Parameter susceptible to SQL injection.
• -1 -> Placeholder value for the original query to return no results.
• %20 -> URL-encoded space, essential for SQL syntax.
• union select -> SQL keywords to combine query results and extract data.
• 0,username,password -> Injected columns to retrieve data (username and password).
• from admin -> Target table containing administrative credentials.

Practical details for offensive operations teams

• Required Access Level: Unauthenticated access to the web application. The vulnerability is exposed via a public-facing URL.
• Lab Preconditions:
  • A target web server running IIS (or a compatible ASP host) with fipsGallery v1.5 installed.
  • A database backend (likely Microsoft SQL Server, given the ASP context) accessible by the web server.
  • The admin table must exist and contain username and password columns (or similar).
  • The index1.asp script must be configured to process the what and which parameters in a way that leads to SQL injection.
• Tooling Assumptions:
  • A web browser for manual testing or reconnaissance.
  • A web proxy (e.g., Burp Suite, OWASP ZAP) to intercept and modify HTTP requests.
  • An SQL injection scanner (though manual crafting is often more effective for specific vulnerabilities like this).
  • A tool to decode URL-encoded strings (most proxies have this built-in).
• Execution Pitfalls:
  • Incorrect [target] or [path]: The exploit will fail if the target URL or path is wrong.
  • Database Schema Mismatch: If the admin table doesn't exist, or if the column names for username/password are different (e.g., user, pass, admin_user, admin_pass), the UNION SELECT will fail.
  • Column Count Mismatch: The number of columns in the UNION SELECT must match the number of columns the original query would have returned. If the original query selects 3 columns, the injected query must also select 3. The 0,username,password assumes the original query returns 3 columns. If it returns 2 or 4, this specific injection will fail.
  • Web Application Firewall (WAF): Modern WAFs might detect and block the UNION SELECT syntax or encoded spaces.
  • Database Error Handling: If the application displays detailed SQL errors to the user, this can be helpful for debugging. If it suppresses errors, it makes exploitation harder.
  • URL Encoding: Incorrect URL encoding of special characters can lead to syntax errors.
• Tradecraft Considerations:
  • Reconnaissance: Identify the target application version and specific vulnerable files/parameters.
  • Enumeration: If the initial UNION SELECT fails, try enumerating the number of columns in the original query by using ORDER BY clauses with increasing numbers (e.g., which=-1 ORDER BY 1, which=-1 ORDER BY 2, etc.) until an error occurs.
  • Data Exfiltration: Once credentials are found, consider how to exfiltrate them discreetly. This might involve embedding them in a subsequent request or using a more advanced payload if available.
  • Post-Exploitation: Access to admin credentials could lead to further compromise of the web application or the underlying server.

Where this was used and when

• Context: This vulnerability was discovered and published in 2006. It targets a specific web application, fipsGallery, which was likely used by individuals or small organizations for displaying galleries.
• Approximate Years/Dates: Published on November 22, 2006. Exploitation would have been relevant around this period and shortly thereafter, until the vulnerability was patched or the application was updated.

Defensive lessons for modern teams

• Input Validation and Sanitization: This is the most critical lesson. Never trust user input. All data coming from the client (URL parameters, form fields, cookies, headers) must be validated and sanitized before being used in database queries. For SQL, this means:
  • Using parameterized queries (prepared statements) with bound parameters. This is the gold standard.
  • Escaping special characters that have meaning in SQL (e.g., single quotes, double quotes, semicolons, hyphens).
  • Whitelisting allowed characters and formats for input.
• Principle of Least Privilege: The database user account used by the web application should have only the minimum necessary permissions. It should not have rights to drop tables, create users, or access sensitive system tables unless absolutely required.
• Error Handling: Configure web servers and applications to suppress detailed database error messages from being displayed to end-users. Log these errors server-side for debugging.
• Web Application Firewalls (WAFs): While not a primary defense, WAFs can provide an additional layer of protection by detecting and blocking common attack patterns like SQL injection. However, they should not be relied upon as the sole defense.
• Regular Patching and Updates: Keep all web applications, frameworks, and server software up-to-date with the latest security patches.
• Code Reviews and Security Testing: Regularly review application code for security flaws and conduct penetration testing to identify vulnerabilities before attackers do.

ASCII visual (if applicable)

This vulnerability is a direct interaction between a user's browser and a web server. An ASCII diagram can illustrate the flow of the malicious request.

+-----------------+      +-----------------+      +-----------------+
| Attacker's      |----->| Web Server      |----->| Database Server |
| Browser         |      | (fipsGallery)   |      | (SQL Server)    |
+-----------------+      +-----------------+      +-----------------+
        ^                      |
        |                      | Malicious SQL Injection
        |                      | (via 'which' parameter)
        |                      v
        |              +-----------------+
        |              | index1.asp      |
        |              | (Vulnerable)    |
        |              +-----------------+
        |                      |
        |                      | Injects 'UNION SELECT'
        |                      | into original query
        |                      v
        |              +-----------------+
        |              | Database Query  |
        |              | (Modified)      |
        |              +-----------------+
        |                      |
        |                      | Returns Admin Credentials
        |                      v
        |              +-----------------+
        |              | Database Result |
        |              | (Credentials)   |
        |              +-----------------+
        |                      |
        |                      | Sends results back
        |                      v
        +----------------------| (Response to Browser)

Source references

• Paper Title: fipsGallery 1.5 - 'index1.asp' SQL Injection
• Author: ajann
• Published: 2006-11-22
• Exploit-DB Paper URL: https://www.exploit-db.com/papers/2829
• Original Source Snippet:

  *******************************************************************************
  # Title   :  fipsGallery <= v1.5 (index1.asp) Remote SQL Injection Vulnerability
  # Author  :   ajann
  # Contact :   :(
  # $$$     :   29 Euro
  
  
  *******************************************************************************
  
  ###http://[target]/[path]//index1.asp?what=artists&which=[SQL]
  
  Example:
  
  //index1.asp?what=artists&which=-1%20union%20select%200,username,password%20from%20admin
  
  See you Admin Hash..
  
  """""""""""""""""""""
  # ajann,Turkey
  # ...
  
  # Im not Hacker!
  
  # milw0rm.com [2006-11-22]

Original Exploit-DB Content (Verbatim)

*******************************************************************************
# Title   :  fipsGallery <= v1.5 (index1.asp) Remote SQL Injection Vulnerability
# Author  :   ajann
# Contact :   :(
# $$$     :   29 Euro


*******************************************************************************

###http://[target]/[path]//index1.asp?what=artists&which=[SQL]

Example:

//index1.asp?what=artists&which=-1%20union%20select%200,username,password%20from%20admin

See you Admin Hash..

"""""""""""""""""""""
# ajann,Turkey
# ...

# Im not Hacker!

# milw0rm.com [2006-11-22]