Dopo soli sei mesi di allarmismo e di commenti sul potenziale impatto dell’AI sulla sicurezza globale dei sistemi digitali è arrivata la prima crisi globale dovuta all’impiego dell’AI in termini di sicurezza, e come tutti ormai sappiamo due vulnerabilità di PHP hanno impattato quello che si stima essere il 70% circa del Web.
La maggior parte delle organizzazioni a livello globale hanno reagito all’annuncio sospendendo i propri servizi Web e provvedendo all’aggiornamento, ma siamo pronti a fronteggiare questo nuovo tipo di crisi? Non credo di avere ricette magiche, ma posso sicuramente raccontare la mia personale esperienza nella gestione della crisi presso l’Università di Pisa.
Indice degli argomenti
Vulnerabilità PHP e il tam tam della crisi globale
Come tutte le organizzazioni e soprattutto quelle che sono impegnate nella piena attuazione della direttiva NIS 2 in qualità di soggetto importante, il personale tecnico dell’Università monitora costantemente i vari siti con aggiornamenti di varia natura, partendo ovviamente da una valutazione supportata dall’AI dell’impatto sui nostri sistemi di ciascuna CVE rilasciata.
Le CVE sono però sempre più numerose e quando un’organizzazione gestisce migliaia di apparati e decine se non centinaia di tecnologie differenti si trova rapidamente nel quadrante in cui deve valutare elevati numeri di vulnerabilità e i relativi impatti per decidere una priorità nell’aggiornamento dei sistemi.
Ma quando un software alla base di molti servizi Web come PHP annuncia una vulnerabilità critica che consente l’esecuzione di codice remoto in server Web senza neanche essere autenticati allora la notizia non arriva da una CVE, ti telefonano in tanti dicendo “bisogna aggiornare”.
Improvvisamente la tua giornata cambia corso e cominci a seguire le normali procedure in una situazione di crisi: fai l’assessment della superficie di potenziale impatto, decidi se il rischio è tale da giustificare il fermo di più di mille siti Web della tua organizzazione, e soprattutto valuti le potenziali remediation.
Il rischio dell’esecuzione di codice remoto
Ho vissuto numerose situazioni di crisi negli ultimi anni, ma questa era la mia seconda crisi globale (la precedente era stata nel febbraio 2022 con la vulnerabilità di log4j) e soprattutto il rischio di esecuzione di codice remoto via Web è tra le peggiori notizie che si possano ricevere perché il Web è largamente aperto a Internet offrendo un vettore di attacco enorme.
Procedure interne e comunicazione sugli hack generati dall’AI
La gestione della crisi è stata anche un’occasione per rivedere le procedure interne in materia di cybersecurity, sia dal punto di vista decisionale che poi nella comunicazione con l’utenza. Dopo pochi minuti è stato più che evidente che era opportuno non prendere rischi soprattutto per la confusione che imperava sulla disponibilità di hack generati da AI e che sembrava avrebbero compromesso il Web nell’arco di poche ore (spoiler: successivamente si è scoperto che la maggior parte di questi hack semplicemente non funzionavano e le due vulnerabilità erano molto più difficili da sfruttare da quanto la comunicazione globale lasciasse intendere).
Le notizie sul sito di PHP non erano particolarmente rassicuranti e anche i sommari delle vulnerabilità rendevano difficile comprendere se fossero direttamente utilizzabili e in che condizioni. Non sorprende quindi che tutti abbiano considerato l’opzione di spegnere ed aggiornare anche se la PHP Foundation informava che le versioni di PHP 8.1 e precedenti non avrebbero ricevuto aggiornamenti dalla fondazione.
CMS e sistemi legacy davanti alle falle di PHP
La valutazione di impatto è un’attività che deve essere svolta tempestivamente in una situazione di crisi, e quando l’impatto non è direttamente collegato ad un sistema in uso ma bensì al runtime su cui questo si basa è un’attività difficile da condurre.
Non stupisce quindi che la reazione globale sia stata spegnere e aggiornare per non prendersi rischi inutili.
In effetti come si giudica se un CMS popolare come Wordpress (o uno dei suoi plugin) sia effettivamente esposto ad una vulnerabilità di PHP? La semplice valutazione avrebbe richiesto ore o giorni che nessuno si poteva permettere. È il prezzo da pagare per l’uso di framework che un tempo si comprendevano ma oggi sono divenuti troppo complessi da conoscere per effettuare valutazioni specifiche.
Versioni obsolete e patch non disponibili
Ma cosa succede quando la tua organizzazione usa PHP sin dai tempi delle prime tecnologie per la generazione di pagine dinamiche? Nelle centinaia di siti Web che si sono accumulati nel tempo si ha la certezza di poter ricostruire tutta la storia di PHP in termini di versioni installate, o quasi.
Ecco quindi che le grandi organizzazioni come la nostra si sono trovate a fronteggiare il problema di come gestire sistemi con versioni di PHP per cui la patch non era stata rilasciata ma sicuramente vulnerabili visto che il problema era presente da circa dieci anni nel codice di PHP.
In alcuni casi si tratta di sistemi non aggiornati perché semplicemente non si aveva la forza di farlo, ma per quei sistemi sviluppati internamente in PHP il problema da fronteggiare è stato sicuramente quello di provare la nuova versione di PHP per scoprire che i cambiamenti, anche semplicemente dalla versione 7.4, erano tali da richiedere una particolare riscrittura del software.
E qui si apre un dilemma: come ci si comporta con servizi di un’organizzazione che non possono essere semplicemente patchati a fronte di una crisi globale? Si sospendono i servizi a data da destinarsi? O si cercano soluzioni per impedire pattern specifici nelle richieste Web che possano bloccare o comunque rendere difficile lo sfruttamento della vulnerabilità?
La risposta operativa dell’Università di Pisa
Queste sono le domande che hanno dovuto affrontare i tecnici nelle ore successive al tam tam, e ciascuna organizzazione ha trovato, immagino, il proprio mix di soluzioni. I tecnici dell’Università sono stati assolutamente straordinari, lavorando ben oltre l’orario previsto per passare a pettine tutti i sistemi e apportare gli aggiornamenti, o per debuggare ed aggiornare il codice. In poco più di 24 ore la maggior parte dei servizi dell’Ateneo era già tornata pienamente operativa ed in sicurezza.
Le lezioni delle vulnerabilità PHP per la sicurezza IT
Questa crisi globale ritengo che ci abbia insegnato (o ricordato) alcune lezioni fondamentali che vanno tenute presenti nella gestione dei sistemi IT in un mondo in cui le vulnerabilità vengono scoperte a ritmi senza precedenti grazie all’AI. La mia prima lezione è sicuramente stata che quando una vulnerabilità è sufficientemente diffusa potresti trovarti nella situazione in cui non hai abbastanza persone per poter intervenire tempestivamente.
Abbiamo costruito i nostri sistemi con l’assunzione che “stanno su” da soli e che i tecnici intervengono a fronte di malfunzionamenti, ora l’inventariazione e la disponibilità di kill switch selettivi sembra necessaria per fronteggiare queste crisi. Se infatti cinque anni fa l’annuncio di una vulnerabilità non portava necessariamente a conseguenze immediate l’AI ha cambiato completamente lo scenario: si è consapevoli che poche ore dopo il rilascio dei dettagli può essere sfruttata su scala globale.
Sistemi legacy e siti storici da spegnere
La seconda lezione è che non possiamo più permetterci di tenere sistemi legacy solo per inerzia: chi non ha rimandato la decisione di spegnere un servizio, magari obsoleto, per evitare frizioni all’interno dell’organizzazione? Ora questa diviene un’opzione non più percorribile, così come tenere siti Web basati su CMS online per semplici ragioni storiche, è necessario renderli statici per minimizzare i rischi connessi a stack software non più mantenuti.
Nuove falle in PHP: perché è solo l’inizio
E se il 23 ottobre cominci a rivedere la luce dopo l’annuncio delle due vulnerabilità del 21 ottobre non è confortante che il tam tam ricominci perché emerge una nuova vulnerabilità sempre di PHP e per cui non è ancora nemmeno disponibile una patch.
E allora ricominci le valutazioni con le informazioni a tua disposizione consapevole che non hai vissuto una situazione eccezionale, è solo che il mondo è cambiato e che l’AI sicuramente potrà migliorare molte cose, ma ha cambiato il mondo della gestione dei sistemi per sempre e quella che prima era l’eccezione sembra rapidamente divenire la nuova norma.
Partecipa alla community