Come avevamo anticipato ieri, nuovi exploit sono stati scritti utilizzando la versione 2.16 di Log4j.
Infatti gli sviluppatori della community opensource, hanno scoperto che l’aggiornamento alla versione 2.16.0 di log4j (rilasciato urgentemente dopo la correzione 2.15.0), risulta incompleto e contiene un bug di DoS (negazione del servizio)
.
“Se si tenta di sostituire una stringa, si attiverà una loop infinito e l’applicazione si bloccherà”
${${::-${::-$${::-j}}} }
ha scritto il reporter del bug.
È disponibile quindi un nuovo aggiornamento di Log4j e la nuova versione è la 2.17.0, che rimuove il bug di negazione del servizio.
Log4j versioni 2.14.0 e precedenti contengono una vulnerabilità di esecuzione di codice remoto facilmente sfruttabile, che è attualmente viene sfruttata dai criminali informatici e anche dai gruppi ransomware per fare breccia nelle reti e lanciare i cryptolocker.
Infatti gli impatti su tutto l’ecosistema internet è “enorme”, per la facilità di utilizzo dell’exploit e per la diffusione del bug.
Separatamente, il team Open Source Insights di Google ha scansionato il più importante repository Java, Maven Central, e ha scoperto che l’otto percento dei pacchetti ha almeno una versione interessata dalla vulnerabilità log4j.
“Per quanto riguarda l’impatto sull’ecosistema, l’otto percento è un numero enorme, anche se l’impatto medio sull’ecosistema degli avvisi che interessano Maven Central è del due percento”
ha scritto OSIT .
OSIT ha scoperto che 35.863 di artefatti Java disponibili su Maven Central dipendono dal codice log4j vulnerabile al 17 dicembre.
Quasi 5000 artefatti sono stati corretti, ma OSIT li considera corretti se sono stati aggiornati alla 2.16.0, che disabilita by default JNDI e che è essa stessa vulnerabile a negazione del servizio.
La correzione della vulnerabilità è resa più difficile dagli artefatti Java che dipendono indirettamente da log4j, ha affermato OSIT e ha detto che la vulnerabilità può essere annidata fino a nove dipendenze in alcuni pacchetti, ha affermato OSIT.
Un altro problema che rende difficile la correzione della vulnerabilità di log4j è la pratica di specificare requisiti di versione “soft”, ha affermato OSIT.
OSIT ha affermato che è difficile dire quanto tempo ci vorrà per correggere la vulnerabilità log4j e che potrebbero volerci anni per farlo.
Tuttavia, OSIT ha affermato che le cose sembrano promettenti sul fronte di log4j, con manutentori, team di infosec e consumatori che si impegnano a fondo per risolvere questi problemi.
Seguici su Google News, LinkedIn, Facebook e Instagram per ricevere aggiornamenti quotidiani sulla sicurezza informatica. Scrivici se desideri segnalarci notizie, approfondimenti o contributi da pubblicare.
