Si chiama Log4Shell, è una vulnerabilità zero-day che da giorni mette in allerta big tech e governi di mezzo mondo.
L’Agenzia per la cybersicurezza nazionale (Acn) guidata da RobeApache Software Foundation ad aver rilasciato un aggiornamento di sicurezza di emergenza che corregge la vulnerabilità 0-day (etichettata come CVE-2021-44228) nella popolare libreria di log Log4j, che fa parte dell’Apache Logging Project. La patch è stata rilasciata come parte della versione 2.15.0.
La vulnerabilità è stata denominata Log4Shell e ha ottenuto 10 punti su 10 nella scala di valutazione della vulnerabilità CVSS. Il bug consente l’esecuzione di codice remoto non autenticato (RCE). Il problema è aggravato dal fatto che ieri il ricercatore di sicurezza informatica p0rz9 ha già pubblicato un exploit PoC su Twitter, dimostrando che la vulnerabilità può essere sfruttata da remoto, e questo inoltre non richiede particolari competenze tecniche.
Come funziona Log4Shell
La società di sicurezza LunaSec descrive come funziona Log4Shell sul proprio blog dicendo che: la vulnerabilità costringe le applicazioni e i server basati su Java che utilizzano la libreria Log4j a registrare una riga specifica nei propri sistemi interni. Quando un’applicazione o un server elabora tali registri, una stringa può far scaricare ed eseguire uno script dannoso sul sistema vulnerabile dal dominio controllato dell’attaccante. Il risultato sarà un completo dirottamento dell’applicazione o del server vulnerabile.
I siti e app colpiti
Il problema è stato originariamente scoperto durante la ricerca di bug sui server Minecraft, ma Log4j è presente in quasi tutte le applicazioni aziendali e i server Java.
Ad esempio, la libreria può essere trovata in quasi tutti i prodotti aziendali rilasciati dalla Apache Software Foundation, inclusi Apache Struts, Apache Flink, Apache Druid, Apache Flume, Apache Solr, Apache Flink, Apache Kafka, Apache Dubbo e così via. Log4j è anche utilizzato attivamente in vari progetti open source, tra cui Redis, ElasticSearch, Elastic Logstash, Ghidra e altri.
Pertanto, anche le aziende che utilizzano uno di questi prodotti sono indirettamente vulnerabili agli attacchi Log4Shell. Gli specialisti della sicurezza delle informazioni segnalano già che le soluzioni di colossi come Apple (iCloud), Amazon, Twitter, Cloudflare, Steam, Tencent, Baidu, DIDI, JD, NetEase e probabilmente migliaia di altre aziende meno note potrebbero essere vulnerabili a Log4Shell.
Ieri p0rz9 ha scritto che CVE-2021-44228 può essere sfruttata solo se il parametro log4j2.formatMsgNoLookups è impostato su false. The Record riporta che, secondo la società KnownSec 404 Team, nella versione 2.15.0 di Log4j questo parametro è impostato su true, soprattutto per prevenire gli attacchi. Ciò significa che gli utenti di Log4j che hanno eseguito l’aggiornamento alla versione 2.15.0 e quindi hanno impostato il flag su false saranno nuovamente vulnerabili agli attacchi. Inoltre, gli utenti di Log4j che non si sono aggiornati, ma hanno impostato il flag su true, potranno comunque bloccare gli attacchi anche su versioni precedenti prive di aggiornamento.
Sfortunatamente, questo significa anche che tutte le versioni precedenti sono a rischio, nelle quali questo parametro sia impostato su false per impostazione predefinita. Cioè sono vulnerabili tutte le versioni precedenti di Log4j, a partire dalla 2.10.0.
I dettagli della minaccia Log4j
Considerato che gli aggressori normalmente utilizzano dnslog per scansionare la rete prima di partire con l’effettivo sfruttamento, bisogna sapere che modi comuni di sfruttamento della vulnerabilità possono essere “javax.naming.CommunicationException” e “javax.naming.NamingException” nell’error log dell’applicazione. Parole chiave su cui concentrare le ricerche: “Error looking up JNDI resource”.
Come aggiornare e mitigare la minaccia
Se non si è ancora pienamente in grado di eseguire l’operazione di aggiornamento per la propria applicazione Apache, è consigliato aggiungere il seguente parametro di avvio della propria Java Virtual Machine (jvm): -Dlog4j2.formatMsgNoLookups=true come riportato sull’immagine qui sotto:
Aggiungere il file di configurazione log4j2.component.properties nel classpath dell’applicazione, il contenuto del file è: log4j2.formatMsgNoLookups=true
Si raccomanda di verificare che JDK utilizzi almeno la versione 11.0.1, 8u191, 7u201, 6u211 e successive.
Dustin Childs, Zero Day Initiative di Trend Micro, guardando al futuro, si è detto preoccupato che l’impatto di questa vulnerabilità continuerà nei prossimi mesi a causa del gran numero di aziende colpite. Se le organizzazioni eseguono un server basato su software open source, ci sono “buone probabilità” che siano colpite da questa vulnerabilità, ha affermato.
“Dal momento che non esiste un elenco definitivo dei programmi interessati da questo bug, è probabile che vedremo questa vulnerabilità per un po’”, ha affermato. “Non mi sorprenderebbe se trovassimo programmi interessati fra mesi o addirittura anni”.