Log4Shell: la patch del 2021 potrebbe non esserci più

Se avete sistemi Java in produzione, nel dicembre 2021 qualcuno in azienda ha messo mano a Log4j. Ha aggiornato la libreria, oppure ha modificato a mano il pacchetto applicativo, oppure ha scritto una regola sul firewall applicativo. Poi ha chiuso il ticket, ha scritto due righe nella comunicazione alla direzione, e si è passati avanti.

Quel ticket chiuso è oggi l’unica prova che il problema sia stato risolto, e in un numero non trascurabile di casi non è più vero. Non perché l’intervento fosse sbagliato, ma perché in quattro anni è successo altro: aggiornamenti, ripristini, macchine sostituite, servizi riaccesi.

Vediamo come una patch applicata correttamente può non esserci più, perché nessuno se ne accorge, e cosa serve per verificarlo davvero.

1. Cosa si è fatto nel dicembre 2021
2. Quando un aggiornamento annulla la mitigazione
3. La patch che sembrava definitiva e non lo era
4. Le regole sul firewall che nessuno rilegge
5. Perché nessuno se ne accorge
6. Come si verifica lo stato reale

Cosa si è fatto nel dicembre 2021

Le strade praticabili in quei giorni erano quattro, e la scelta dipendeva da quanto si poteva intervenire.

Aggiornare la libreria era la soluzione migliore, e funzionava dove l’applicazione era gestita internamente e c’era un ambiente di collaudo in cui provare. Chi non poteva aspettare un rilascio del fornitore ha modificato il pacchetto applicativo a mano, disattivando la funzione all’origine del difetto. Chi non poteva toccare nemmeno quello ha messo una regola sul firewall applicativo per fermare le richieste sospette in ingresso. Chi non poteva fare nessuna delle tre cose ha spento il servizio o lo ha isolato dalla rete.

Solo la prima è una correzione: le altre tre sono contenimento. La vulnerabilità resta dove è, e viene semplicemente reso più difficile arrivarci. Nelle intenzioni erano tutte misure temporanee, da mantenere il tempo necessario ad arrivare a una versione aggiornata.

Questa distinzione conta perché una correzione, una volta applicata, resta. Una misura di contenimento invece dipende da una configurazione, e le configurazioni si perdono. Vale la pena ricordare che la stessa logica governa la gestione di tutte le vulnerabilità informatiche: quello che conta non è l’intervento, è lo stato in cui il sistema si trova adesso.

Quando un aggiornamento annulla la mitigazione

Questo è il caso che dà il titolo all’articolo, e nei test lo incontriamo con una regolarità che sorprende chi lo scopre.

Una modifica applicata a mano dentro un pacchetto applicativo non sopravvive a un aggiornamento del pacchetto. Il fornitore rilascia una nuova versione, il vostro reparto IT la installa correttamente come deve fare, e il pacchetto torna al proprio contenuto originale. La modifica del dicembre 2021 semplicemente non c’è più, e nessuno l’ha rimossa deliberatamente.

Il punto delicato è che nessun sistema segnala l’accaduto, perché dal suo punto di vista non è accaduto niente di anomalo: un aggiornamento è stato applicato, che è esattamente il comportamento corretto. Se il nuovo pacchetto include una versione aggiornata della libreria il problema non esiste, ma questo dipende dal fornitore e voi non avete modo di saperlo senza andare a controllare.

Lo stesso vale per tre situazioni che accadono continuamente. Un ripristino da backup precedente all’intervento riporta la configurazione allo stato di prima. Una macchina sostituita e riconfigurata a partire da un’immagine anteriore al dicembre 2021 nasce già senza la mitigazione. E un servizio spento in emergenza, riacceso mesi dopo perché serviva una funzione, torna online nella condizione in cui era stato lasciato.

In tutti e quattro i casi il ticket del 2021 resta chiuso e la documentazione continua a riportare che l’intervento è stato eseguito. Che è vero: è stato eseguito, e poi annullato. È la stessa asimmetria che si osserva sui componenti di terze parti, dove quello che è stato configurato una volta non coincide con quello che è attivo oggi.

La patch che sembrava definitiva e non lo era

Il secondo caso riguarda chi ha fatto la cosa giusta nel momento giusto, e proprio per questo è convinto di aver chiuso.

La prima versione correttiva è uscita pochissimi giorni dopo la divulgazione, sotto una pressione enorme. Non copriva tutti i casi, e nelle settimane successive sono servite altre versioni prima di arrivare a una considerata risolutiva per l’insieme delle vulnerabilità della serie.

Chi ha aggiornato immediatamente, come era corretto fare, ha applicato una correzione parziale. E l’ha applicata nel momento in cui l’attenzione mediatica era massima, quindi con la percezione netta di aver risolto l’emergenza.

Le versioni successive uscite a gennaio non hanno avuto la stessa risonanza. Su un sistema che risultava già aggiornato nessuno è andato a verificare a quale versione fosse arrivato, perché la voce nell’elenco delle cose da fare era già barrata. Il risultato è un parco applicativo dove convivono versioni corrette e versioni corrette a metà, senza che la differenza sia registrata da nessuna parte.

Quali versioni siano interessate e quale sia lo stato di ciascuna è dettagliato nell’articolo su cos’è Log4Shell e chi colpisce.

Le regole sul firewall che nessuno rilegge

Chi ha risolto con una regola sul firewall applicativo si trova oggi con quella regola ancora attiva, e con due domande a cui in genere non sa rispondere.

La prima è se serve ancora. Se nel frattempo la libreria è stata aggiornata da un rilascio del fornitore, quella regola è diventata inutile e continua a essere valutata su ogni richiesta in ingresso. Se invece la libreria non è mai stata aggiornata, quella regola è l’unica cosa che sta tenendo, e questo cambia completamente la valutazione del rischio su quel sistema.

La seconda è cosa blocca esattamente. Le regole scritte in quei giorni erano larghe per prudenza, e in qualche caso fermano anche richieste legittime che contengono sequenze simili. Quando succede, il sintomo arriva come una segnalazione di malfunzionamento applicativo, e nessuno la collega a una configurazione di quattro anni prima.

Il modo per uscirne è una domanda sola: se togliessi questa regola domani, cosa resterebbe esposto? Se la risposta non è immediata, quella non è una mitigazione, è una dipendenza di cui non conoscete il peso. Verificarlo richiede di provare cosa passa e cosa no, che è parte di quello che fa un Web Application Penetration Test.

Perché nessuno se ne accorge

Le ragioni sono strutturali e valgono per qualsiasi emergenza di sicurezza, non solo per questa.

La prima è che l’emergenza produce documentazione dell’intervento, non dello stato. Il ticket registra che qualcuno ha fatto qualcosa in una certa data. Non registra che quella cosa sia ancora vera oggi, e non esiste un processo che vada a ricontrollarlo.

La seconda è che le verifiche successive partono da quella documentazione. Quando arriva un audit o un questionario di sicurezza da parte di un cliente, la risposta viene compilata leggendo i ticket. La domanda è se l’azienda ha gestito Log4Shell, e la risposta documentata è sì, il che è formalmente corretto e sostanzialmente non informativo.

La terza è che i sistemi interni non vengono guardati. Dopo il dicembre 2021 la corsa all’aggiornamento ha riguardato il perimetro raggiungibile da internet, che era la priorità giusta in quel momento. Strumenti di gestione, sistemi di monitoraggio e apparati che parlano solo con la rete interna sono stati controllati meno, e chi ha già ottenuto un accesso trova lì una vulnerabilità con punteggio dieci ancora sfruttabile.

La quarta è che nessuno ha più scritto niente sul tema. Se cercate informazioni su Log4Shell trovate decine di articoli del dicembre 2021 e quasi nulla dopo. L’argomento è uscito dal radar collettivo mentre era ancora aperto nei sistemi.

Come si verifica lo stato reale

I passaggi sono tre, e il primo è quello che manca più spesso.

Il primo passaggio è l’unico che non si può saltare, ed è quello che richiede più tempo. Un’azienda che ha sviluppato internamente le proprie applicazioni può andare a guardare le dipendenze e togliersi il dubbio. Per i software commerciali, gli apparati con firmware Java e i servizi erogati da fornitori, la libreria c’è ma non compare in nessun inventario, e va cercata. È il tipo di ricognizione con cui comincia un penetration test: prima si stabilisce cosa esiste davvero, poi si decide cosa testare.

Per i sistemi dove l’aggiornamento resta impossibile, come le applicazioni su misura senza più manutenzione o gli apparati il cui produttore non rilascia più firmware, la strada è il contenimento. Ma un contenimento scelto e documentato, non un residuo del 2021: il tema è affrontato nell’articolo sulle vulnerabilità che non si possono correggere.

Log4Shell è utile come esempio proprio perché l’emergenza è finita da tempo. Nessuno ne parla più, e questo permette di vedere con chiarezza cosa resta nei sistemi quando l’attenzione si sposta altrove. La prossima vulnerabilità di questa portata seguirà lo stesso percorso: settimane di interventi rapidi, poi silenzio, e fra qualche anno nessuno saprà più cosa è stato fatto davvero.