Vulnerabilità Log4j e milioni di attacchi: è allarme rosso
![google spyware google spyware](https://static.digitalworlditalia.it/wp-content/uploads/2018/04/security_threats_hackers_malware_spyware_phishing_virus_thinkstock_905222206-100749995-large-320x210.jpg)
Bitdefender ha pubblicato una nuova ricerca su come i criminali informatici stiano attivamente utilizzando la vulnerabilità Log4j. Nello studio viene confermata una serie di attacchi volti a incorporare estrattori di cryptovalute e tentativi di attacchi per distribuire Ransomware, Trojan e Botnet.
Log4j è una libreria open source, parte degli Apache Logging Services, scritta in Java. La versione originale del Java Development Kit (JDK) non includeva API di logging, quindi le librerie di logging Java hanno rapidamente guadagnato popolarità, compresa proprio Log4j. La libreria Log4j è ampiamente utilizzata da altri framework, come Elasticsearch, Kafka e Flink, che sono alla base di molti siti e servizi web popolari. Java è un framework multipiattaforma e questa vulnerabilità non è quindi limitata alle applicazioni in esecuzione su uno specifico sistema operativo.
Tutte le applicazioni che utilizzano il framework in esecuzione su sistemi operativi come Windows, Linux, macOS e FreeBSD sono vulnerabili. Java alimenta web cam, sistemi di navigazione per auto, lettori DVD e set-top box, vari terminali e persino parchimetri e dispositivi medici. Di conseguenza, questa vulnerabilità ha un effetto a catena molto significativo sulla supply chain del software ed è difficile prevedere la portata totale e l’impatto a lungo termine della vulnerabilità.
Negli ultimi giorni i criminali informatici hanno tentato di diffondere Khonsari, una nuova famiglia di ransomware, per colpire i sistemi con sistema operativo Windows. La maggior parte dei primi attacchi finora ha preso di mira i server Linux. I criminali stanno anche cercando di utilizzare la vulnerabilità per distribuire il Trojan (RAT) di accesso remoto Orcus.
Sono stati poi lanciati attacchi di reverse bash shell, tecnica utilizzata per guadagnare un punto d’appoggio nei sistemi per sfruttarli in un momento successivo. Distribuire una reverse shell su questi server vulnerabili è relativamente semplice da fare e molto probabilmente questa azione sarà seguita da un attacco su larga scala.
Le analisi di Bitdefender hanno riscontrato l’esistenza di diverse botnet che stanno già sfruttando questa vulnerabilità. Le botnet prendono di mira i server per implementare backdoor ed espandere la loro rete di botnet. Più specificamente, Bitdefender ha identificato la botnet Muhstik come uno dei primi utilizzatori.
Di fronte a questo scenario, che sta causando milioni di attacchi e che ha fatto di Log4j2 la vulnerabilità più grave degli ultimi dieci anni, Bitdefender consiglia di implementare tutte le patch esistenti e le misure di mitigazione consigliate. In particolare raccomanda di:
- Condurre un’ampia verifica dell’infrastruttura e delle applicazioni software per identificare tutti i sistemi che implementano il framework di logging Apache Log4j2. Quasi tutte le versioni di Log4j sono vulnerabili, a partire dalla 2.0-beta9 fino alla 2.14.1. Il metodo di protezione più semplice ed efficace è quello di installare la versione più recente della libreria, la 2.15.0. Potete scaricarla sulla pagina del progetto. Nel caso delle versioni di Log4J dalla 2.10 alla 2.14.1, Apache Foundation consiglia di impostare la proprietà di sistema log4j2.formatMsgNoLookups, o di impostare la variabile d’ambiente LOG4J_FORMAT_MSG_NO_LOOKUPS su vero. Per proteggere le versioni precedenti di Log4j (dalla 2.0-beta9 alla 2.10.0), gli sviluppatori della libreria raccomandano di rimuovere la classe JndiLookup dal classpath: zip -q -d log4j-core – *. Jar org / apache / logging / log4j / core / lookup / JndiLookup .class.
- Esaminare la supply chain del software e la struttura di base del software.
- Implementare un approccio che garantisca un livello di difesa profondo. Al momento, gli attacchi consistono in più fasi, dando al team di sicurezza una buona opportunità di impedire che un incidente di sicurezza si evolva in una violazione della sicurezza.
- Monitorare attivamente l’infrastruttura per potenziali tentativi di violazione e rispondere di conseguenza.