Come funziona l'exploit

1. L'app vittima registra l'input fornito dall'attaccante da un'intestazione HTTP.
2. Il server LDAP dell'attaccante risponde con un riferimento a Exploit.class.
3. La vittima recupera Exploit.class via HTTP.
4. L'inizializzatore statico in Exploit viene eseguito, generando una reverse shell verso l'attaccante.

2. Rischio

• Impatto: RCE non autenticata - massima gravità possibile.

• Chi/cosa è a rischio:

  • Qualsiasi applicazione Java che utilizza Log4j <= 2.14.1.
  • Servizi esposti su Internet e interni che registrano input controllati dall'utente (es. intestazioni HTTP).

• Conseguenze:

  • Compromissione del sistema (accesso shell).
  • Esfiltrazione di dati.
  • Pivot verso reti interne.
  • Evasione delle difese perimetrali (attacchi tramite servizi interni).

3. Prova di Concetto

Prerequisiti

1. docker + docker-compose
2. netcat
3. make

Build e avvio

Exploit

1. Avvia un listener netcat:

2. Attiva l'exploit:

3. Netcat riceve una reverse shell dalla vittima:

4. Correzione

Correzione preferita

• Aggiorna a Log4j 2.17.1 o successivo.
• Questa è l'unica correzione completa e a lungo termine. Le versioni precedenti hanno risolto parzialmente ma hanno lasciato esposizioni:
  • CVE-2021-45046: RCE tramite configurazione di logging non predefinita
  • CVE-2021-45105: DoS tramite lookup autoreferenziali
  • CVE-2021-44832: RCE tramite alcune configurazioni di appender JDBC

Mitigazioni temporanee (se l'aggiornamento non è possibile)

1. Guadagna tempo

• Limita le stringhe di exploit in ingresso (${jndi: patterns) con un WAF o middleware.
• Limita le richieste LDAP in uscita dai server applicativi con filtri di egress.

2. Disabilita i lookup:

3. Rafforza la JVM:

Mitigazioni operative

1. Controlla dipendenze e runtime

• Genera un SBOM (gradle dependencies, Snyk, Wiz, ecc.).
• Cerca immagini/server distribuiti per log4j-core-*.jar, inclusi fat JAR.
• Effettua il triage e dai priorità alle mitigazioni per i carichi di lavoro più rischiosi.

2. Monitora e rileva

• Controlla i tentativi di exploit nei log (${jndi:...}, ${${lower:j}ndi:...}, ecc.).
• Monitora il traffico LDAP in uscita per callback.
• Tratta i risultati come potenziali compromissioni, aumenta il livello per la risposta agli incidenti (indagine forense, rimozione di artefatti malevoli, rotazione dei segreti, ecc.).

3. Patch dei fornitori

• Tieni traccia degli advisory dei fornitori (ad es. Elasticsearch) - molti includono Log4j integrato.
• Applica hotfix o workaround forniti fino a quando non sono disponibili patch ufficiali.

4. Miglioramenti strategici

• Applica una policy 'nega per impostazione predefinita' per il filtraggio del traffico in uscita.
• Applica la scansione delle dipendenze in CI/CD.
• Formalizza i playbook di risposta in modo che i team sappiano esattamente cosa fare durante la prossima vulnerabilità 'CVSS 10.0'.
• Esegui esercitazioni di resilienza/tavoli di prova per testare la prontezza per un incidente 'nuovo di classe Log4Shell'.

5. Riferimenti

• Avvisi di sicurezza di Apache