Apache HTTP Server è uno dei server web più diffusi su Internet e costituisce la base di una parte significativa dei servizi web, dai siti più semplici ai backend applicativi complessi. Le sue prestazioni e stabilità sono fondamentali per la continuità operativa, rendendo la sua sicurezza una priorità assoluta per amministratori di sistema e team di sicurezza in tutto il mondo.

Questa vulnerabilità rappresenta un rischio elevato perché consente a un utente remoto non autenticato di causare un completo Denial of Service (DoS) con uno sforzo minimo. L’attacco non richiede privilegi speciali né l’interazione dell’utente. Sono disponibili codici di exploit pubblici e l’attacco è semplice da eseguire, aumentando significativamente la probabilità di sfruttamento.

Qualsiasi istanza di Apache HTTP Server esposta a Internet che esegue una versione vulnerabile con il protocollo HTTP/2 abilitato è a rischio. Un attacco riuscito renderà indisponibili tutti i servizi web ospitati, con conseguente interruzione operativa, potenziali perdite economiche e danni reputazionali. Dato l’ampio utilizzo del server, l’impatto potenziale è considerevole.

Riassunto tecnico

La causa tecnica della vulnerabilità è una gestione impropria del meccanismo di controllo del flusso HTTP/2, classificata come CWE-400: Uncontrolled Resource Consumption. Si tratta di una variante dell’attacco “slow loris”, specificamente diretta all’implementazione del protocollo HTTP/2 del server.

L’attacco si sviluppa come segue:

1. L’attaccante avvia una connessione HTTP/2 verso un’istanza vulnerabile di Apache HTTP Server.
2. L’attaccante invia quindi un frame SETTINGS con il parametro SETTINGS_INITIAL_WINDOW_SIZE impostato a 0.
3. Questa impostazione malevola induce la logica di gestione delle connessioni del server a bloccarsi indefinitamente durante l’elaborazione dei dati successivi provenienti dal client, attendendo un aggiornamento della finestra che non arriverà mai.
4. Ciascuna di queste connessioni bloccate occupa un thread worker. Avviando più connessioni simili, un attaccante può rapidamente esaurire tutti i thread worker disponibili nel server.
5. Una volta esaurito il pool di thread worker, il server non è più in grado di accettare nuove connessioni, negando in modo efficace il servizio agli utenti legittimi.

Concettualmente, la configurazione client malevola apparirebbe così:

# Conceptual representation of a malicious HTTP/2 SETTINGS frame
# Do NOT use as an attack string.
SETTINGS {
    SETTINGS_INITIAL_WINDOW_SIZE = 0
}

• Versioni impattate: Apache HTTP Server 2.4.55 fino a 2.4.57
• Versione corretta: Apache HTTP Server 2.4.58

Raccomandazioni

• Applicare la patch immediatamente: Aggiornare le istanze di Apache HTTP Server alla versione corretta 2.4.58 o successive. Questo è il modo più efficace per correggere la vulnerabilità.

• Mitigazioni:

• Come misura temporanea fino all’applicazione della patch, considerare la disabilitazione del protocollo HTTP/2 se non essenziale per l’ambiente. Questo può essere fatto modificando la direttiva Protocols nella configurazione di Apache (es. Protocols http/1.1).

• Utilizzare un Web Application Firewall (WAF) o un dispositivo perimetrale in grado di ispezionare e normalizzare il traffico HTTP/2 per bloccare richieste con una dimensione iniziale della finestra pari a zero.

• Hunt & Monitor:

• Monitorare la pagina server-status di Apache per individuare un numero anomalo di connessioni bloccate in stato “Read” o “Write” persistente senza trasferimenti di dati.

• Analizzare il traffico di rete per un improvviso aumento di connessioni HTTP/2, in particolare quelle che si bloccano dopo lo scambio iniziale del frame SETTINGS.

• Configurare alert per l’utilizzo continuo elevato dei thread worker, che può rappresentare un indicatore precoce dell’attacco.

• Incident Response:

• Se si sospetta una compromissione, riavviare con grazia il servizio Apache per terminare tutte le connessioni esistenti e liberare il pool di thread worker.

• Bloccare temporaneamente gli indirizzi IP sorgente responsabili dell’attacco a livello di firewall. Si noti che gli attaccanti possono cambiare facilmente indirizzo IP, rendendo questa misura solo temporanea.

• Dare priorità alla distribuzione immediata della patch (versione 2.4.58) per prevenire recidive.

• Difesa in profondità:

• Implementare politiche di limitazione delle connessioni e del traffico nei dispositivi perimetrali per rallentare gli attacchi di esaurimento delle risorse.

• Assicurarsi che siano attivi sistemi di monitoraggio e logging completi del server per fornire visibilità su stati di connessione e utilizzo delle risorse.