Articolo Pubblicazioni

Log4Shell: come gestire una vulnerabilità che è ovunque

di · Pubblicato il 30 dicembre 2021

Abstract

Il 9 dicembre 2021 è stata resa pubblica una vulnerabilità nella libreria Java Apache Log4j 2 che permette a un attaccante di eseguire codice su un server semplicemente facendogli registrare una stringa. L’articolo spiega il meccanismo, ricostruisce le tre settimane successive con le versioni correttive e le nuove vulnerabilità collegate, descrive le mitigazioni e i metodi di rilevamento e trae le lezioni per la gestione delle vulnerabilità nei componenti software.

Vincenzo Calabrò | Log4Shell: come gestire una vulnerabilità che è ovunque
 

Che cosa è successo

Log4j è una libreria open source della Apache Software Foundation che i programmi Java usano per scrivere i messaggi di log. È presente in applicazioni aziendali, prodotti commerciali, servizi cloud, apparati di rete, videogiochi. Il 9 dicembre 2021 è stata pubblicata una vulnerabilità nella versione 2 della libreria, identificata come CVE-2021-44228 e chiamata Log4Shell, con il punteggio massimo di 10 nella scala CVSS. Era stata segnalata alla fondazione il 24 novembre da un ricercatore del team di sicurezza di Alibaba Cloud. I primi sfruttamenti pubblici sono stati osservati nei server del videogioco Minecraft, dove bastava scrivere una stringa nella chat.

Il meccanismo

Log4j 2 interpreta alcune espressioni contenute nei messaggi da registrare, le cosiddette lookup. Una di queste, ${jndi:...}, fa sì che la libreria contatti un servizio esterno tramite l’interfaccia Java JNDI, per esempio un server LDAP. Se l’attaccante controlla quel server, può restituire un riferimento a una classe Java che il programma vulnerabile scarica ed esegue. Basta quindi che un dato controllato dall’esterno, come un’intestazione HTTP, un nome utente o un campo di un modulo, finisca in un messaggio di log perché l’attaccante ottenga l’esecuzione di codice sul server. Non serve autenticazione e non serve conoscere l’applicazione.

Tre settimane di correzioni

Le versioni correttive si sono succedute rapidamente, perché ogni intervento ha rivelato nuovi problemi:
  1. la 2.15.0, pubblicata in corrispondenza della divulgazione, limita le lookup JNDI;
  2. la 2.16.0, del 13 dicembre, disattiva JNDI per impostazione predefinita e rimuove le lookup nei messaggi, dopo la scoperta della CVE-2021-45046 che aggirava la prima correzione in alcune configurazioni;
  3. la 2.17.0, del 17 dicembre, corregge la CVE-2021-45105, un problema di ricorsione infinita che provoca un blocco del servizio;
  4. la 2.17.1, del 28 dicembre, corregge la CVE-2021-44832, sfruttabile solo da chi può modificare la configurazione dei log.
Log4Shell riguarda la sola versione 2. La versione 1 è priva di aggiornamenti dal 2015 e ha vulnerabilità proprie, tra cui la CVE-2021-4104 pubblicata nello stesso mese. Chi la usa ancora dovrebbe pianificarne la sostituzione.

Mitigazioni temporanee

Quando l’aggiornamento non è possibile subito, le mitigazioni indicate da Apache e dai CSIRT nazionali sono queste:
  • rimuovere la classe JndiLookup dal file della libreria, misura efficace per le versioni dalla 2.10 in poi;
  • limitare le connessioni in uscita dei server verso Internet, in particolare sui protocolli LDAP e RMI;
  • applicare regole sui web application firewall per bloccare le stringhe di attacco, sapendo che esistono molte varianti offuscate;
  • separare i sistemi esposti da quelli interni, per ridurre l’impatto in caso di compromissione.
L’impostazione formatMsgNoLookups, suggerita nei primi giorni, si è rivelata insufficiente e non va considerata una protezione.

Rilevare i tentativi

La ricerca di attacchi va fatta in due direzioni. Nei log delle applicazioni e dei proxy si cercano le stringhe che iniziano con ${jndi: e le loro forme offuscate, come quelle che usano ${lower:} o ${::-j} per spezzare le parole. Nei log del firewall si cercano connessioni in uscita verso indirizzi sconosciuti sulle porte LDAP, RMI e DNS a partire dai server applicativi. Un tentativo registrato indica soltanto che il sistema è stato preso di mira. Una connessione in uscita riuscita verso il server dell’attaccante richiede un’analisi approfondita del sistema. Nelle prime settimane gli sfruttamenti osservati hanno installato soprattutto programmi per minare criptovalute e agenti di botnet, e sono stati segnalati tentativi legati a ransomware.

Il vero problema è l’inventario

Per molte organizzazioni la domanda più difficile è stata sapere dove si trovasse Log4j. La libreria è spesso inclusa all’interno di altri componenti, a volte a più livelli di profondità, e compare in prodotti di terze parti di cui il cliente non vede il codice. Un inventario degli asset fermo ai server e ai sistemi operativi non aiuta. Servono strumenti che analizzino i file delle applicazioni, compresi gli archivi Java annidati, e soprattutto l’elenco dei componenti fornito dai produttori.
È qui che entra in gioco la Software Bill of Materials, l’elenco strutturato dei componenti di un prodotto software. Negli Stati Uniti l’ordine esecutivo del maggio 2021 sulla sicurezza informatica ne ha previsto l’adozione per il software acquistato dalle agenzie federali, e la NTIA ha pubblicato a luglio gli elementi minimi. Log4Shell ha mostrato in modo concreto a che cosa serve. Chi disponeva di SBOM aggiornate ha saputo in poche ore quali sistemi erano coinvolti.

La risposta delle autorità

Il CSIRT Italia ha diffuso un allarme nei giorni immediatamente successivi alla divulgazione e ha aggiornato le indicazioni man mano che uscivano nuove versioni. Negli Stati Uniti la CISA ha emesso il 17 dicembre una direttiva di emergenza che impone alle agenzie federali di individuare i sistemi vulnerabili, applicare correzioni o mitigazioni e riferire entro scadenze precise, e ha pubblicato un elenco dei prodotti coinvolti alimentato dai produttori. In Europa altri CERT nazionali hanno fatto lo stesso. Per un’organizzazione italiana la fonte più affidabile resta l’avviso del produttore di ciascun prodotto, perché solo il produttore sa se e come la libreria viene usata al suo interno.

Le lezioni

Il caso lascia alcune indicazioni pratiche per chi gestisce la sicurezza. Conviene chiedere ai fornitori un elenco dei componenti e un impegno sui tempi di risposta alle vulnerabilità. Le connessioni in uscita dei server vanno limitate a ciò che serve, perché molte catene di attacco richiedono di scaricare qualcosa dall’esterno. Infine una libreria mantenuta da pochi volontari può reggere una parte rilevante dei servizi digitali, e il sostegno ai progetti open source critici diventa una questione di sicurezza collettiva.
 
 
Vincenzo Calabrò | Ingegnere informatico specializzato in sicurezza informatica e investigazioni digitali. Funzionario informatico del Ministero dell'Interno; su incarico autorizzato si occupa di sicurezza informatica e di perizie informatiche forensi. Autore di articoli e saggi. Lecturer, Speaker, Trainer.
Profili: Google Scholar · ORCID · ResearchGate · Academia.edu · CyberSecurity360 · AgendaDigitale · ICT Security Magazine · LinkedIn