CVE-2024-39573

Executive Summary

CVE-2024-39573 is a Server-Side Request Forgery (SSRF) vulnerability in the mod_rewrite module of Apache HTTP Server versions 2.4.59 and earlier. An attacker can craft unsafe RewriteRule directives that cause the server to unexpectedly forward requests to mod_proxy, enabling SSRF attacks. This can lead to internal network scanning, access to cloud metadata endpoints, or exploitation of other internal services. The vulnerability is fixed in Apache HTTP Server 2.4.60.

Supply Chain & Package Security

This vulnerability affects the Apache HTTP Server, a widely used web server. Organizations using Apache in their infrastructure should prioritize patching. The risk is amplified in containerized environments where the server may have network access to internal services.

CVSS Breakdown & Threat Level

CVSS Score: 0.0 (No official CVSS vector provided) Threat Level: High (based on SSRF impact and widespread use of Apache)

Rationale: SSRF vulnerabilities allow attackers to pivot from the web server to internal networks, potentially accessing sensitive data or compromising other systems. The lack of a CVSS vector does not diminish the risk.

Deep Dive & Mechanics

The vulnerability lies in how mod_rewrite processes RewriteRule directives. When a RewriteRule is configured to proxy requests (using the [P] flag), it can be tricked into forwarding requests to arbitrary URLs. An attacker can manipulate the request path or query parameters to force the rewrite engine to generate a URL that is then handled by mod_proxy. This bypasses intended access controls and allows the server to make requests to internal hosts.

Root Cause: Insufficient validation of the target URL generated by RewriteRule before passing it to mod_proxy.

Attack Vector: An attacker sends a specially crafted HTTP request to the Apache server. The request is processed by mod_rewrite, which applies a vulnerable RewriteRule. The rule generates a URL pointing to an internal resource (e.g., http://169.254.169.254/latest/meta-data/). The server then uses mod_proxy to fetch this URL, returning the response to the attacker.

Vulnerable vs. Patched Code

Vulnerable (Apache 2.4.59 and earlier):

RewriteRule ^/proxy/(.*)$ http://internal.example.com/$1 [P]

An attacker can send a request to /proxy/http://169.254.169.254/latest/meta-data/ and the server will proxy it.

Patched (Apache 2.4.60): The patch adds validation to ensure that the target URL generated by RewriteRule is not an external or internal URL that could be abused. The exact code change is not publicly available, but the fix likely involves checking the scheme and host of the generated URL against a whitelist or rejecting URLs that are not explicitly allowed.

Exploitation & Lab Setup

Red Team

Lab Setup:

1. Install Apache HTTP Server 2.4.59 on a Linux VM.
2. Enable mod_rewrite and mod_proxy.
3. Add a vulnerable RewriteRule to the configuration:

   RewriteEngine On
   RewriteRule ^/proxy/(.*)$ http://internal.example.com/$1 [P]
   

4. Ensure the server has network access to an internal service (e.g., a metadata endpoint or another internal web server).

Exploitation:

curl -v "http://target-server/proxy/http://169.254.169.254/latest/meta-data/"

If successful, the server will return the cloud metadata.

Blue Team

Detection:

• Monitor Apache access logs for requests containing http:// or https:// in the path.
• Look for requests to internal IP ranges (e.g., 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.169.254).
• Use the Sigma rule provided in the Detection Engineering section.

Mitigation:

• Immediately upgrade to Apache 2.4.60.
• If patching is not possible, disable mod_rewrite or mod_proxy if not needed.
• Implement network segmentation to limit the web server's access to internal resources.
• Use Web Application Firewalls (WAF) to block requests with suspicious patterns.

Indicators of Compromise (IOCs)

• Network: Outbound connections from the Apache server to internal IP addresses (e.g., 10.x.x.x, 172.16.x.x, 192.168.x.x, 169.254.169.254).
• Logs: Apache access log entries with URLs containing http:// or https:// in the request path.
• Process: Unusual mod_proxy activity or connections to internal hosts.

Detection Engineering

YARA Rule

rule CVE_2024_39573_SSRF_ModRewrite {
    meta:
        description = "Detects SSRF attempts via mod_rewrite in Apache HTTP Server"
        author = "Valters IT"
        date = "2024-10-27"
        reference = "CVE-2024-39573"
    strings:
        $s1 = "RewriteRule" nocase
        $s2 = "[P]" nocase
        $s3 = "http://" nocase
        $s4 = "https://" nocase
    condition:
        all of ($s1, $s2) and any of ($s3, $s4)
}

Sigma Rule

title: CVE-2024-39573 SSRF via mod_rewrite
id: 12345678-1234-1234-1234-123456789012
status: experimental
description: Detects SSRF attempts via mod_rewrite in Apache HTTP Server
author: Valters IT
date: 2024/10/27
logsource:
    category: webserver
    product: apache
detection:
    selection:
        cs-uri-query|contains:
            - 'http://'
            - 'https://'
    condition: selection
falsepositives:
    - Legitimate use of proxy functionality
level: high

Suricata Rule

alert http any any -> any any (msg:"CVE-2024-39573 SSRF via mod_rewrite"; flow:to_server; content:"GET"; http_method; content:"http://"; http_uri; distance:0; content:"https://"; http_uri; distance:0; classtype:attempted-recon; sid:1000001; rev:1;)

Remediation & Mitigation

1. Immediate: Upgrade Apache HTTP Server to version 2.4.60 or later.
2. Workaround: If patching is not possible, disable mod_rewrite and mod_proxy if they are not required.
3. Network Segmentation: Restrict the web server's outbound network access to only necessary external services.
4. WAF Rules: Deploy WAF rules to block requests containing http:// or https:// in the URI path.
5. Monitoring: Implement the detection rules above to identify exploitation attempts.

Valters IT
DevSecOps & Cyber Threat Intelligence