Il 9 dicembre è stata resa pubblica la falla di un software assai popolare. La vulnerabilità (CVE-2021-44228) coinvolge la libreria Java Apache Log4j utilizzata a livello mondiale. Considerata di livello critico, permette a chi la sfrutta di eseguire del codice arbitrario a danno dell’applicazione affetta: in gergo si parla di Remote Code Execution (RCE). Una bella metafora utilizzata per spiegare questo problema informatico è questa: “come se mentre stai recitando a teatro qualcuno ti cambia la sceneggiatura e il gobbo suggeritore non tiene più traccia dei testi dei personaggi, anzi, ce ne aggiunge di nuovi”.
La vulnerabilità è stata soprannominata Log4Shell e all’inizio ha interessato le versioni dalla 2.0-beta 9 alla 2.14.1 della libreria. Ma adesso, nonostante le patch, le correzioni prodotte velocemente dalla comunità del software open source, si scoprono nuove vulnerabilità e per mettersi al riparo le patch successive non bastano più.
Per capire il contesto di questa minaccia abbiamo interpellato un esperto del settore, un giovane ricercatore di cyber security e professore di Sistemi di elaborazione delle informazioni nel Dipartimento di Ingegneria dell’Università del Sannio, molto citato dai suoi colleghi scienziati. Si occupa di ricerca industriale per DefenseTech, un’azienda che sviluppa tecnologie per la difesa in ambito aerospazio, ingegneria dei sistemi e cyber security dirigendone il settore R&D.
Indice degli argomenti
Attacchi alla supply chain
In questi giorni pare si stiano moltiplicando le varianti di questa vulnerabilità e Akamai ha registrato 250k attacchi all’ora che cercano di sfruttarla. Professor Visaggio che sta succedendo? Ricordiamo che Java viene usato in miliardi di dispositivi e siti web, Log4j è una delle librerie più usate per il logging e che tra le aziende che colpite ci sono Apple, Tencent, Twitter, CloudFlare. Amazon, Tesla, e altre. Un bel pezzo di Internet, insomma…
È un tipico attacco alla supply chain, particolarmente ben riuscito per tre motivi: Log4j è un’applicazione estremamente diffusa, la vulnerabilità è relativamente facile da sfruttare e consente l’esecuzione di codice remoto, quindi ha un impatto disastroso.
Il problema reale di questo attacco è che non è banale rintracciare Log4j nel proprio patrimonio software, in quanto potrebbe essere incorporata in software che utilizziamo ma di cui non conosciamo la composizione.
La lezione più importante
Lezioni apprese?
Credo che questa storia ci debba insegnare che non possiamo costruire software assemblando componenti e librerie di terze parti senza tenerne esplicitamente traccia, altrimenti accade questo.
Si tratta della lezione più importante di questa storia. Bisogna ridurre il software di terze parti utilizzato in quello che produciamo e comunque bisogna tenerne traccia. Addirittura io credo che chi vende software dovrebbe dichiarare quali componenti esterni utilizza, come accade per i prodotti alimentari che dichiarano gli ingredienti che usano.
La risposta al problema
Come è stata la risposta della comunità scientifica e delle aziende?
Bisogna dire che c’è stata una risposta rapidissima al problema, come mai era successo prima: la Apache Foundation ha rilasciato due patch in pochi giorni e la notizia ha rapidamente raggiunto tutti gli interessati. Dall’altro lato abbiamo assistito anche a un equivalente adattamento degli attaccanti. In pochi giorni è stato distribuito un malware che utilizza questa vulnerabilità per installarsi.
C’è però un altro problema: questa forte concentrazione degli attacchi ha polarizzato gli sforzi degli analisti che sono impegnati nella definizione di firme per bloccare le scansione log4shell, distraendoli dall’hunting di altre minacce. E questo indebolisce il nostro sistema di difesa.
Le strategie per individuare il problema
Per risolvere il problema di sicurezza, viene consigliato di fare OSINT del perimetro pubblico, scansione del perimetro interno, detection sulla rete, aggiornare le policy e ovviamente installare le Patch: può bastare?
No, affatto. Rintracciare Log4J nell’intero patrimonio software non è banale, a causa delle dipendenze indirette, quindi non sono sicuro che tutte le istanze vengano trovate in breve tempo. Per fare questo le aziende dovrebbero dotarsi di processi efficaci di Software Composition Analysis e non tutte sono in grado di farlo.
Bisognerebbe avere asset inventory fatti bene e anche in questo caso non tutti ne sono provvisti. Inoltre, le patch potrebbero porre problemi di retrocompatibilità e questo potrebbe rallentare l’aggiornamento in molti casi o addirittura impedirlo.
Non trascuriamo il largo impiego di software open source o software legacy che non sono provvisti di aziende a cui chiamare per l’assistenza o la manutenzione.
Alcuni esperti dicono che ci porteremo dietro il problema per anni. É vero?
È probabile, certo. Come ho detto prima, purtroppo rintracciare Log4j nel proprio patrimonio software non è semplice e non tutti potrebbero essere nelle condizioni di acquisire la patch. Molti utilizzano software di terze parti che contiene Log4j ma di cui non si hanno patch. E questo dilata la finestra di opportunità degli attaccanti.
Non dimentichiamo che Heartbleed è rimasta attiva per mesi come vulnerabilità. Non mi stupirebbe se con Log4j succedesse qualcosa di analogo.
La vulnerabilità in Italia
Veniamo all’Italia. Alcuni ricercatori dicono che il nostro è un paese particolarmente vulnerabile. È d’accordo oppure no? E se è d’accordo, quali sono secondo lei le cause?
Il problema sta nella percezione del rischio. Il rischio legato agli attacchi informatici in molte organizzazioni italiane non è percepito come severo, per cui vengono presi accorgimenti minimali, a volte sufficienti a soddisfare aspetti normativi o di compliance. Oppure, cosa ancora più grave, in molte organizzazioni, soprattutto pubbliche, manca una chiara “accountability” legata agli incidenti, per cui nessun responsabile significa nessun committment.
Invece la sicurezza deve diventare un problema “sentito” da tutti, non solo da chi poi è il responsabile diretto dei danni causati dagli attacchi.
Manca ancora una consapevolezza diffusa della numerosità degli attacchi e dei danni che questi producono. Mettere in sicurezza una organizzazione oggi richiede interventi profondi che devono modificare tutti i processi dell’organizzazione ed i comportamenti degli addetti, anche quelli che possono sembrare banali. È una mutazione necessaria ma impegnativa e quindi costosa. E, credo, non c’è molta voglia di sostenere questo “costo”. Avere un firewall ed un antivirus non è più sufficiente. Inoltre, oggi sicurezza vuol dire una evoluzione continua della postura, perché gli attacchi evolvono a ritmo serrato ed il cambiamento, come si sa, costa energia, sia in natura che nelle cose umane.
Quindi, se non entriamo in questo ordine di idee, non riusciremo mai a difenderci adeguatamente.
Attacco a Sogin
Pochi giorni fa è stata data la notizia di un attacco informatico alla Sogin che gestisce il decommissioning nucleare in Italia. Gli attaccanti avrebbero esfiltrato 800 GB di materiali. Come è possibile?
Naturalmente posso fare solo ipotesi, non avendo a disposizione i rapporti dell’indagine forense. Un volume così elevato di materiale racconta due cose: insider threat o APT (Advanced Persistent Threat, minaccia avanzata persistente, si tratta spesso di gruppi ben finanziati e organizzati, spesso supportati da “Stati canaglia”, così chiamati per il tipo di tattica usata ndr).
Un’esfiltrazione del genere potrebbe sottendere un livello di difesa ampiamente insufficiente, nel caso di un APT, perché suggerirebbe un’infiltrazione durata molto tempo e che è riuscita a esfiltrare indisturbata così tanti dati. È un volume davvero importante. Oppure un insider threat, che in genere sono è più difficile da individuare.
Oggi abbiamo politiche e processi in grado, per lo meno, di tracciare gli accessi al materiale sensibile o classificato per cui, se fosse questo il caso, dovrebbero essere in grado di ricostruire l’accaduto. Se così non fosse, la situazione sarebbe allarmante e confermerebbe quanto detto nella domanda precedente.
Investimenti nella sicurezza informatica
Non crede che l’Italia investa poco in sicurezza informatica?
Sì. Serve molta ricerca. Le tecnologie di difesa sono chiaramente poco efficaci e servono con urgenza nuovi paradigmi tecnologici. E questi può darceli solo la ricerca. Non si può nemmeno pensare che siano aziende private a sviluppare il know-how per la protezione. Oggi dobbiamo essere in grado di prevedere i trend di attacco, di riconoscere attacchi mai visti prima, di raccogliere filtrare, validare e aggregare automaticamente tutta la threat intelligence prodotta, che è un’attività ancora troppo manuale.
Dobbiamo capire che la cyber security è oggi un dominio critico in cui si deve investire, perché rimanere deboli su questo piano avrà impatti sempre più devastanti per il Paese. E gli attacchi evolvono con crescente rapidità, quindi più si perde terreno e più se ne perderà in futuro.
Il concetto di resilienza
Quali sono i rimedi per rendere l’Italia più resiliente?
Bisogna letteralmente rivoluzionare l’approccio con cui tutti quanti noi guardiamo alla sicurezza informatica. Purtroppo, la sensibilizzazione non basta. Servono norme a cui tutte le organizzazioni devono aderire, altrimenti la transizione sarà lentissima e il problema potrebbe diventare di difficile gestione nell’arco di poco tempo.
Il lavoro da fare è enorme perché, come ho detto, bisogna modificare dall’interno processi (delle organizzazioni) e comportamenti (delle persone). Bisogna, inoltre, instillare una propensione ad una continua evoluzione, per rimanere all’altezza dell’evoluzione degli attacchi.
Consideriamo che esistono numerosissime macchine con sistemi operativi obsoleti, di cui non ci sono più gli aggiornamenti, perimetri non difesi affatto o con configurazioni di controlli ampiamente inadeguati, reti non partizionate, ecc.
Insomma, serve una rivoluzione forte e rapida. E credo che la spinta per fare questo debba essere imposta dall’alto, purtroppo.
