Per l’attaccante che sfrutta la falla sarà possibile acquisire il controllo dell’applicazione interessata e l’accesso completo al sistema. L’impatto si ripercuote su architettura sia Windows sia Linux. Le analisi di Andrea Chittaro (SNAM) e di Stefano Fratepietro (Tesla Consulting).
Il rischio di “attacco è sulla totalità della rete Internet”, avverte il CSIRT – Computer Security Incident Response Team – Italia, guidato dall’Agenzia per la Cybersicurezza Nazionale. Per questo motivo c’è chi parla “dell’apocalisse dell’informatica” se si dovesse sfruttare pienamente la vulnerabilità nota col nome Log4Shell, che interessa applicazioni Java-based che utilizzano per il logging il prodotto open source Log4j 2, sviluppato da Apache, dalla versione 2.0 fino alla 2.14.1.
Stefano Fratepietro: “Vulnerabilità sfruttata in queste ore in modo massiccio per installare criptominer e per sferrare attacchi informatici”
L’exploit genera un pezzo di una riga di log che consente di eseguire qualsiasi comando o programma. “Dai nostri monitoraggi, effettuati da quando la vulnerabilità è stata scoperta, abbiamo riscontrato solo il suo utilizzo, in modo massivo, per installare criptominer e per violare i sistemi con l’obiettivo di sferrare futuri attacchi informatici”, ci racconta Stefano Fratepietro, CEO Tesla Consulting S.r.l. e CSO Be Shaping the Future S.p.A.
Essendo interessata una libreria Java, per natura multipattaforma, l’impatto si ripercuote su architettura sia Windows sia Linux e sono da considerare potenzialmente vulnerabili anche i sistemi di backend e i microservizi.
Come può essere sfruttata Log4Shell e come è possibile impedirne l’attività malevola
Ma la vulnerabilità è anche un po’ complessa da sfruttare: sebbene alcuni prodotti possano essere vulnerabili, non è necessario che la falla possa essere utilizzata con successo poiché dipende da diverse pre e post condizioni come la JVM utilizzata, la configurazione effettiva, ecc. Visivamente, ecco come può essere sfruttata Log4Shell e come è possibile impedirne l’attività malevola, secondo l’infografica di Swiss Government Computer Emergency Response Team.
Concretamente, sono a rischio migliaia di dispositivi, ossia software open-source spesso direttamente integrati in importanti applicazioni da Minecraft (client and server) – inclusi quelli di casa Apache come: Struts 2, Solr, Druid, Flink e Swift – fino a quelli venduti da società specializzate in sicurezza. I prodotti interessati dalla vulnerabilità sono oltre 150, ecco quali.
Come può essere sfruttata la vulnerabilità Log4Shell
Ecco il possibile scenario di attacco. L’eventuale sfruttamento della falla consente l’esecuzione di codice arbitrario a danno dell’applicazione affetta. Gli aggressori, che non necessitano di un accesso preventivo al sistema, possono inviare una richiesta https malformata tramite una stringa appositamente predisposta, per generare un log su Log4j – che adotta JNDI (Java Naming and Directory Interface) – con l’obiettivo di registrare la stringa dannosa nel registro dell’applicazione. Durante l’elaborazione del registro, il sistema vulnerabile si troverà nelle condizioni di eseguire il codice appositamente inserito dall’utente malintenzionato. Questa condizione può ad esempio portare l’applicazione ad effettuare una richiesta verso un dominio dannoso per eseguire un payload malevolo. In questo modo per l’attaccante sarà possibile acquisire il controllo dell’applicazione interessata e l’accesso completo al sistema.
Azione di mitigazione
Il CSIRT consiglia di installare Log4j 2 nella versione 2.15.0 o e qualora non fosse possibile, ridurre la superficie di attacco:
- impostare le seguenti proprietà:
log4j2.formatMsgNoLookups=true
LOG4J_FORMAT_MSG_NO_LOOKUPS=true
2. rimuovere la classe JndiLookup dal path delle classi
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
3. Impostare le seguenti proprietà in Java 8u121:
com.sun.jndi.rmi.object.trustURLCodebase
com.sun.jndi.cosnaming.object.trustURLCodebase=false
Poiché molte applicazioni basate su Java possono sfruttare Log4j 2, le organizzazioni dovrebbero valutare di contattare i fornitori di applicazioni o assicurarsi che le loro applicazioni Java eseguano l’ultima versione disponibile del prodotto. Anche gli sviluppatori che utilizzano Log4j 2 dovrebbero assicurarsi di adottare l’ultima versione nelle applicazioni per garantire protezione agli utenti e le organizzazioni.
Andrea Chittaro (SNAM): “Il patching per la mitigazione potrebbe richiedere molto tempo”
Quanto è grave questa vulnerabilità? Le patch di sicurezza rilasciate riusciranno a mitigare i rischi? Lo abbiamo chiesto ad Andrea Chittaro, Global Security & Cyber Defence SNAM e Presidente AIPSA. “La gravità ‘concreta’ la valuteremo quanto agli effetti. Quella ‘percepita’ è assolutamente rilevante trattandosi di uno zero day verso una delle più diffuse utilità di registrazione open source”, commenta a Cybersecurity Italia. “Quanto al patching”, aggiunge, “sono attività che potrebbero richiedere del tempo vista l’enorme superficie d’attacco che dovranno coprire”. E sottolinea: “Non necessariamente opensource è sinonimo di ‘sicuro’ come spesso si sente erroneamente dire. La gestione della vulnerabilità in emergenza”, conclude Chittaro,” pone ancora una volta l’accento su quanto sia complicato ma al contempo indispensabile avere un formale ed ordinato ciclo di gestione del software”.
Dello stesso tenore è anche l’analisi finale di Stefano Fratepietro: “Per quanto riguarda azioni con maggiori effetti occorrerà aspettare che il cybercrime si organizzi e potremmo trovarci nei prossimi giorni di fronte a ‘brutte sorprese’. Nel frattempo i criminali informatici stanno effettuando un ‘censimento’ dei software interessati dalla vulnerabilità utilizzati dalle grandi aziende”.
