È di nuovo allerta per una seconda vulnerabilità scoperta nella libreria Java Log4j (CVE-2021-45046, dopo che la scorsa settimana la Apache Foundation aveva già rilasciato la versione 2.15 della sua utility di logging per affrontare la famigerata vulnerabilità Log4Shell (CVE-2021-44228)che consente di attaccare server e applicazioni basati su Java, da remoto, esponendo oltre 3 miliardi di dispositivi in tutto il mondo.
Tuttavia, questo aggiornamento ha risolto solo parzialmente la vulnerabilità: nella versione 2.15 di Log4j, infatti, solo un aspetto della funzionalità di recupero dei log mediante il tag JNDI (Java Naming and Directory Interface, un’API utilizzata da Log4j per recuperare oggetti da server remoti da utilizzare nei record dei log) era disabilitato per impostazione predefinita.
La Apache Foundation ha quindi rilasciato una seconda correzione della libreria Log4j, ora disponibile in versione 2.16, che disabilita tutto il supporto JNDI per impostazione predefinita e rimuove completamente la gestione della ricerca dei messaggi.
La libreria Java Log4j è incorporata in quasi tutti i servizi o applicazioni Internet che conosciamo, tra cui Twitter, Amazon, Microsoft, Minecraft, Amazon e altri. Al momento la maggior parte degli attacchi si concentra sull'uso di un mining di criptovalute a spese delle vittime ma, sotto l'egida degli hacker più capaci, fondamentalmente qualsiasi dispositivo esposto a Internet è a rischio se sta eseguendo Apache Log4J, versioni da 2.0 a 2.14.1. NCSC (Organizzazione governativa di Cyber Sicurezza inglese) nota che Log4j versione 2 (Log4j2), la versione interessata, è inclusa nei framework Apache Struts2, Solr, Druid, Flink e Swift.
Il consiglio principale della CISA (Organizzazione governativa di Cyber Sicurezza americana) è quello di identificare i dispositivi rivolti a Internet che eseguono Log4j e aggiornarli alla versione 2.16.0, o applicare le mitigazioni fornite dai fornitori "immediatamente". Ma raccomanda anche di impostare avvisi per attacchi sui dispositivi che eseguono Log4j. Le principali azioni da eseguire sarebbero:
AWS ha aggiornato il suo set di regole WAF - AWSManagedRulesKnownBadInputsRuleSet AMR - per rilevare e mitigare i tentativi di attacco Log4j e la scansione. Ha anche opzioni di mitigazione che possono essere attivate per CloudFront, Application Load Balancer (ALB), API Gateway e AppSync. Attualmente sta anche aggiornando tutti gli Amazon OpenSearch Service alla versione patchata di Log4j.
NCSC raccomanda l'aggiornamento alla versione 2.16.0 o successiva, e - dove non possibile - mitigare la falla in Log4j 2.10 e successive impostando la proprietà di sistema "log4j2.formatMsgNoLookups" a "true" o rimuovendo la classe JndiLookup dal classpath.
Parte della sfida sarà identificare il software che ospita la vulnerabilità di Log4j. Il Nationaal Cyber Security Centrum (NCSC) dei Paesi Bassi ha pubblicato una lista A-Z completa e di provenienza su GitHub di tutti i prodotti colpiti di cui è a conoscenza, vulnerabili, non vulnerabili, sotto inchiesta o dove è disponibile una correzione. L'elenco dei prodotti illustra quanto sia diffusa la vulnerabilità, abbracciando servizi cloud, servizi per sviluppatori, dispositivi di sicurezza, servizi di mappatura e altro ancora.
I fornitori con prodotti popolari noti per essere ancora vulnerabili includono Atlassian, Amazon, Microsoft Azure, Cisco, Commvault, ESRI, Exact, Fortinet, JetBrains, Nelson, Nutanix, OpenMRS, Oracle, Red Hat, Splunk, Soft e VMware. L'elenco è ancora più lungo quando si aggiungono i prodotti in cui è stata rilasciata una patch.
Per tutti i possessori di macchine con installato Ubuntu o Debian consigliamo di controllare il link di Server Fault per maggiori informazioni e di eseguire il seguente comando per verificare se la vulnerabilità è presente all’interno dei loro server:
wget https://raw.githubusercontent.com/rubo77/log4j_checker_beta/main/log4j_checker_beta.sh -q -O - | bash
Categorie: News
