Exploiting CLScript.com Classifieds Software via SQL Injection

What this paper is

This paper details a SQL injection vulnerability found in the CLScript.com Classifieds Software. The vulnerability allows an attacker to manipulate database queries by injecting malicious SQL code through a specific URL parameter. This can lead to unauthorized data retrieval or modification.

Simple technical breakdown

The CLScript.com Classifieds Software, when displaying help details, uses a URL parameter called hpId. This parameter is directly used in a database query without proper sanitization. By adding specific SQL commands to the hpId parameter, an attacker can alter the intended query. The paper demonstrates using UNION SELECT to extract information, such as the database version, from the database.

Complete code and payload walkthrough

The provided "code" is actually a demonstration of how to exploit the vulnerability via crafted URLs. There is no traditional executable code or shellcode in the traditional sense.

• Exploited Link: http://example.com/help-details.php?hpId=-38'

  • Purpose: This is the base URL that triggers the vulnerability. The hpId parameter is intended to be a numerical identifier.
  • Behavior: The single quote (') at the end of -38' is the crucial injection point. It prematurely terminates the intended SQL query, allowing for further SQL commands to be appended.
  • Mapping:
    • http://example.com/help-details.php: The vulnerable script.
    • ?hpId=-38': The parameter and the injected character.

• Live Demo: http://example.com/help-details.php?hpId=-38+union+select+all+1,version(),3,4,5,6,7--

  • Purpose: This URL demonstrates a successful SQL injection attack using the UNION SELECT technique to extract database information.
  • Behavior:
    • hpId=-38: The original intended value, likely a negative number.
    • +union+select+all: This part appends the UNION SELECT statement. UNION combines the results of two or more SELECT statements. ALL means duplicate rows are kept.
    • 1,version(),3,4,5,6,7: This is the core of the injection. The attacker is injecting a SELECT statement that returns 7 columns.
      • 1, 3, 4, 5, 6, 7: These are placeholder values. They are included to match the expected number of columns that the original, legitimate query would have returned. The exact number of columns is determined by observing the application's behavior or through trial and error.
      • version(): This is a SQL function that returns the version of the database server. This is the actual data the attacker wants to retrieve.
    • --: This is a SQL comment. It comments out the rest of the original SQL query that would have followed the injected statement, preventing syntax errors and ensuring the injected query is executed.
  • Mapping:
    • hpId=-38: Original parameter value.
    • +union+select+all: SQL command to combine query results.
    • 1,version(),3,4,5,6,7: Injected SELECT statement with placeholders and the version() function.
    • --: SQL comment to terminate the original query.

Payload Explanation:

The "payload" here is not executable code but rather a crafted URL string. The attacker's goal is to make the web application's backend database execute a modified SQL query.

1. Initial Request: The browser sends a request to http://example.com/help-details.php?hpId=-38'.
2. Vulnerable Script: The help-details.php script receives this request. It likely constructs a SQL query like SELECT * FROM help_topics WHERE hpId = -38' ....
3. Injection Point: The single quote (') breaks the intended query. The database parser now sees -38' as the end of the hpId value.
4. UNION SELECT Execution: The injected UNION SELECT 1,version(),3,4,5,6,7-- is then appended to the query. The database executes this as a separate query.
5. Result Combination: The UNION operator combines the results of the original (now malformed) query with the results of the injected SELECT query.
6. Data Leakage: The version() function's output is returned as part of the combined results, which is then displayed by the web application.

Practical details for offensive operations teams

• Required Access Level: Unauthenticated (remote). This vulnerability is exploitable via a public-facing web interface.
• Lab Preconditions:
  • A target web application running CLScript.com Classifieds Software.
  • A web server (e.g., Apache) and a database backend (e.g., MySQL, PostgreSQL) supporting the application.
  • The specific vulnerable version of the CLScript software.
  • Network connectivity to the target.
• Tooling Assumptions:
  • A web browser for manual testing.
  • A web proxy (e.g., Burp Suite, OWASP ZAP) for intercepting and modifying requests.
  • SQL injection tools (e.g., sqlmap) can automate the discovery and exploitation process, including identifying the number of columns and extracting data.
• Execution Pitfalls:
  • Incorrect Column Count: The UNION SELECT statement must match the number of columns returned by the original query. If the count is wrong, the query will fail, and the application might return an error or a blank page. This requires enumeration.
  • Database Type Differences: SQL syntax, especially for functions like version(), can vary slightly between database systems (MySQL, PostgreSQL, SQL Server, etc.). The payload might need adjustment.
  • WAF/IDS Evasion: Web Application Firewalls (WAFs) or Intrusion Detection Systems (IDS) might detect common SQL injection patterns. Evasion techniques (e.g., character encoding, alternative syntax, case variations) might be necessary.
  • URL Encoding: Spaces in URLs are often represented by + or %20. The exploit uses + for spaces. The target server's interpretation of URL encoding needs to be considered.
  • Error Handling: The application's error reporting can be a double-edged sword. Verbose errors can reveal injection success, but generic errors can mask it.
• Tradecraft Considerations:
  • Reconnaissance: Use search engine dorks (as provided: intext:"Powered by CLscript.com") to identify potential targets.
  • Passive Analysis: Examine the application's URL structure and parameters for potential injection points. Look for parameters that seem to be used for fetching specific data (IDs, names, etc.).
  • Active Testing: Start with simple tests like appending a single quote (') to parameters to see if errors occur. Then, try UNION SELECT with a low number of columns and increment until a successful response is observed.
  • Data Extraction: Once the column count is known, use functions like version(), database(), user(), or even concat() to extract specific data. For larger data sets, techniques like blind SQL injection or time-based injection might be required if direct UNION SELECT is not feasible or yields too much data.
  • Post-Exploitation: If successful, the attacker has gained insight into the database structure and potentially sensitive information. Further exploitation might involve escalating privileges, dumping tables, or attempting to gain shell access if the database user has sufficient permissions.

Where this was used and when

• Context: This vulnerability was found in the CLScript.com Classifieds Software, a web application designed for creating classified ad websites.
• Timeframe: The paper was published on April 27, 2010. This indicates the vulnerability was likely present and exploitable around that time. It's unknown if the vendor patched this specific vulnerability or if it was present in older versions.

Defensive lessons for modern teams

• Input Validation and Sanitization: This is the cornerstone of preventing SQL injection.
  • Parameterized Queries (Prepared Statements): Always use parameterized queries or prepared statements. This separates SQL code from user-supplied data, ensuring that input is treated as data, not executable code.
  • Whitelisting: If possible, validate user input against a strict list of allowed characters or patterns.
  • Escaping: Properly escape special characters in user input before it's used in SQL queries. However, this is less secure than parameterized queries and prone to errors.
• Least Privilege Principle: Ensure the database user account used by the web application has only the minimum necessary privileges. This limits the damage an attacker can do even if they successfully inject SQL.
• Web Application Firewalls (WAFs): WAFs can provide a layer of defense by detecting and blocking common SQL injection patterns. However, they are not foolproof and should be used in conjunction with secure coding practices.
• Regular Patching and Updates: Keep all web applications and their underlying components (web server, database) up to date with the latest security patches.
• Error Handling: Configure applications to log detailed errors internally but display generic error messages to users. This prevents attackers from gaining information through error messages.
• Security Audits and Code Reviews: Regularly audit code for common vulnerabilities like SQL injection.

ASCII visual (if applicable)

+-----------------+      +-----------------+      +-----------------+
| Attacker's      |----->| Web Server      |----->| Database Server |
| Browser/Tool    |      | (CLScript App)  |      |                 |
+-----------------+      +-----------------+      +-----------------+
                         |
                         |  1. Malicious URL Request
                         |     (e.g., ?hpId=-38')
                         |
                         |  2. Vulnerable Script
                         |     Constructs SQL Query
                         |     with injected data
                         |
                         |  3. Modified SQL Query
                         |     (e.g., SELECT ... WHERE hpId = -38' UNION SELECT ...)
                         |
                         |  4. Database Executes Query
                         |     and returns results
                         |
                         |  5. Application Displays
                         |     Leaked Data

Source references

• Paper ID: 12423
• Paper Title: CLScript.com Classifieds Software - SQL Injection
• Author: 41.w4r10
• Published: 2010-04-27
• Paper URL: https://www.exploit-db.com/papers/12423
• Raw Exploit URL: https://www.exploit-db.com/raw/12423

Original Exploit-DB Content (Verbatim)

# Exploit Title: CLScript.com Classifieds Software SQL Injection
Vunerability
# Date: 27-4-2010
# Author: 41.w4r10r
# Vendor Link : http://www.clscript.com/
# Version: Web Application
# Tested on: Apcahe/Unix
# CVE : [if exists]
# Dork : intext:"Powered by CLscript.com"
# Code :
---------------------------------------------------------------------------------------
############################################################################
#Greetz to all Andhra Hackers and ICW Memebers[Indian Cyber
Warriors]
#Thanks:
SaiSatish,FB1H2S,Godwin_Austin,Micr0,Mannu,Harin,Jappy,Dark_Blue,Hoodlum
#Shoutz: hg_H@x0r,r45c4l,Yash,Hackuin,unn4m3d
#Catch us at www.andhrahackers.com or www.teamicw.in
############################################################################



Exploited Link :

1) http://example.com/help-details.php?hpId=-38'



Live Demo :

1)
http://example.com/help-details.php?hpId=-38+union+select+all+1,version(),3,4,5,6,7--




#41.w4r10r mailto:41.w4r10r@andhrahackers.com