Der Apache HTTP Server ist einer der am weitesten verbreiteten Webserver im Internet und wird häufig als Reverse Proxy eingesetzt, um Datenverkehr an Backend-Anwendungen zu verwalten und weiterzuleiten. Seine Stabilität und Leistung machen ihn zu einer kritischen Komponente in vielen Unternehmens- und Webhosting-Umgebungen.
Diese Schwachstelle stellt ein erhebliches Risiko für Organisationen dar, die Apache in einer Reverse-Proxy-Konfiguration verwenden. Ein erfolgreicher Exploit ermöglicht eine HTTP-Desynchronisation, einen ausgeklügelten Angriff, der zu Web-Cache-Poisoning oder Session-Hijacking führen kann. Ein Angreifer könnte eine Website verunstalten, schädliche Inhalte an Benutzer ausliefern oder sensible Sitzungscookies stehlen, um sich als legitime Benutzer auszugeben und auf deren Daten zuzugreifen.
Die Schwachstelle ist ausnutzbar, wenn die Backend-Anwendung, für die Apache als Proxy fungiert, einen separaten Fehler aufweist, der die Injektion von Antwort-Headern ermöglicht. Obwohl es keine öffentlichen Berichte über aktive Exploits für diese spezifische CVE gibt, ist die HTTP-Desynchronisation eine gut verstandene Angriffsklasse, und es sind öffentliche Proof-of-Concepts verfügbar, was die Wahrscheinlichkeit einer zukünftigen Ausnutzung erhöht. Im Internet exponierte Reverse Proxys sind am stärksten gefährdet.
| Produkt | Apache HTTP Server |
| Datum | 06.12.2025 12:19:05 |
Technische Zusammenfassung
Die Hauptursache für CVE-2024-24795 ist eine unsachgemäße Validierung von HTTP-Antwort-Headern, die von Backend-Anwendungen stammen – ein Fehler, der als CWE-113: Improper Neutralization of CRLF Sequences in HTTP Headers (‘HTTP Response Splitting’) klassifiziert ist. Wenn der Apache-Server als Reverse Proxy fungiert, neutralisiert er die in diesen Headern vorhandenen Wagenrücklauf- und Zeilenvorschubzeichen (CRLF) nicht korrekt.
Ein Angreifer kann diesen Fehler ausnutzen, indem er eine Backend-Anwendung kompromittiert, um schädliche CRLF-Sequenzen in einen Antwort-Header zu injizieren. Die Angriffskette gliedert sich wie folgt:
- Ein Angreifer nutzt einen separaten Fehler in einer Backend-Anwendung aus, um ein Payload mit CRLF-Sequenzen (
\r\n) in einen HTTP-Antwort-Header zu injizieren. - Die Backend-Anwendung sendet die manipulierte Antwort an den Apache-Reverse-Proxy.
- Der anfällige Apache-Server leitet diese Antwort weiter, ohne die CRLF-Zeichen zu entfernen.
- Nachgelagerte Clients oder Caches interpretieren die CRLF-Sequenz als Ende einer Antwort und Beginn einer zweiten, vom Angreifer kontrollierten Antwort. Dies führt zur Desynchronisation der Verbindung.
Diese Desynchronisation ermöglicht es einem Angreifer, der nächsten legitimen Antwort auf derselben TCP-Verbindung eine schädliche Antwort voranzustellen, was Cache-Poisoning oder den Diebstahl von Sitzungsdaten des nachfolgenden Benutzers ermöglicht.
Betroffene Versionen:
- Versionen des Apache HTTP Servers vor 2.4.59 sind anfällig.
Verfügbare Korrektur:
- Die Schwachstelle wurde in Version 2.4.59 (und neuer) des Apache HTTP Servers behoben.
Ein konzeptionelles Beispiel für einen bösartigen Antwort-Header von einem Backend:
HTTP/1.1 200 OK
Injected-Header: value\r\n\r\nHTTP/1.1 200 OK\r\nContent-Type: text/html\r\nContent-Length: 50\r\n\r\n<html><body>Malicious Content</body></html>
Empfehlungen
Patch sofort anwenden: Aktualisieren Sie alle Apache HTTP Server-Instanzen auf die neueste stabile Version, 2.4.59 oder höher, die die Korrektur für diese Schwachstelle enthält.
Mitigationen:
Härten Sie alle Backend-Anwendungen ab, um Injektionsschwachstellen in HTTP-Headern zu verhindern. Implementieren Sie eine strikte Eingabevalidierung und ein Output-Encoding für alle benutzergesteuerten Daten, die in Antwort-Headern reflektiert werden.
Falls das Einspielen des Patches nicht sofort möglich ist, konfigurieren Sie eine Web Application Firewall (WAF) oder einen zwischengeschalteten Proxy mit strengen CRLF-Filterregeln für HTTP-Antwort-Header.
Suche & Überwachung:
Überwachen Sie Anwendungs- und Proxy-Logs auf ungewöhnliche Antworten von Backend-Servern. Suchen Sie insbesondere nach HTTP-Antwort-Headern, die URL-kodierte CRLF-Sequenzen (
%0d%0a) enthalten.Führen Sie Audits auf Cache-Servern durch, um Anomalien zu erkennen, wie z. B. nicht übereinstimmende
Content-Length-Header oder unerwartete Inhalte, die für populäre Ressourcen ausgeliefert werden. Analysieren Sie Logs auf Meldungen über mehrere Antworten für eine einzelne Anfrage.Reaktion auf Vorfälle:
Wenn eine Kompromittierung vermutet wird, leeren Sie sofort alle relevanten Web-Caches (sowohl serverseitig als auch clientseitig, sofern möglich).
Invalidieren Sie alle aktiven Benutzersitzungen, um das Risiko von Session-Hijacking zu mindern.
Isolieren Sie die betroffenen Reverse Proxys und Backend-Server, um eine forensische Untersuchung durchzuführen.
Defense-in-Depth:
Führen Sie regelmäßig Sicherheitsbewertungen und Code-Reviews für Backend-Anwendungen durch, um Fehler bei der Header-Injektion zu identifizieren und zu beheben.
Implementieren Sie Netzwerksegmentierung, um Reverse Proxys von kritischen internen Systemen zu isolieren.
[Callforaction-THREAT-Footer]
Leave a Reply