I problemi relativi alle vulnerabilità di Apache Log4j si stanno ampliando. L'ultima notizia in ordine di tempo è che Apache Software Foundation (ASF) ha pubblicato una nuova correzione per la libreria Log4j dopo che la patch precedente per l'exploit Log4Shell è stata considerata "incompleta in alcune configurazioni non predefinite".

Un nuovo alert di MITRE in corrispondenza della vulnerabilità monitorata come CVE-2021-45046 (che interessa tutte le versioni di Log4j dalla 2.0-beta9 alla 2.12.1 e dalla 2.13.0 alla 2.15.0), spiega che nel chiudere la falla CVE-2021-44228 gli addetti si sono resi conto che il JNDI (l'API Java Naming and Directory Interface) ha problemi di sicurezza significativi. Per porvi rimedio è necessario installare l'ultima versione di Log4j, la 2.16.0, che rimuove il supporto per le ricerche dei messaggi e disabilita JNDI per impostazione predefinita.

La nuova falla ha un punteggio CVSS di 3.7, che è di gran lunga meno preoccupante del CVSS di 10 della falla principale. Il problema è che come spesso accade in casi come questo, la falla visibile è accompagnata da molte altre di secondo piano, magari silenti da molto tempo, che vengono alla luce man mano che gli esperti indagano sul problema principale.

La notizia peggiore delle ultime ore viene da Mandiant, secondo cui anche gruppi APT cinesi e iraniani stanno sfruttando Log4Shell, ed è prevedibile che altri ne seguiranno l'esempio. Creeranno punti d'appoggio nelle reti vulnerabili per attività di follow-on.

https://twitter.com/ystan_/status/1470206230647894016?s=20

L'opinione di Kaspersky

Come ha spiegato a Security Open Lab Evgeny Lopatin, security expert di Kaspersky, la velocità di propagazione degli attacchi Log4Shell è dovuta a tre fattori principali: "la pubblicazione anticipata dell'exploit, che ha permesso a un numero enorme di criminali informatici di iniziare rapidamente a sfruttare questa vulnerabilità. Il fatto che lo sfruttamento di CVE-2021-44228 non richiede particolari competenze tecniche, conoscenze o abilità. Terzo ma non ultimo, il dato di fatto che un'enorme quantità di software utilizza un modulo vulnerabile e, di conseguenza, è di per sé vulnerabile".

In questo momento non ci sono dati che suggeriscono un possibile impiego della falla per scatenare attacchi alla supply chain, tuttavia "stiamo assistendo a un uso molto diffuso di questa vulnerabilità" aggiunge Lopatin. Ad attirare gli attaccanti è il fatto che "questa falla possa consegnare facilmente l'accesso remoto alla macchina". Non c'è quindi da stupirsi se si sta assistendo ad attacchi di criptomining, all'installazione di malware, alla diffusione di ransomware e ad azioni finalizzate allo spionaggio. Secondo Lopatin "lo sviluppo di ulteriori attacchi e il loro esito dipenderanno dalla fantasia dei criminali informatici. Le vulnerabilità non ottengono spesso una valutazione di criticità di 10 su 10, quindi dobbiamo aspettarci una varietà di scenari dannosi" conclude Lopatin.

Per quanto riguarda la diffusione della libreria fallata, l'esperto russo si limita a constatare razionalmente che "possiamo continuare a testare il software in modo approfondito a tutti i livelli di sviluppo. Ma sfortunatamente, per quanto bene possa essere svolto questo lavoro, è spesso impossibile evitare le vulnerabilità". La soluzione che propone al problema del DevSecOps quindi è una protezione a valle capace di rilevare e fermare minacce come quelle che stanno fronteggiando i sistemi con Log4j.