CrowdStrike ha pubblicato un resoconto che spiega cosa sia successo, nel dettaglio, quando è stato rilasciato l’aggiornamento difettoso che ha causato il blocco di 8,5 milioni di macchine Windows lo scorso venerdì. La società ha individuato la causa principale in un bug presente nel software di test che ha mancato di validare correttamente l’aggiornamento rivelatosi poi difettoso.
Lo scorso venerdì 19 luglio CrowdStrike ha rilaciato un aggiornamento automatico per il software Falcon, utilizzato largamente da aziende anche di alto profilo per la sicurezza degli endopoint Windows. Secondo le dichiarazioni della società questo aggiornamento avrebbe avuto lo scopo di “raccogliere dati di telemetria su possibili nuove tecniche di minaccia”. Si tratta invero di operazioni abituali, ma questa volta qualcosa è andato storto, portandosi dietro le conseguenze che abbiamo conosciuto.
CrowdStrike fa uso di due metodi distinti per rilasciare gli aggiornamenti di configurazione. Il primo, denominato Sensor Content, aggiorna direttamente il sensore Falcon che opera a livello di kernel in Windows. Il secondo, chiamato Rapid Response Content, modifica il comportamento di quel sensore per ottimizzare il rilevamento del malware. Ed è stato proprio un piccolo file Rapid Response Content, di soli 40KB, a scatenare il caos lo scorso venerdì.
CrowdStrike gestisce un sistema proprietario che esegue controlli di convalida sui contenuti prima del rilascio, esattamente con l’obiettivo di prevenire incidenti come quello che si è invece verificato. La scorsa settimana la società ha rilasciato due aggiornamenti Rapid Response Content, noti anche come Template Instances: una di queste due ha superato la convalida del sistema di controllo, nonostante contenesse alcuni problemi. Proprio questi problemi hanno causato il famigerato Blue Screen of Death di Windows, per via di un comportamento non previsto dovuto ad una lettura out-of-bounds della memoria.
La società ha inoltre sottolineato il proprio impegno a migliorare il processo di testing e distribuzione degli aggiornamenti per evitare che situazioni come quella di venerdì dovessero riproporsi in futuro. Oltre ad una revisione dei testing su Rapid Response Content, implementando anche i test di sviluppatori locali e rollback dei contenuti, assieme a test di stabilità e stress test, la società adotterà anche un meccanismo di distribuzione degli aggiornamenti a scaglioni, evitando di inviare l’aggiornamento contemporaneamente a tutti i sistemi.
Ciò che comunque, a valle di tutto, desta maggior perplessità è il fatto che evidentemente il meccanismo di validazione utilizzato da CrowdStrike non effettua nessun genere di test su macchine in produzione: sarebbe bastato un solo test, magari “a mano”, su una singola macchina per accorgersi del problema…