muhammad-ali007/log4j_cve-2021-44228Esercizio di laboratorio pratico per sfruttare Log4Shell (CVE-2021-44228) con iniezione JNDI, server referral LDAP e payload di reverse shell. Include rilevamento, tecniche di bypass e guida post-sfruttamento.
La vulnerabilità Log4j, nota anche come "Log4Shell" o "CVE-2021-44228", è una grave falla di sicurezza nella libreria Apache Log4j. Log4j è un framework di logging ampiamente utilizzato in ambienti Java che consente agli sviluppatori di registrare messaggi dalle applicazioni verso varie destinazioni, come file, database e output di console.
La vulnerabilità è stata scoperta nel dicembre 2021 e ha attirato notevole attenzione a causa della sua gravità e del potenziale sfruttamento. Colpisce le versioni 2.x di Log4j e, in alcuni casi, anche versioni precedenti. La vulnerabilità Log4j è una vulnerabilità di Remote Code Execution (RCE), il che significa che un attaccante può eseguire codice arbitrario su un sistema bersaglio sfruttando la falla. La vulnerabilità è causata da un difetto di progettazione nella libreria Log4j relativo all'elaborazione di messaggi di log contenenti dati appositamente creati.
Lo sfruttamento della vulnerabilità si basa sulla capacità di iniettare codice malevolo nel messaggio di log. Ciò può essere ottenuto attraverso vari vettori, come campi di input controllati dall'utente, header di richieste HTTP o altri dati forniti dall'utente che vengono passati all'istruzione di log.
Quando un'applicazione vulnerabile elabora un messaggio di log contenente i dati appositamente creati, Log4j interpreta i dati come una lookup Java Naming and Directory Interface (JNDI). Sfruttando questo comportamento, un attaccante può creare un payload che attiva una lookup JNDI verso un server malevolo controllato dall'attaccante. Questo server può quindi rispondere con un payload che viene eseguito sul sistema bersaglio, consentendo all'attaccante di ottenere l'esecuzione remota di codice.
L'impatto della vulnerabilità Log4j è grave perché Log4j è ampiamente utilizzato in varie applicazioni basate su Java, inclusi server web, applicazioni e servizi cloud. La vulnerabilità consente agli attaccanti di ottenere accesso non autorizzato ai sistemi compromessi, portando potenzialmente a violazioni dei dati, compromissione del sistema e ulteriore sfruttamento dell'ambiente compromesso.
Oggi è disponibile la versione 2.16.0 di log4j che corregge questa vulnerabilità (JNDI è completamente disabilitato, il supporto per Message Lookups è stato rimosso e la nuova vulnerabilità DoS CVE-2021-45046 non è presente). (https://github.com/apache/logging-log4j2/releases/tag/rel%2F2.16.0)
Tuttavia, il pericolo enorme di questa vulnerabilità è dovuto a quanto sia pervasivo il pacchetto di logging. Milioni di applicazioni e fornitori di software utilizzano questo pacchetto come dipendenza nel proprio codice. Mentre potresti essere in grado di correggere il tuo codice che utilizza log4j, altri vendor e produttori dovranno comunque distribuire le proprie patch di sicurezza a valle. Molti ricercatori di sicurezza hanno paragonato questa vulnerabilità a Shellshock per la natura della sua enorme superficie d'attacco. Vedremo questa vulnerabilità per anni a venire.
Per un elenco in continua crescita, supportato dalla community, di software e servizi vulnerabili a CVE-2021-44228, dai un'occhiata a questo repository GitHub (https://github.com/YfryTchsGD/Log4jAttackSurface)
Sebbene esistano molti altri articoli, blog, risorse e materiali di apprendimento su CVE-2021-44228, io (l'autore di questo esercizio) prediligo in particolare questi:
Il pacchetto log4j aggiunge logica extra ai log "analizzando" le voci, in definitiva per arricchire i dati — ma può anche eseguire azioni e persino valutare codice basato sui dati delle voci. Questo è il succo di CVE-2021-44228. Altre sintassi potrebbero infatti essere eseguite esattamente come vengono inserite nei file di log. Alcuni esempi di questa sintassi sono:
Potresti già conoscere il payload generale per abusare di questa vulnerabilità log4j. Il formato della sintassi tipica che sfrutta questa falla è il seguente:
Questa sintassi indica che log4j invocherà funzionalità da "JNDI", ovvero la "Java Naming and Directory Interface". In definitiva, ciò 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 bersaglio contatterà un endpoint (una posizione controllata dall'attaccante, nel caso di questo attacco) tramite il protocollo LDAP. Per brevità, non sarà necessario coprire tutti i dettagli di LDAP qui, ma sappi che è qualcosa con cui dovremo lavorare mentre affiniamo il nostro attacco. Per ora, tieni presente che il bersaglio effettuerà una connessione verso una posizione esterna. Questo è indicato dal segnaposto ATTACKERCONTROLLEDHOST nella sintassi precedente. Tu, nel ruolo dell'attaccante in questo scenario, puoi ospitare un semplice listener per visualizzare questa connessione.
La prossima domanda è: dove potremmo inserire questa sintassi? Ovunque ci siano dati registrati dall'applicazione.
Questo è il cuore della vulnerabilità. Purtroppo, è molto difficile determinare dove sia la superficie d'attacco per diverse applicazioni e, di conseguenza, quali applicazioni siano effettivamente vulnerabili. Il semplice vedere la presenza di file log4j non rivela il numero di versione esatto, né dove o come l'applicazione potrebbe utilizzare il pacchetto.
Altri punti in cui potresti fornire questa sintassi JNDI:
Se desideri maggiori informazioni su questo vettore d'attacco JNDI, consulta questa presentazione Black Hat USA del 2016. https://www.blackhat.com/docs/us-16/materials/us-16-Munoz-A-Journey-From-JNDI-LDAP-Manipulation-To-RCE.pdf
POC
Exploitation A questo punto hai verificato che il bersaglio è effettivamente vulnerabile vedendo questa connessione catturata dal tuo listener netcat. Tuttavia, ha effettuato una richiesta LDAP... quindi tutto ciò che il tuo listener netcat potrebbe aver visto sono caratteri non stampabili (byte dall'aspetto strano). Ora possiamo costruire su questa base per rispondere con un vero handler LDAP.
