Apache HTTP Server è uno dei web server più diffusi su Internet, spesso utilizzato come reverse proxy per gestire e instradare il traffico verso applicazioni backend. La sua stabilità e le sue prestazioni lo rendono un componente critico in molti ambienti aziendali e di hosting web.
Questa vulnerabilità rappresenta un rischio significativo per le organizzazioni che utilizzano Apache in configurazione reverse proxy. Un exploit riuscito consente una desincronizzazione HTTP, un attacco sofisticato che può portare al web cache poisoning o al dirottamento di sessione. Un attaccante potrebbe deturpare un sito web, servire contenuti dannosi agli utenti o rubare cookie di sessione sensibili per impersonare utenti legittimi e accedere ai loro dati.
La vulnerabilità è sfruttabile quando l’applicazione backend, verso cui Apache fa da proxy, presenta un difetto separato che consente l’iniezione di intestazioni di risposta. Sebbene non vi siano segnalazioni pubbliche di exploit attivi per questo specifico CVE, la desincronizzazione HTTP è una classe di attacco ben compresa e sono disponibili proof-of-concept pubblici, aumentando la probabilità di un possibile sfruttamento futuro. I reverse proxy esposti su Internet sono i più a rischio.
| Apache HTTP Server |
| 2025-12-06 12:19:05 |
Riassunto tecnico
La causa principale della CVE-2024-24795 è una validazione impropria delle intestazioni HTTP di risposta provenienti dalle applicazioni backend, un difetto classificato come CWE-113: Improper Neutralization of CRLF Sequences in HTTP Headers (‘HTTP Response Splitting’). Quando funziona come reverse proxy, il server Apache non neutralizza correttamente i caratteri di ritorno a capo e avanzamento riga (CRLF) presenti in queste intestazioni.
Un attaccante può sfruttare questo difetto compromettendo un’applicazione backend per iniettare sequenze CRLF dannose in un’intestazione di risposta. La catena dell’attacco si articola nel seguente modo:
- Un attaccante sfrutta un difetto separato in un’applicazione backend per iniettare un payload contenente sequenze CRLF (
\r\n) in un’intestazione HTTP di risposta. - L’applicazione backend invia la risposta manipolata al reverse proxy Apache.
- Il server Apache vulnerabile inoltra questa risposta senza rimuovere i caratteri CRLF.
- I client a valle o le cache interpretano la sequenza CRLF come la fine di una risposta e l’inizio di una seconda risposta controllata dall’attaccante. Questo desincronizza la connessione.
Questa desincronizzazione permette a un attaccante di premettere una risposta dannosa alla successiva risposta legittima sulla stessa connessione TCP, abilitando il cache poisoning o il furto di dati di sessione dell’utente successivo.
Versioni affette:
- Le versioni di Apache HTTP Server precedenti alla 2.4.59 sono vulnerabili.
Correzione disponibile:
- La vulnerabilità è stata corretta nella versione 2.4.59 (e successive) di Apache HTTP Server.
Un esempio concettuale di intestazione di risposta malevola proveniente da 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>
Raccomandazioni
-
Applicare la patch immediatamente: aggiornare tutte le istanze del server Apache HTTP alla versione stabile più recente, 2.4.59 o successiva, che include la correzione per questa vulnerabilità.
-
Mitigazioni:
-
Rafforzare tutte le applicazioni backend per impedire vulnerabilità di iniezione nelle intestazioni HTTP. Implementare una rigorosa validazione degli input e encoding in uscita per tutti i dati controllabili dall’utente che vengono riflessi nelle intestazioni di risposta.
-
Se non è immediatamente possibile applicare la patch, configurare un Web Application Firewall (WAF) o un proxy intermedio con regole rigorose di filtraggio CRLF per le intestazioni di risposta HTTP.
-
Caccia & Monitoraggio:
-
Monitorare i log delle applicazioni e del proxy per risposte insolite provenienti dai server backend. In particolare, cercare intestazioni HTTP di risposta contenenti sequenze CRLF codificate in URL (
%0d%0a). -
Eseguire audit sui server di cache per rilevare anomalie, come intestazioni
Content-Lengthnon corrispondenti o contenuti inaspettati serviti per risorse popolari. Analizzare i log per segnalazioni di risposte multiple ricevute per una singola richiesta. -
Risposta agli incidenti:
-
Se si sospetta una compromissione, svuotare immediatamente tutte le web cache rilevanti (sia lato server che client, se possibile).
-
Invalida tutte le sessioni utente attive per mitigare il rischio di dirottamento di sessione.
-
Isolare i reverse proxy e i server backend coinvolti per svolgere un’indagine forense.
-
Difesa in profondità:
-
Eseguire regolarmente valutazioni della sicurezza e revisioni del codice sulle applicazioni backend per identificare e correggere difetti di iniezione di intestazioni.
-
Implementare la segmentazione di rete per isolare i reverse proxy dai sistemi interni critici.