KLINK SQL Injection Exploit Explained

What this paper is

This paper describes a SQL injection vulnerability found in a web application called KLINK, developed by contacto.com. The vulnerability allows an attacker to execute arbitrary SQL commands on the database. This can lead to data theft, modification, or deletion, compromising the integrity and confidentiality of the information stored.

Simple technical breakdown

The core of the vulnerability lies in how the web application handles user input. Specifically, it takes a parameter named txtCodiInfo from the URL and uses it directly in a SQL query without proper sanitization.

When an attacker provides a specially crafted string as the value for txtCodiInfo, they can break out of the intended SQL query and inject their own SQL commands. This is often achieved by using single quotes (') to close off the original query and then adding new SQL logic.

The paper demonstrates this by showing how to append UNION SELECT statements. This technique allows the attacker to retrieve data from other tables or system information, even if it's not directly related to the original query's purpose.

Complete code and payload walkthrough

The provided "code" is not executable code in the traditional sense (like a compiled program). Instead, it consists of URL examples and a suggested code snippet for a fix.

Here's a breakdown of the meaningful parts:

• Exploit Title, Date, Author, Software Developed by, Contact, Dork:

  • Purpose: Metadata providing context about the vulnerability.
  • Details:
    • Exploit Title: "KLINK Sql Injection Vulnerability" - Clearly states the vulnerability type.
    • Date: "2010-12-31" - When the exploit was documented.
    • Author: "Andr�s G�mez" - The researcher who found it.
    • Software Developed by: "http://www.contacto.com" - The vendor of the vulnerable software.
    • Contact: "gomezandres@adinet.com.uy" - Contact information for the author.
    • Dork: "allinurl:*.php?txtCodiInfo=" - A Google search query to find potentially vulnerable URLs. This is a powerful reconnaissance technique.

• Vulnerability Description:

  • "An attacker may execute arbitrary SQL statements on the vulnerable system. This may compromise the integrity of your database and/or expose sensitive information."
  • Purpose: Explains the impact of the vulnerability.
  • Details: Highlights the risks of data compromise and exposure.

• Example 1: http://site.tld/path/interna.php?txtCodiInfo='

  • Purpose: Demonstrates the simplest form of injection.
  • Details: By appending a single quote ('), the attacker attempts to terminate the existing SQL query. If the application doesn't handle this quote properly, it will likely result in a SQL syntax error, confirming the vulnerability.

• Example 2: http://site.tld/path/interna.php?txtCodiInfo=2+and+1=0+union+select+1,2,3,4,5,6,7,8,9,10--

  • Purpose: Shows how to use UNION SELECT to retrieve data.
  • Details:
    • 2: This likely represents a valid value that the txtCodiInfo parameter would normally expect.
    • +and+1=0: This part is crucial. 1=0 is always false. By appending AND 1=0, the attacker ensures that the original query's conditions will not be met, effectively making the original query return no results. This is a common technique to isolate the results from the injected UNION SELECT statement.
    • union+select+1,2,3,4,5,6,7,8,9,10: This is the core of the injection. UNION SELECT combines the result set of the original query with the result set of the injected SELECT statement. The attacker is trying to determine the number of columns expected by the original query. They provide a series of numbers (1 through 10) as placeholders. The web application will likely return these numbers if the UNION SELECT is successful. The number of SELECTed items must match the number of columns in the original query.
    • --: This is a SQL comment. It tells the database to ignore anything that comes after it on the same line. This is used to comment out any remaining parts of the original SQL query that might interfere with the injected statement.

• Example 3: http://site.tld/path/interna.php?txtCodiInfo=2+and+1=0+union+select+1,2,3,@@version,5,6,7,8,9,10--

  • Purpose: Demonstrates retrieving specific database information.
  • Details:
    • This is similar to Example 2, but instead of just numbers, it injects @@version.
    • @@version: This is a common SQL Server variable that returns the version of the SQL Server. In other database systems, similar functions exist (e.g., version() in MySQL, v$version in Oracle). The attacker is using this to confirm the database type and version, which can be useful for further exploitation. The position of @@version (the 4th position in this case) indicates that the original query likely expects at least 4 columns, and the 4th column's output will be replaced by the database version.

• Malicious users may inject SQL querys...:

  • Purpose: Reiteration of the impact and attacker motivations.
  • Details: Emphasizes data gathering and exposure of sensitive information.

• Solution:

  • $_GET = preg_replace("|([^\w\s\'])|i",'',$_GET);
  • $_POST = preg_replace("|([^\w\s\'])|i",'',$_POST);
  • Add them to your template index.php after the first <?php decelaration.
  • Purpose: Provides a proposed fix for the vulnerability.
  • Details:
    • This solution uses preg_replace to remove characters that are not alphanumeric (\w), whitespace (\s), or a single quote (') from $_GET and $_POST superglobals.
    • The regular expression |([^\w\s\'])|i means:
      • |: Delimiter for the regular expression.
      • [^...]: Negated character set. Matches any character not in the set.
      • \w: Word characters (alphanumeric plus underscore).
      • \s: Whitespace characters.
      • \': A literal single quote.
      • i: Case-insensitive flag.
    • In essence, it attempts to strip out potentially dangerous characters that could be used in SQL injection.
    • Critique: This is a very weak sanitization method. It allows single quotes, which are fundamental to SQL injection. A much more robust solution would involve parameterized queries or proper escaping of special characters specific to the database being used. Relying solely on this preg_replace would likely still leave the application vulnerable to various forms of SQL injection.

• Special Thanks:

  • Purpose: Acknowledgment of contributors.
  • Details: "HYPERNETHOST & Mauro Rossi" - Mauro Rossi is listed as an author of the paper.

Practical details for offensive operations teams

• Required Access Level: Typically, no special access is required beyond the ability to send HTTP requests to the target web server. This is a client-side vulnerability from the perspective of the attacker's interaction.
• Lab Preconditions:
  • A target web application that uses the vulnerable KLINK software or a similar PHP application with the same coding pattern.
  • A functional web server environment (e.g., Apache, Nginx) with PHP and a database (e.g., MySQL, MSSQL) configured.
  • The specific vulnerable version of KLINK or a custom application exhibiting the same txtCodiInfo parameter handling.
• Tooling Assumptions:
  • Web Browser: For manual testing and initial reconnaissance.
  • Burp Suite / OWASP ZAP: Essential for intercepting, modifying, and replaying HTTP requests. This allows for precise crafting of injection payloads.
  • SQLMap: An automated SQL injection tool that can detect and exploit this type of vulnerability efficiently. It can also help determine the number of columns and retrieve data.
  • Command-line tools (curl): For scripting and automated testing.
• Execution Pitfalls:
  • Incorrect Column Count: The UNION SELECT statement must have the same number of columns as the original query. If the attacker guesses incorrectly, the query will fail. Tools like SQLMap are invaluable for automating this discovery.
  • Database-Specific Syntax: The @@version variable is specific to SQL Server. For other databases (MySQL, PostgreSQL, Oracle), different functions or variables would be needed (e.g., version() for MySQL). The attacker needs to identify the target database.
  • WAF/IDS Evasion: Modern Web Application Firewalls (WAFs) or Intrusion Detection Systems (IDS) might detect common SQL injection patterns like UNION SELECT or specific keywords. Payloads may need encoding or obfuscation.
  • Application Logic: The vulnerability might only be exploitable under specific application states or user roles.
  • Sanitization/Filtering: Even if the original code is vulnerable, intermediate security controls (like a WAF) or more recent patches might prevent exploitation.
  • Error Handling: If the application has very strict error reporting disabled, it might not reveal the SQL errors needed to confirm the injection.
• Tradecraft Considerations:
  • Reconnaissance: Use the provided dork or similar techniques to identify potential targets. Analyze the URL structure of the target application.
  • Manual Verification: Start with simple injections (like Example 1) to confirm the vulnerability.
  • Column Discovery: Systematically test UNION SELECT with increasing numbers of columns until the query executes without error.
  • Data Extraction: Once the column count is known, replace numbers with queries to extract sensitive data (e.g., usernames, passwords, credit card numbers, system information).
  • Payload Obfuscation: If standard payloads are blocked, consider URL encoding, case variations, or using alternative SQL syntax.
  • Post-Exploitation: Depending on the data obtained, the next steps could involve privilege escalation, lateral movement, or data exfiltration.

Where this was used and when

• Context: This exploit targets a specific web application named "KLINK" developed by "contacto.com". The vulnerability was documented in late 2010.
• Usage: The paper suggests this vulnerability could be used by "malicious users" to gather data or see sensitive information. It's likely that similar vulnerabilities existed in other PHP web applications that did not properly sanitize user input from URL parameters.
• Timeframe: The exploit was published on January 1, 2011, indicating it was relevant around that period. SQL injection vulnerabilities have been prevalent for decades, and this paper highlights a specific instance of it in a particular application.

Defensive lessons for modern teams

• Input Validation is Paramount: Never trust user input. All data coming from external sources (URLs, forms, APIs) must be validated and sanitized.
• Parameterized Queries / Prepared Statements: This is the gold standard for preventing SQL injection. Instead of concatenating user input into SQL strings, use parameterized queries where the SQL command and the data are sent separately to the database. The database engine then handles the data safely.
• Least Privilege Principle: Ensure the database user account used by the web application has only the minimum necessary permissions. This limits the damage an attacker can do even if they achieve SQL injection.
• Regular Security Audits and Code Reviews: Proactively scan code for common vulnerabilities like SQL injection.
• Web Application Firewalls (WAFs): While not a complete solution, WAFs can provide a layer of defense by detecting and blocking common attack patterns. However, they can be bypassed.
• Secure Coding Practices: Educate developers on secure coding principles and common web vulnerabilities.
• Database Error Handling: Configure database error reporting to be verbose only in development environments. In production, log errors securely but do not expose detailed error messages to end-users, as these can reveal valuable information to attackers.
• The provided "Solution" is insufficient: The preg_replace method described in the paper is a weak defense and should not be relied upon as the sole security measure.

ASCII visual (if applicable)

This vulnerability is primarily about how data flows from the user's browser to the web server and then to the database.

+-----------------+      +-----------------+      +-----------------+
| User's Browser  |----->| Web Server      |----->| Database Server |
| (Sends Request) |      | (PHP Application)|      | (Stores Data)   |
+-----------------+      +-----------------+      +-----------------+
        |                        |                        ^
        | `txtCodiInfo='`        |                        |
        | (Malicious Input)      | SQL Query              |
        |                        | (Unsanitized)          |
        |                        v                        |
        |                  +-----------------+              |
        |                  | Vulnerable Code |--------------|
        |                  | (Concatenates   |
        |                  | Input into SQL) |
        |                  +-----------------+
        |
        | `2+and+1=0+union+select...--`
        | (Injected Payload)
        |
        +---------------------------------------------------------> (Potential Data Leak/Compromise)

Source references

• Paper ID: 15886
• Paper Title: KLINK - SQL Injection
• Author: Mauro Rossi & Andres Gomez
• Published: 2011-01-01
• Keywords: PHP, webapps
• Paper URL: https://www.exploit-db.com/papers/15886
• Raw URL: https://www.exploit-db.com/raw/15886

Original Exploit-DB Content (Verbatim)

##########################[Andr�s G�mez]################################
> # Exploit Title : KLINK Sql Injection Vulnerability
> # Date : 2010-12-31
> # Author : Andr�s G�mez
> # Software Developed by : http://www.contacto.com<http://www.contacto.com.com/>
> # Contact : gomezandres@adinet.com.uy
> # Dork : "allinurl:*.php?txtCodiInfo="
> ########################################################################
> # An attacker may execute arbitrary SQL statements on the vulnerable
> system.
> #This may compromise the integrity of your database and/or expose sensitive
> information.
> ########################################################################
> # Example 1: http://site.tld/path/interna.php?txtCodiInfo='
> # Example 2:
> http://site.tld/path/interna.php?txtCodiInfo=2+and+1=0+union+select+1,2,3,4,5,6,7,8,9,10--
> # Example 3:
> http://site.tld/path/interna.php?txtCodiInfo=2+and+1=0+union+select+1,2,3,@@version,5,6,7,8,9,10--
> ########################################################################
> # Malicious users may inject SQL querys into a vulnerable
> # application to fool a user in order to gather data from them or see
> sensible information.
> ########################################################################
> # Solution:
> # $_GET = preg_replace("|([^\w\s\'])|i",'',$_GET);
> # $_POST = preg_replace("|([^\w\s\'])|i",'',$_POST);
> # Add them to your template index.php after the first <?php decelaration.
> ########################################################################
> # Special Thanks : HYPERNETHOST & Mauro Rossi
> ##########################[Andr�s G�mez]################################