È da quando si è avuta notizia dell’attacco ai sistemi della Regione Lazio che seguo e leggo tutti i commenti e tutti gli esperti che come sempre sanno come si doveva fare e cominciano il linciaggio mediatico senza avere una concreta idea di cosa stia succedendo e postulando cosa sia accaduto assumendo modelli di attacco a volte imbarazzanti, perché è il ransomware è un software che si può conoscere, ma il suo uso è ben lontano da essere scontato in un attacco in cui viene lanciato solo dopo aver riconfigurato i sistemi.
L’anno scorso mi sono trovato coinvolto direttamente in una situazione analoga, sistemi giù, tutti esperti, e chi sta lavorando cerca di capire, stimare e trovare contromisure per ripristinare servizi critici senza una reale idea di quando si vedrà la luce. Non posso che solidarizzare con il personale che ha dovuto fronteggiare la situazione con tutta la pressione mediatica, non sapendo se e come ritirare i sistemi su e stimando il danno con la necessità di politici e governatori di dire qualcosa, e avidi ascoltatori pronti a leggere nelle dichiarazioni di governatore e assessori limiti tecnici e inadempienze.
Regione Lazio e ransowmare, lieto fine amaro: troppi errori fatti
Quando poi ho letto il post di Corrado Giustozzi su LinkedIn che comunicava il recupero dei backup ho tirato un sospiro di sollievo salvo poi assistere ad una macelleria di complottismo insinuare che si trattasse di un post di copertura, addirittura basato sull’autorevolezza di chi lo aveva fatto.
Ho pensato di condividere le mie riflessioni da tecnico che in alcune occasioni si è trovato ad affrontare situazioni simili e leggere le informazioni pubblicamente note con l’occhio di un tecnico prendendo spunto da uno degli ultimi articoli che fanno il punto sullo stato.
L’inizio di un attacco
Quando un attacco inizia sembra di vivere uno di quei film catastrofici dove qualche primo segnale di malfunzionamento provoca qualche spalluccia da parte di chi riceve le notifiche, pensando che è necessario riavviare qualche servizio perché si è bloccato e senza rendersi conto che un enorme vulcano si sta formando proprio nel bel mezzo dei tuoi servizi.
Nelle prime comunicazioni è emerso che la possibile falla era quella di un dipendente che dallo smart-working aveva eseguito il fatidico ransomware che aveva crittografato tutto. Magari il mondo fosse così semplice ancora, un datacenter che funziona come un ordinario PC e tutti immagino lo smart-worker che come Pippo al suono di “Yuk! Yuk!” clicca sulla mail di phishing che in pochi minuti crittografa petabyte di dati.
Per quanto possa essere disastrato lo stato di un sistema dopo vent’anni di Active Directory e accesso basato su ruoli è difficile immaginare che tutti i sistemi fossero accessibili con l’account di uno smart worker, tra l’altro se così fosse si tratterebbe di uno smart worker con una linea di casa invidiabile: se il processo del ransomware esegue dal suo PC la crittografia va alla velocità della sua connessione. Certo, è possibile che il potentissimo software ispezioni la rete a cui ha accesso tramite VPN e esegua copie di sé su tutti i nodi a cui ha accesso con i privilegi dell’utente.
Se questo fosse lo scenario l’infezione dovrebbe essere contenuta a meno che il ransomware si appoggi a vulnerabilità che consentono l’escalation e che gli script di analisi e di replica siano efficaci in un ambiente che per sua natura è eterogeneo sia nei sistemi che nel loro stato di aggiornamento.
Per ottenere un effetto così efficace in breve tempo è necessario che l’attacco sia volto a prendere il controllo di una postazione da utilizzare come ponte per indebolire le difese interne e massimizzare l’impatto nell’eseguire il software di cryptolocker e quindi poter ricattare avendo reso inusabili quanti più file possibile.
Assumo quindi che chi ha conquistato l’accesso ai sistemi attraverso un phishing abbia prima usato vulnerabilità note per elevare i privilegi, cercando anche nelle cache dei browser alla ricerca di password (è bene ricordare che Chrome preserva le password in chiaro), ad esempio quelle dei virtualizzatori che sono amministrati attraverso interfacce Web. Una volta che si riesce a guadagnare i privilegi di amministrazione in alcuni sistemi si procede a disabilitare firewall e a cambiare i permessi dei filesystem prima di lanciare il cryptolocker in modo da massimizzare l’impatto.
C’è poi la minaccia dell’esfiltrazione: in un tempo di backup la minaccia include la pubblicazione di dati estratti durante il processo di cifratura. Ma nuovamente è facile immaginare che pochi gigabytes siano trasferiti in rete, altra cosa è un’esfiltrazione di tutti i dati contenuti in un datacenter, azione che richiederebbe ore e ore anche disponendo di banda larga in upstream. Certamente alcuni megabyte di documenti possono essere sufficienti a fare danno, ma c’è un evidente questione di probabilità e prima di gridare al data breach dei dati sanitari di un’intera regione bisognerebbe pensarci bene.
Il cryptolocker crypta i file…
Una delle prime domande che mi sono posto è stata: “ma come mai sono caduti i servizi?”. Con la storia del cryptolocker eseguito dallo smart-worker Pippo mi sarei aspettato che fossero solo gli share di rete ad essere coinvolti, per carità tanti documenti, ma perché i servizi Web sono stati affetti? E se sono stati coinvolti i dati dei servizi Web perché non i DB?
Si tratta di domande legittime ma è necessario prestare attenzione alle conclusioni che si traggono. Per un ente come la Regione Lazio mi aspetto che i dati principali siano in DB (probabilmente Oracle) installati su server fisici, e quindi relativamente immuni al cryptolocker. Questo spiegherebbe il perché delle dichiarazioni che i dati sanitari non sono stati coinvolti (immagino che questa affermazione non si possa estendere ad eventuali documenti generati a partire dai dati presenti nei DB e memorizzati in cache sul filesystem).
Resta il fatto che in un’installazione standard oggi i servizi vengono erogati da sistemi virtualizzati, e se si ha avuto accesso alle macchine virtuali allora è possibile crittografare i file al loro interno e di conseguenza i file php, aspx, ecc. divengono illeggibili per un Web server con il conseguente blocco dei sistemi. Questa mi pare l’unica spiegazione plausibile (a meno di non assumere che le installazioni dei virtualizzatori montassero i dischi virtuali da uno share di rete che è stato cifrato, cosa che mi pare decisamente poco probabile).
Il backup criptato o no?
Una delle voci più controverse è stata quella della cifratura dei backup che ha portato a numerose congetture e al formarsi della storia che è stato pagato il riscatto di 5 milioni di euro e come storia di copertura è spuntato fuori un backup.
Se fosse una storia di copertura sarebbe decisamente poco soddisfacente, me ne vengono in mente almeno altre dieci e tutte migliori, quantomeno storie da cui uno non esca come colui che ha perso una parte del backup. In effetti l’annuncio in conferenza stampa del backup crittografato è stato fatto da parte di un assessore e non certo di una persona tecnica, ed è stato subito rettificato (senza troppo successo visto che lo hanno notato in pochi) in “hanno cancellato i backup”, cosa comunque non di poco conto.
Sarei propenso a credere alla storia del wiping dei volumi di backup: non è detto che il backup risieda su un filesystem, e se si è un hacker che cerca di massimizzare l’impatto di un attacco (e si presume che magari vi sia una copia offline dei dati, anche se non troppo aggiornata) si può pensare che la cancellazione sia sufficiente ad eliminare i dati più recenti e dare un valore al dato crittografato tale da giustificare il pagamento del riscatto (anche grazie alla minaccia di pubblicazione dei dati che ad ora, per quanto ne so, non ha avuto seguito).
In ogni caso chiunque abbia lavorato con uno storage serio (con snapshot, deduplica, ecc.) sa che gli algoritmi usati al suo interno per ottimizzare le performance rendono assai difficile il controllo delle scritture sui singoli dischi. Una procedura di wiping, perciò, rischia di essere logica e non fisica, e con il supporto di chi ha realizzato il filesystem è possibile pensare di recuperare dati che si pensavano persi. A me personalmente è capitato: nel 2013 ho visto ricostruire un filesystem da mezzo petabyte a distanza da tecnici di EqualLogic con un processo durato oltre 24 ore da me spese a guardare cosa facessero connessi dagli Stati Uniti. Le 50 ore annunciate sono coerenti con la mia personale esperienza e se l’unico backup recente potesse essere ricostruito invece di spendere 5 milioni di euro ci proverei sicuramente. Certo, è questione di fortuna, ma in uno storage dove i dati vengono replicati più volte se si è provveduto a spegnere tutto tempestivamente quando si è evidenziata la crisi, e tenuto conto del fatto che il backup viene scritto solo dall’apposita procedura, è ragionevole che si sia tentata la strada che alla fine è risultata di successo.
Nuovamente, se avessero voluto una cover story migliore avrebbero potuto appellarsi a snapshot presenti nello storage, piuttosto che a un mero recovery low-level. Personalmente sono propenso a credere che le cose siano andate così, anche se mi auguro che un post-mortem lo confermi. Sicuramente trovo la spiegazione possibile, e non vedo quali dettagli addizionali chiunque, incluso Corrado Giustozzi, possa fornire per convincere qualcuno.
Trasparenza?
Una cosa che mi ha colpito dei commenti da parte di molti sedicenti esperti di cybersecurity è stata la richiesta di news in tempo reale, accurate e dettagliate, nel nome della trasparenza. Premesso che vorrei vedere loro dare i dettagli degli ultimi 5 attacchi presso le proprie organizzazioni prima di proferire parola (si sa che la maggior parte degli attacchi eseguiti con successo sono tenuti sotto silenzio). La mia esperienza è che in una prima fase, quella in cui cerchi di capire cosa ti sta succedendo fai ipotesi ma non sai esattamente da dove sono entrati, a volte servono mesi per individuare una dinamica precisa; successivamente, una volta compresa l’estensione del problema ti concentri sul ripristino della situazione, ripristino che è ancora in corso.
Non capisco quindi perché tutti pretendano un post-mortem visto che non siamo ancora al “mortem” figurati al post. È comunque sicuro che in questo caos che si abbatte sui tecnici poche informazioni, imprecise e date nella fase di analisi vengono recepite da chi ha bisogno di comunicare, e poiché l’impatto è grosso si tende a premere l’acceleratore sull’attaccante in modo da non passare per quelli che si sono fatti bucare da qualche ragazzino (non è questo il caso, ma sicuramente alcune affermazioni iniziali erano un po’ accentuate e lasciavano pensare a cyberwarfare e non a un hack per un mero riscatto).
Non mi ricordo chi, ma qualcuno che ho in contatto su LinkedIn invitava tutti al silenzio stampa in attesa del ripristino, penso che sarebbe una buona idea. Anche i big rilasciano i dettagli sulle vulnerabilità solo dopo averle fissate. Non capisco perché questo non si applichi alla Regione Lazio: dovrebbero prima ripristinare e mettere in sicurezza la piattaforma e solo dopo comunicare con più dettaglio.
ZTA non è 2FA
Molti invocano la ZTA (o la sua assenza) come un elemento dirimente ma troppo spesso lo fanno a sproposito. In alcuni casi ho visto confondere la two-factor-authentication con la ZTA. Non posso che raccomandare di leggere il documento del NIST che la descrive e che si basa sui seguenti presupposti:
- Tutte le sorgenti dati e i servizi di calcolo sono considerate risorse
- Tutte le comunicazioni sono sicure indipendentemente dalla posizione in rete
- L’accesso alle risorse dell’enterprise è assicurato su base di ogni sessione
- La politica di accesso alle risorse è determinata dinamicamente basandosi sullo stato del cliente, l’identità, l’applicazione, e altri attributi comportamentali
- L’enterprise effettua monitoraggio e misura l’integrità e il livello di sicurezza di tutte le proprie risorse
- L’autenticazione e l’autorizzazione di accesso a tutte le risorse è dinamica e verificata prima di concedere l’accesso
- Si colleziona la maggior quantità di informazione possibile sullo stato delle risorse, dell’infrastruttura di rete al fine di valutare lo stato di sicurezza e come migliorarlo
La 2FA rientra nel punto 4 ed è ben lontana da coprire tutti gli aspetti che caratterizzano le ZTA.
A mia conoscenza sono poche le infrastrutture in questa nazione che si possono dichiarare ZTA, anche solo in parte. Questo perché la ZTA è un’architettura relativamente giovane e i sistemi legacy non sempre possono essere adeguati in tempo, e sicuramente in un sistema come quello della Regione Lazio vi saranno molti sistemi legacy accumulati nel tempo che assumono la classica architettura basata su DMZ.
Ma quanto è grave un attacco?
Quando un sistema è compromesso è necessario guardare all’accaduto con freddezza e distacco per capire l’essenza dei problemi. È difficile farlo, ci si sente violati come quando entrano i ladri in casa, ed è forte la tentazione di buttarsi tutta la faccenda alle spalle. E se tutti ti usano come il tiro a segno diventa ancor più difficile seguire il giusto percorso e non comprare un firewall più grosso nella speranza di aver fatto qualcosa.
Non sono nella posizione di sapere quanto è grave, quanto fosse evitabile o meno, e perché il backup non fosse offline. È evidente che vi sono delle falle, anche organizzative, ma non posso non pensare che si tratti di una situazione comune. Troppo spesso la sicurezza viene discussa, analizzata, monetizzata solo quando succede qualcosa, e a farne le spese sono le persone che hanno realizzato un’infrastruttura con limiti di budget (che per la sicurezza è sempre inesistente), con lamentele da parte di tutto il personale per le procedure complicate, e con la naturale via tutta italiana di sperare sempre che capiti a qualcun altro. Trovo però che la banalizzazione a cui ho assistito di un’infrastruttura complessa, la riduzione di tutto un datacenter al PC di casa, sia da evitare per il bene di tutti.
Aspettiamo il post-mortem dell’accaduto e nel frattempo diamo tutti una mano, anche solo minimizzando il rumore. Sicuramente ci saranno contromisure da attuare, per fortuna l’impatto, ad ora, è stato importante ma molto minore di quanto avrebbe potuto essere.
