Nonostante siano passati diversi giorni dalla scoperta della vulnerabilità, Log4Shell continua a far paura a tutti i programmatori e ai professionisti del settore ICT.
Come avvenuto a livello sanitario con il Covid19, anche il mondo IT si è svegliato una mattina con la sua pandemia: lo scorso 9 Dicembre 2021 è stata scoperta una vulnerabilità nella libreria Log4J e analogamente all’andamento delle fasi del coronavirus, si può dire che è stata subito corsa al vaccino o meglio alle patch.
Per capire la gravità e la portata del problema, dobbiamo prima fare un passo indietro.
In informatica, si definisce libreria un insieme di funzioni o strutture di dati predefinite e predisposte per essere collegate ad un programma software.
Lo scopo delle librerie è rendere disponibili una serie di funzioni di base preimpostate evitando così che il programmatore debba riscriverle ogni volta facilitando così le operazioni di sviluppo e manutenzione. Le entità definite in una certa libreria possono essere riutilizzate da più applicazioni.
Log4J è la libreria utilizzata dalla piattaforme Apache e Java, le più diffuse piattaforme di programmazione ed elaborazione software a livello mondiale.
Quasi tutti i servizi e software che utilizziamo quotidianamente sono stati realizzati con questi linguaggi, è quindi evidente come una vulnerabilità in questi sistemi possa rappresentare un pericolo per l’intero ecosistema IT a livello globale (una fotografia di quello che è successo nei giorni successivi la scoperta della vulnerabilità Log4Shell, l’ha fornita Check Point, azienda di sicurezza informatica israeliana: il 10 dicembre 2021 sono stati registrati qualche migliaio di tentativi di attacco informatico; l’11 dicembre 2021 sono diventati 40.000; il 12 dicembre 2021 200.000; il 13 dicembre 2021, erano più di 840 mila).
Entrando più nello specifico, Log4Shell è una libreria che serve a scrivere file di Log, funzioni tecniche utilizzate dai programmatori.
Fatto questo preambolo, cosa è effettivamente successo?
Si è scoperto che forzando una qualsiasi applicazione che usa la libreria Log4J, si può scrivere una riga di testo nel Log che viene interpretata come un comando (in termine tecnico Remote Code Execution o RCE).
Questa vulnerabilità è stata chiamata Log4Shell.
Quindi qualunque utente forzando l’app può far eseguire alla macchina il codice che desidera, il tutto senza necessità di autenticazione.
È il sogno di qualsiasi hacker, vista anche l’enorme superficie di attacco che hanno a disposizione. Con una sola riga la macchina (non necessariamente un Pc o uno Smartphone collegato ad internet…può trattarsi anche di una telecamera di sorveglianza o di un’auto a guida autonoma ) che fa uso dell’app può connettersi a un sito, scaricare un programma ed eseguirlo.
Un attaccante potrebbe quindi sfruttare queste falle per costringere le varie app a collegarsi a dei server da lui gestiti e quindi ad eseguire dei payload (per payload si intende l’effetto di qualunque infezione virale).
A questo punto è lecito porsi una domanda, quale versione utilizzare di questa libreria?
Stando a quanto riporta The Hacker News, Log4J-2.17.0 è la versione più sicura attualmente disponibile.
Apache ha infatti rilasciato la versione 2.17.0 di Log4j, che contiene la terza patch risolutiva della falla Log4Shell. In particolare, la versione 2.17.0 dovrebbe essere immune sia alla vulnerabilità CVE-2021-45105, che colpiva tutte le versioni dalla 2.0 beta9 alla 2.16.0 permettendo l’esecuzione di codice da remoto, sia alla vulnerabilità CVE-2021-44228, che è quella più propriamente nota come Log4Shell.
La soluzione più immediata, nel caso non sia possibile installare aggiornamenti o patch per eventuali problemi di continuità di servizio o retrocompatibilità, è quella di disabilitare la funzionalità JNDI.
Link utili:
Test di vulnerabilità
Pagina con schermate delle evidenze delle vulnerabilità
Pagina sullo stato dei principali attori
