Red Hot Cyber
La cybersecurity è condivisione. Riconosci il rischio, combattilo, condividi le tue esperienze ed incentiva gli altri a fare meglio di te.
Redazione RHC : 12 Dicembre 2023 18:41
Molte applicazioni che utilizzano la libreria Apache Log4j utilizzano versioni vulnerabili a vari problemi, inclusa la nota vulnerabilità Log4Shell (CVE-2021-44228 ). Questo anche se sono passati più di due anni da quando è stato scoperto il bug e successivamente corretto.
A metà dicembre 2021, gli sviluppatori dell’Apache Software Foundation hanno rilasciato un aggiornamento di sicurezza di emergenza che correggeva una vulnerabilità 0day (CVE-2021-44228) nella popolare libreria di logging Log4j, parte dell’Apache Logging Project.
L’urgenza era spiegata dal fatto che gli specialisti della sicurezza informatica avevano già iniziato a rendere pubblici gli exploit PoC, spiegando che il bug poteva essere utilizzato da remoto, e ciò non richiedeva competenze tecniche particolari.
Sei un Esperto di Formazione?
Entra anche tu nel Partner program!
Accedi alla sezione riservata ai Creator sulla nostra Academy e scopri i vantaggi riservati ai membri del Partner program.
Per ulteriori informazioni, scrivici ad [email protected] oppure su Whatsapp al 379 163 8765
Supporta RHC attraverso:
Il problema si chiamava Log4Shell e, ovviamente, gli attacchi contro di esso non si sono fatti attendere. Ben presto la vulnerabilità divenne una delle più sfruttate dagli hacker, poiché gli aggressori iniziarono a cercare in Internet eventuali applicazioni Java che potessero utilizzare la libreria Log4j e a testarne gli exploit.
Il problema Log4Shell ha ricevuto molta attenzione poiché la sua ampia portata e la facilità d’uso hanno attirato molti gli aggressori. Tuttavia, gli analistidi Veracode ora scrivono che una vasta campagna per informare i manutentori dei progetti interessati e gli amministratori di sistema non ha avuto molto successo.
Il fatto è che, secondo i dati raccolti tra il 15 agosto e il 15 novembre, ci sono ancora molti progetti con versioni vulnerabili di Log4j. Pertanto, gli specialisti di Veracode hanno raccolto dati da 3.866 organizzazioni che utilizzano 38.278 applicazioni che dipendono da Log4j dalle versioni 1.1 alla 3.0.0-alpha1.
Di queste applicazioni, solo il 2,8% utilizza le versioni Log4J dalla 2.0-beta9 alla 2.15.0, che sono direttamente vulnerabili a Log4Shell. Un altro 3,8% utilizza Log4j 2.17.0, che non è vulnerabile a Log4Shell, ma è interessato dal problema RCE CVE-2021-44832, che è stato risolto nella versione 2.17.1.
Infine, il 32% utilizza Log4j versione 1.2.x, il cui supporto è terminato nell’agosto 2015. Queste versioni sono vulnerabili a molti problemi seri, inclusi bug come CVE-2022-23307, CVE-2022-23305 e CVE-2022-23302.
In totale, Veracode ha rilevato che circa il 38% delle applicazioni utilizza versioni non sicure di Log4j. L’uso continuato di versioni obsolete delle librerie indica un problema sistemico, che Veracode spiega come il desiderio degli sviluppatori di evitare inutili complessità.
Pertanto, secondo i ricercatori, il 79% degli sviluppatori preferisce non aggiornare affatto le librerie di terze parti dopo la loro inclusione iniziale nel codice base, per non interrompere la funzionalità. Inoltre, nel 65% dei casi, gli aggiornamenti alle librerie open source contengono solo piccole modifiche e correzioni che difficilmente portano a problemi funzionali.
Inoltre, lo studio ha rilevato che il 50% dei progetti impiega più di 65 giorni per risolvere vulnerabilità di elevata gravità. Allo stesso tempo, in caso di carenza di personale, ci vorrà 13,7 volte più tempo per colmare almeno la metà dell’arretrato, e più di sette mesi in caso di consapevolezza insufficiente.
Redazione