Apache HTTP Server est l’un des serveurs web les plus répandus sur Internet, souvent utilisé comme reverse proxy pour gérer et acheminer le trafic vers des applications backend. Sa stabilité et ses performances en font un composant critique dans de nombreux environnements d’entreprise et d’hébergement web.
Cette vulnérabilité représente un risque significatif pour les organisations utilisant Apache en configuration reverse proxy. Un exploit réussi permet une désynchronisation HTTP, une attaque sophistiquée pouvant mener à un empoisonnement de cache web (web cache poisoning) ou à un détournement de session. Un attaquant pourrait défigurer un site web, servir du contenu malveillant aux utilisateurs ou voler des cookies de session sensibles afin d’usurper l’identité d’utilisateurs légitimes et d’accéder à leurs données.
La vulnérabilité est exploitable lorsque l’application backend, vers laquelle Apache agit en tant que proxy, présente un défaut distinct permettant l’injection d’en-têtes de réponse. Bien qu’aucun rapport public d’exploitation active ne soit signalé pour cette CVE spécifique, la désynchronisation HTTP est une classe d’attaque bien comprise et des preuves de concept (PoC) publiques sont disponibles, augmentant la probabilité d’une exploitation future. Les reverse proxies exposés sur Internet sont les plus exposés au risque.
| Produit | Apache HTTP Server |
| Date | 2025-12-06 12:19:05 |
Résumé technique
La cause principale de la CVE-2024-24795 est une validation inappropriée des en-têtes de réponse HTTP provenant des applications backend, un défaut classé comme CWE-113 : Neutralisation incorrecte des séquences CRLF dans les en-têtes HTTP (‘HTTP Response Splitting’). Lorsqu’il fonctionne comme reverse proxy, le serveur Apache ne neutralise pas correctement les caractères de retour chariot et de saut de ligne (CRLF) présents dans ces en-têtes.
Un attaquant peut exploiter ce défaut en compromettant une application backend pour injecter des séquences CRLF malveillantes dans un en-tête de réponse. La chaîne d’attaque se déroule comme suit :
- Un attaquant exploite un défaut distinct dans une application backend pour injecter une charge utile contenant des séquences CRLF (
\r\n) dans un en-tête de réponse HTTP. - L’application backend envoie la réponse manipulée au reverse proxy Apache.
- Le serveur Apache vulnérable transfère cette réponse sans supprimer les caractères CRLF.
- Les clients en aval ou les caches interprètent la séquence CRLF comme la fin d’une réponse et le début d’une seconde réponse contrôlée par l’attaquant. Cela désynchronise la connexion.
Cette désynchronisation permet à un attaquant de faire précéder une réponse malveillante à la réponse légitime suivante sur la même connexion TCP, permettant ainsi l’empoisonnement du cache ou le vol de données de session de l’utilisateur suivant.
Versions affectées :
- Les versions d’Apache HTTP Server antérieures à la 2.4.59 sont vulnérables.
Correctif disponible :
- La vulnérabilité a été corrigée dans la version 2.4.59 (et ultérieures) d’Apache HTTP Server.
Un exemple conceptuel d’en-tête de réponse malveillant provenant d’un 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>
Recommandations
Appliquer le correctif immédiatement : mettre à jour toutes les instances du serveur Apache HTTP vers la version stable la plus récente, 2.4.59 ou ultérieure, qui inclut le correctif pour cette vulnérabilité.
Atténuations :
Renforcer toutes les applications backend pour empêcher les vulnérabilités d’injection dans les en-têtes HTTP. Mettre en œuvre une validation stricte des entrées et un encodage en sortie pour toutes les données contrôlables par l’utilisateur qui sont reflétées dans les en-têtes de réponse.
Si l’application du correctif n’est pas immédiatement possible, configurer un Web Application Firewall (WAF) ou un proxy intermédiaire avec des règles strictes de filtrage CRLF pour les en-têtes de réponse HTTP.
Chasse & Surveillance :
Surveiller les journaux des applications et du proxy pour détecter des réponses inhabituelles provenant des serveurs backend. En particulier, rechercher les en-têtes de réponse HTTP contenant des séquences CRLF encodées en URL (
%0d%0a).Effectuer des audits sur les serveurs de cache pour détecter des anomalies, telles que des en-têtes
Content-Lengthnon concordants ou des contenus inattendus servis pour des ressources populaires. Analyser les journaux pour détecter des signalements de réponses multiples reçues pour une seule requête.Réponse aux incidents :
En cas de suspicion de compromission, vider immédiatement tous les caches web pertinents (côté serveur et côté client, si possible).
Invalider toutes les sessions utilisateur actives pour atténuer le risque de détournement de session.
Isoler les reverse proxies et les serveurs backend impliqués pour mener une enquête forensique.
Défense en profondeur :
Effectuer régulièrement des évaluations de sécurité et des revues de code sur les applications backend pour identifier et corriger les défauts d’injection d’en-têtes.
Mettre en œuvre la segmentation réseau pour isoler les reverse proxies des systèmes internes critiques.
[Callforaction-THREAT-Footer]
Leave a Reply