Ciao a tutti e benvenuti in questo mio nuovo post. È ormai da quasi un anno che in questo blog non scrivo più nulla. Sono tornato a distanza di ben 10 mesi (una lunga assenza) per parlarvi di una nuova problematica di sicurezza che è comparsa circa 3 giorni fa.
Non sono solito parlare di problematiche software subito, in quanto preferisco sempre attendere per avere maggiori informazioni e poi eventualmente, se ne vale la pena, andare ad approfondire l’argomento. Infatti questo non è un blog dove vengono pubblicate delle notizie (anche perché con 10 mesi di assenza che notizie si vogliono pubblicare), ma è un posticino dove pubblico quando ne vedo l’esigenza, degli approfondimenti. Andiamo ad approfondire infatti alcune dinamiche particolari che riguardano la tecnologia e che credo possano essere meritevoli di essere approfondite.
Ma con oggi faccio “uno strappo alla regola”. Infatti sono qui a parlare di questo argomento veramente a distanza di neanche 3 giorni.
Che cosa sarebbe Log4J?
Innanzi tutto dobbiamo capire che cosa sarebbe Log4J. Questo non è il nome della breccia o dell’exploit, ma è il nome di una libreria Java utilizzata dalla maggior parte degli sviluppatori che programmano con questo linguaggio, per effettuare attività di debug. Molto spesso infatti quando si sviluppa un’applicazione ci possono essere determinati errori. È normale, fa parte del rischio e del lavoro di ogni sviluppatore la fuori (me incluso). L’unico modo per sapere cosa causi quello specifico errore è fare del buono e sano debug. In pratica si fa in modo di registrare in un log (che in inglese significa letteralmente registro) tutta una serie di informazioni. Queste informazioni possono essere:
- Il nome del file e se viene rilevata anche la riga di codice che causa l’errore
- Il problema che si sta verificando (dalla riga di codice scritta male al parametro che non viene correttamente processato ecc…)
- Il semplice avviso o la semplice attività svolta
Infatti il log non registra solo gli errori o gli avvisi. Registra ogni singola attività o singola operazione che viene svolta dal software. Ogni avviso poi viene associato ad un codice e questo codice identifica se l’avviso è: un errore, un avviso o una semplice attività andata a buon fine (forse, non si può mai sapere) e quindi semplicemente registrata all’interno del registro stesso.
In java per effettuare attività di debug viene utilizzato Log4J, una libreria con tutta una serie di funzionalità pensate per fare questo e farlo bene. Quindi è per questo che la stragrande maggioranza degli sviluppatori utilizzano questa specifica risorsa. Il problema poi è che solitamente questa libreria non viene rimossa dopo aver completato lo sviluppo di un software. Molti infatti mantengono nel programma questa risorsa per continuare ad avere la possibilità di monitorare l’andamento di un software. Questo peraltro è fondamentale in algoritmi piuttosto complessi che effettuano decine di migliaia di operazioni su ogni singolo dato (pensiamo ad esempio agli algoritmi dei social network o all’algoritmo di una qualche sonda spaziale della Nasa).
Che problema ha questa libreria?
È stata individuata una grave falla di sicurezza all’interno di Log4J che consentirebbe a chiunque malintenzionato e con sufficienti capacità informatiche di riuscire a sfruttare questa libreria pensata appunto per riportare eventi in un file di registro, di andare a inviare comandi alla macchina. In pratica si andrebbe a sfruttare un componente di per se innocuo per effettuare operazioni che possono risultare piuttosto pericolose per la vittima. Le azioni che si possono effettuare sono molteplici tra le quali:
- Rubare informazioni
- Usare la macchina della vittima come botnet (quindi come macchina per effettuare attacchi informatici o operazioni non consentite dal proprietario stesso)
- Danneggiare la reputazione della vittima
- Danneggiare i clienti
Dagli ultimi 2 punti potreste aver capito che questa vulnerabilità affligge principalmente i provider di servizi. Infatti Log4J viene implementato nei backend delle applicazioni e non nei frontend. Per chi non lo sapesse il backend sarebbe l’algoritmo dell’applicazione. Il frontend invece l’interfaccia grafica che va a rappresentare i dati elaborati dal backend.
Essendo una vulnerabilità che colpisce i provider dei servizi accadono le seguenti 2 cose:
- I clienti a loro volta possono risultare vittime, in quanto non sono al sicuro e non possono farci nulla e molto spesso sono anche ignari
- Possono essere effettuati attacchi multipli. Infatti sfruttando questa vulnerabilità per attaccare il backend di un importante provider di un servizio noto, si possono attaccare centinaia se non migliaia di clienti contemporaneamente, prima che il provider se ne possa accorgere
Come si risolve il problema?
Ci sono un paio di aspetti da tenere in considerazione. Il problema di per se è “facilmente” risolvibile. Infatti bisogna semplicemente aggiornare la libreria Log4J all’ultima versione o cambiare libreria di debug e il gioco è presto fatto. Ma appunto ho messo la parola facilmente tra apici e ci sono svariati motivi.
Il primo tra tutti è che bisognerà intervenire su ogni backend di ogni applicazione sviluppata da un’azienda. Non è sempre facile in quanto un’azienda dispone di un numero limitato di persone e magari nel corso degli anni ha sviluppato un numero enorme di progetti, diversificati tra di loro.
Molti progetti poi utilizzano a loro volta delle librerie o dei software (dette dipendenze di terze parti) che quindi essendo sviluppate da terzi non sono sviluppate dall’azienda stessa. Ed è anche molto probabile che queste dipendenze sono fondamentali. Il problema qui è duplice: da una parte non sempre si possono sostituire queste dipendenze in quanto non ci sono delle alternative o non le si conoscono. Il secondo è l’impossibilità di sapere se le librerie che si stanno usando usano Log4J o se le librerie / dipendenze in uso hanno a loro volta delle libreria / dipendenze che ne fanno uso. È un problema così su larga scala che è praticamente impossibile sostituire tutte le parti di ogni applicazione.
Per ultimo (ma non per importanza) troviamo tutta una serie di progetti detti legacy, ovvero piuttosto datati e che non vengono più aggiornati da anni se non decenni. Sono principalmente driver, firmware, sistemi a basso livello, librerie che si occupano di far funzionare specifici dispositivi o che permettono l’implementazione di singole funzionalità all’interno di un’applicativo su un determinato dispositivo. In questo caso essendo progetti ormai fermi da decenni, dove i relativi sviluppatori (molto spesso lo sviluppatore, visto che spesso sono progetti portati avanti da una singola persona) sono ormai in pensione o comunque non più reperibili e che solo loro sapevano dove metterci le mani. Pensate che questi sistemi a basso livello sono alla base del funzionamento di moltissimi dispositivi, anche IoT. Quindi dovremmo paradossalmente dover aggiornare tutto. In questo caso quindi diventa praticamente impossibile pensare di risolvere il problema, chiudere la falla di sicurezza “con un semplice aggiornamento”, come siamo da sempre abituati ormai. Pensate
Ma si risolverà?
Per la maggior parte dei servizi più importanti la falla di sicurezza è già stata risolta in quanto gli amministratori di sistema e i relativi sviluppatori si sono già messi all’opera. Potrebbe essere richiesto, per i clienti, un aggiornamento dell’applicazione lato client per allinearsi alla nuova versione del backend remoto. Ma per tutta una serie di altri progetti, magari meno famosi o per tutta una serie di tecnologie meno recenti (legacy), certo nel corso dei mesi se non anni verranno pian piano coperti con la patch, ma ci vorrà tempo. Diciamo che sarà una parabola in costante aggiornamento.
Cosa si deve fare?
Se siete customers (clienti) molto probabilmente non dovrete fare assolutamente nulla. In caso contrario dovrete aggiornare all’ultima versione un eventuale software che usate (seguite le linee guida del vostro fornitore) o se siete sviluppatori che state sviluppando la vostra applicazione… beh auguri 🙂
Se siete fornitori di servizi, c’è da controllare se nei vostri sistemi usate strumenti in java e nel caso applicarvi per risolvere. Come per il caso dei clienti.. auguri.
Che cos’è Log4Shell?
Log4Shell è un exploit che è stato sviluppato per sfruttare le vulnerabilità di Log4J. Il problema è che piuttosto facile da usare, per un eventuale malintenzionato e questo è un problema di per se.
Per maggiori informazioni vi rimando all’articolo di Kaspersky, che spiega piuttosto bene l’argomento.
E niente gente… benvenuti in una nuova giornata strana sulla sicurezza informatica. Dai che come tutte le varie problematiche inerenti alla cyber security, ne usciremo. Per tutti i nostri clienti, siamo pronti ad affrontare questa nuova sfida.
