A circa 30 giorni di distanza da alcune prove di sicurezza effettuate su sistemi infetti da ransomware Hermes, abbiamo interessanti risultati che confermano le nostre aspettative.
Vorrei ringraziare alcuni amici che si sono prestati negli esperimenti e con i quali ho potuto creare i testbed che ci hanno portato ai risultati definitivi.
Siamo riusciti a contenere le conseguenze del ransomware Hermes attraverso la corretta applicazione di policy di sicurezza su un sistema infetto, riducendo gli effetti e la perdita di dati a zero, ecco come abbiamo fatto.
La situazione
Abbiamo preso un sistema e lo abbiamo infettato. Su questo sistema erano in funzione:
- Applicazioni
- Database SQL server
- Documenti
- Una Network Area Storage come gestore file e backup manager
Il backup, affidato volutamente al comando Robocopy di Windows, veniva effettuato su un’unità di rete che sapevamo essere soggetta alla propagazione del virus. Abbiamo optato per SQL Server come RDBMS perchè è molto diffuso e rappresenta uno standard di mercato.
Criteri di protezione
Analogamente a quanto avevamo descritto in questo articolo. Abbiamo adottato alcune politiche di sicurezza utili a contenere gli effetti nefasti del virus partendo dal presupposto che il materiale sulla macchina sarebbe stato distrutto. Ci siamo quindi concentrati sulla capacità di evitare la propagazione sulle unità di backup.
La policy che ha funzionato di più è stata quella che impediva la cancellazione dei file sull’unità di rete perchè, con relativa sorpresa, ha inibito l’esecuzione del virus. La mancata cancellazione ha bloccato e mandato in errore l’applicazione infetta impedendo la perdita dei file.
- L’attivazione delle quote utente hanno impedito e bloccato ulteriori scritture non autorizzate all’interno dell’unità di rete: permettendo la salvaguardia dello spazio e la non proliferazione di file .crypt o affini.
- Le ACL, regolate direttamente dall’unità di storage, hanno impedito al virus di alterare il comportamento dello stesso impedendo il fenomeno di unwanted role escalation.
- La creazione di un clone completo di applicazioni di base ha consentito un ripristino sicuro e molto veloce del sistema, con ripresa di funzionalità completa in circa 40 minuti.
- Il database SQL Server è stato gestito attraverso policy di dumping con successivo trasferimento in cartella di sola scrittura. Nelle versioni più vecchie del RDBMS è impossibile salvare su percorsi di rete e quindi è stato creato un job a livello di sistema operativo che si occupasse di creare una copia del file direttamente dentro all’unità di rete protetta (quella senza privilegi di cancellazione). Abbiamo usato con successo l’opzione robocopy con attributo di mirroring[1] attivo, in modo da esser certi che la copia fosse speculare. Chiaramente la cancellazione era inibita dalla mancanza di privilegi. Bisogna fare molta attenzione alle politiche di gestione delle transazioni, poichè quelle sono oggetto di maggior rischio. Si consiglia, di conseguenza, la clusterizzazione del database.
Ulteriori procedure applicabili
Abbiamo fatto ulteriori test a livello di volume, in quanto per velocizzare le procedure di backup, abbiamo testato un Backup on local folder che sfrutta a pieno la velocità del dispositivo di storage e, al tempo stesso, permette un ripristino rapido. Chiaramente bisogna avere memoria a disposizione per accogliere i backup e consigliamo di procedere con una rotazione giornaliera dei file.
Sarebbe auspicabile predisporre il dispositivo con almeno 2 volumi ma questo varia sia dalla condizione di partenza che dalla capienza complessiva dell’unità. Chiaramente scrivere su due volumi è più sicuro che scrivere sul medesimo volume nel caso di un’eventuale corruzione dello stesso. È importante ricordare che lo scopo del backup on local folder è quello di offrire la possibilità di un ripristino rapido, senza interessare le unità di backup esterne. È inoltre importante capire che non vale la pena procedere ad un ridimensionamento del volume unico forzando la stabilità del RAID e che, nel caso di unità molto capienti, si dovrebbe valutare di default l’opzione dei due volumi.
Si raccomanda, nel caso di due o più volumi, di attivare processi giornalieri di snapshot replication ma con una frequenza tale da poter essere controllabile. Nel caso in cui la snapshot replication sia attiva, si raccomanda di attivare la storicizzazione delle modifiche con accesso esclusivo da parte degli amministratori.
Gestire i dati utente
La gestione dei dati utente è, invece, un aspetto diverso rispetto a quanto elencato prima. Poiché un conto sono i dati di backup e un conto sono le cartelle di un sistema di storage a cui l’utente può accedere e che potrebbero essere facilmente corrotte in poco tempo compromettendo il lavoro dell’intera azienda. In tal caso abbiamo simulato uno scenario che ci ha restituito essenzialmente quanto segue.
Ad un tratto il virus ha correttamente aggredito la cartella rete con la quale l’utente lavora quotidianamente. A tale cartella accedevano anche altri utenti che, ovviamente, si sono trovati i documenti rinominati e cifrati.
Per evitare la propagazione dell’infezione è stata adottata una misura di collegamento basata su protocollo HTTP e quindi una soluzione analoga a Google Drive, OneDrive o DropBox. In questo modo l’infezione non può estendere agli altri computer poiché il protocollo adottato per il collegamento è differente.
Le cartelle di lavoro sono state protette da backup incrementali che hanno consentito un rollback efficace, permettendo un ripristino della versione funzionante.
L’attività di propagazione dei file sul cloud è stata tracciata dal log, consentendo di risalire al client infetto e disattivarlo da remoto. L’interruzione del client dalla nuvola, ha permesso di mantenere in sicurezza tutti i sistemi e di effettuare un ripristino corretto. Una volta risanato, il client precedentemente infetto è stato reintrodotto nella nuvola.
Aspetti migliorabili
Purtroppo nessun sistema testato da noi (Western Digital, Synology, Qnap, etc…) implementa la scrittura selettiva impedendo all’utente (o al virus) di scrivere file di specifici formati.
L’attuazione di un sistema cloud non sempre è confacente alle politiche aziendali e non sempre è sostenibile dai sistemi più datati. Abbiamo provato ad utilizzare la soluzione Synology Cloud Station su un sistema Intel Core 2 Duo notando un sostanziale aumento della RAM impiegata e un rallentamento non indifferente di tutte le procedure. La situazione è migliorata su un i5 appena preparato ma non su un i5 con due anni di funzionamento alle spalle. È necessario quindi adottare applicazioni che abbiano un ridotto consumo di memoria e fa specie che soluzioni come Google Drive non rientrino in questa sfera con un consumo massivo.
Conclusioni
I nostri test hanno evidenziato l’importanza di mantenere leggero il sistema evitando, per quanto possibile, di affollarlo di applicazioni. Inoltre è importante effettuare una valutazione sull’utilizzo della connessione internet: sistemi delicati potrebbero (e dovrebbero) avere una tipologia di accesso al dato internet molto più “ristretta”. Ad esempio, per quanto riguarda la posta elettronica, sarebbe auspicabile evitare l’accesso alle mail tramite client software e ricorrere, invece, alla parte di web mail.
Le soluzioni commerciali anti-ransomware di BitDefender, Acronis, AVG, si sono rivelate completamente inutili e sono state, in taluni casi, fermate dalla stessa minaccia. Hermes è stato riconosciuto ma non fermato da alcuni di questi anti-ransomware toolkit e ancora una volta sono state fermate le installazioni legittime di applicazioni, ottenendo falsi-positivi.
Un altro aspetto fastidioso riguarda la facile corruzione delle partizioni di ripristino del sistema operativo presenti sulla quasi totalità dei notebook e la necessità di affidare il ripristino ad un disco esterno con la procedura lanciata, magari, da chiavetta USB. Purtroppo i ransomware più forti sono in grado di non risparmiare nessun aspetto del disco.
