Team IT e Privacy: cosa manca? Il caso Log4j

di Domenico Grieco - Software Architect GFM Group 

Tra i casi più noti di vulnerabilità degli ultimi 10 anni si annovera sicuramente Apache Log4j. Stiamo parlando della principale libreria Java che permette di registrare log applicativi fondamentali per monitorare i sistemi. Il caso a cui ci riferiamo risale a venerdì 10 dicembre 2021, quando questa innocua libreria si è rivelata il principale mezzo per poter eseguire attacchi informatici. Come può una libreria che si limita a tenere traccia degli eventi di sistema causare problemi di sicurezza? 

Questa è la domanda che si sono posti tutti gli addetti ai lavori, sviluppatori inclusi, e la risposta è da ricercarsi nella capacità di questa libreria di eseguire funzionalità evolute non note ai più, trascurate e attive di default. Bisogna aggiungere però che Log4j da solo non basta ai malintenzionati per sfruttare questa vulnerabilità. Infatti, come indicato nella descrizione fatta dal MITRE (CVE-2021-44228), per sfruttarne la vulnerabilità è necessario che l’attaccante possa controllare un server con interfaccia JNDI come ad esempio LDAP. 

Come avviene un attacco?

Per eseguire l’attacco, il malintenzionato deve controllare un suo server LDAP e fare in modo che il sistema della sua vittima produca dei log che possano essere interpretati da Log4J come un comando. Questo comando deve essere in grado di chiamare il server LDAP del malintenzionato da cui scaricare del codice eseguibile. In questo modo il malintenzionato può disporre del server della vittima e trafugarne dati e/o danneggiarne i servizi. Scoperta da Alibaba e comunicata all’Apache Foundation il 24 novembre 2021, la vulnerabilità viene pubblicata ufficialmente nelle liste CVE qualche settimana dopo. Una volta resa pubblica, la vulnerabilità diventa più sfruttabile, anche grazie alla facilità con cui poteva essere riprodotta. Era sufficiente installare un server LDAP raggiungibile da rete pubblica e tentare, ad esempio, di accedere alla pagina di login in tutti i sistemi che incontrava, utilizzando come username una stringa della forma ${jndi:ldap:}, sperando che il server fosse affetto dalla vulnerabilità.

Come interviene il team IT? 

Per rispondere a questa domanda torniamo ai primi giorni di dicembre 2021, per la precisione al primo giorno lavorativo dopo la pubblicazione della vulnerabilità, lunedì 13 dicembre, e immaginiamo di trovarci in un’azienda qualsiasi. L’annuncio della vulnerabilità scatena una risposta tempestiva del team IT che si adopera per capire se la versione Log4j interessata è presente nei software utilizzati in azienda. Seguono verifiche sui software sviluppati internamente, che coinvolgono il team di sviluppo, e viene richiesto ai fornitori di software di svolgere i controlli necessari. L’analisi effettuata porta alla scoperta di una vulnerabilità nei software interni. A questo punto il team degli sviluppatori per prima cosa adotta un workaround e poi risolve definitivamente la crisi, con la sostituzione della libreria con l’ultima versione rilasciata da Apache. Problema risolto! 

Sicuri? Il personale tecnico può affermare che non è più possibile sfruttare questa vulnerabilità e che di certo l’azienda non ne è stata vittima. Quindi, perché preoccuparsene ulteriormente? È anche vero che non c’è stato tempo per comprendere il problema causato dalla vulnerabilità e i nostri tecnici non ne hanno intuito fino in fondo le sue implicazioni, perché in generale il loro compito è sempre quello di agire tempestivamente per risolvere il problema e non di studiarlo a fondo. 

E il team Privacy?

È molto probabile che in questo ginepraio il team Privacy sia rimasto all’oscuro di tutto. Questo perché non si è trattato di un vero e proprio attacco alla sicurezza dei dati personali, non è stato necessario applicare le procedure aziendali per la gestione dei Data Breach e, soprattutto, il problema è stato risolto velocemente… per cui che problema c’è? Agli occhi del team Privacy la valutazione di rischio del servizio è rimasta inalterata. Ma, a qualche giorno dalla pubblicazione della vulnerabilità, il responsabile del team Privacy apprende la notizia dai media e si chiede se la nostra azienda ne sia stata interessata. Seguono mail e richieste di spiegazione ai responsabili IT, i quali spiegano che sì, la loro azienda era stata interessata, ma che avevano risolto tempestivamente e che in fondo era solo una libreria per il log e pertanto qualsiasi possibilità di violazione dei dati è da escludere. Il responsabile Privacy, rassicurato, appunta la risposta e chiude il caso. 

Possiamo stare davvero tranquilli?

Seppur minimo, il rischio c’è stato. E il fatto che le vulnerabilità vengano pubblicate solo dopo essere state scoperte, ci porta a pensare che fino a quando non si agisce per prevenire l’attacco si è sempre esposti alla vulnerabilità. Nel caso di Log4j lo sfruttamento di questa vulnerabilità offriva all’attaccante un grandissimo ventaglio di opportunità, tra cui la possibilità di accedere ai dati personali gestiti dal nostro servizio o potenzialmente raggiungibili tramite esso. Da questo si deduce che se il team Privacy lo avesse saputo, e soprattutto lo avesse saputo in tempo, avrebbe sicuramente rivisto la valutazione di rischio del servizio e contestualmente avrebbe avviato le procedure per verificare una possibile violazione dei dati informando, se ritenuto necessario, le parti (in primis il titolare che è tenuto al rispetto degli obblighi di notifica delle violazioni) al fine di predisporre le adeguate misure organizzative e tecniche. Allo stesso modo, dopo la risoluzione tecnica, il team Privacy avrebbe dovuto aggiornare nuovamente la valutazione di rischio del nostro servizio. Nella nostra azienda, volutamente fittizia, tutto questo non è accaduto (per fortuna!) e di fatto la nostra organizzazione non ha conservato traccia di questo episodio e ha completamente ignorato potenziali esposizioni dei dati.

Il caso raccontato è frutto di fantasia, ma potrebbe essere accaduto nella tua azienda: sicurezza informatica esicurezza dei dati personali non sono sinonimi, ma hanno sicuramente delle forti implicazioni reciproche.Le differenze culturali tra i componenti dei team IT e Privacy costituiscono un impedimento. Infatti, i team IT tendono a risolvere gli incidenti informatici e a trascurare l’impatto sui dati personali che questi possono causare, mentre i team Privacy non comprendono la natura tecnica degli incidenti e si affidano ai controlli degli assessment di rischio per valutare l’efficacia dei sistemi. Per di più i due team utilizzano vocaboli (es. rischio) a cui associano molto di frequente significati non completamente coincidenti.