Cosa ci insegna o su cosa ci fa riflettere l’attacco che ha preso di mira VmWare ESXi? Seguono alcune considerazioni di carattere tecnico e sociologico.
Tre lezioni dal caso attacco via VmWare
Sull’evento c’è stata una attenzione mediatica elevata malgrado ad oggi, in Italia, le conseguenze siano abbastanza contenute. Tuttavia la storia non si ferma qui.
Attacco hacker globale? Forse eccesso di allarme ma la minaccia cyber resta seria
I danni indiretti
In un sistema digitale interconnesso in maniera irreversibile è facile identificare i danni diretti.
Meno per quelli indiretti. Ad esempio, se un server necessario per fare check-in in un mezzo di trasporto non funziona, sicuramente la agenzia che fornisce il servizio ne è penalizzata, ma il passeggero di conseguenza ne è penalizzato a sua volta se a causa di questo disservizio non può portare a termine le sue attività (che possono essere a sua volta critiche , quali ad esempio fare una operazione medica vitale per un paziente).
Non dovrebbe pertanto sorprendere che ogni qual volta ci sono vulnerabilità su sistemi abbastanza pervasivi, la preoccupazione ed il coinvolgimento raggiunge non solo i diretti interessati ma la società intera. È successo con ESXi, ma in passato ricorderemo Log4j…. e se andiamo indietro con il tempo, ricorderete Spectra e Meldown. Insomma, le persone sono preoccupate da fatto che qualcosa danneggi i propri piani in una routine che spesso non ammette ritardi. D’altra parte internet è nata per questo, accelerare le transazioni.
Il problema annoso delle patch
Il fatto che la vulnerabilità è vecchia di due anni dimostra che non è semplice talvolta installare le patch, ma anche che le abitudini del passato vanno modificate. Se nei decenni precedenti, il principio di non toccare nulla (con eccezione della manutenzione di alcuni asset da sostituire in maniera proattiva, a prescindere) finché tutto funziona, la preoccupazione che una patch forse risolve il problema per cui è stata sviluppata, ma sicuramente introduce qualche nuovo errore, non è più sufficiente a giustificare la latenza con cui si installano le patches, si usano sistemi non supportati.
Se una vulnerabilità è sconosciuta (zero-day), forse interessa pochi interessati. Ma quando la vulnerabilità diventa di dominio pubblico, se da un lato chi si difende è informato della vulnerabilità e può risolverla, dall’altro se non la risolve gli attaccanti sono facilitati nell’identificare le vittime.
Resta il fatto che non sempre le patch possono essere installate e, talvolta, con le vulnerabilità bisogna conviverci anche se in fase di sviluppo si è provato a disegnare un servizio garantendone la manutenibilità (security by design).
Test di vulnerabilità
Ovviamente per farlo, vanno identificate le contromisure, sempre che le vulnerabilità vengano conosciute ed indentificate. Pertanto se da un lato eseguire test di vulnerabilità periodici è una delle pratiche maggiormente raccomandata, dall’altro è necessario avere le competenze per disegnare la rete in modo che le vulnerabilità conosciute e no (zero-day) siano il meno esposte possibile agli esterni… perché se un asset è esposto direttamente su internet, è attaccabile, che sia un server con ESXi o che sia un dispositivo IoT.
I danni effettivi dall’attacco
A un’analisi di Cynet risultano in Italia 44 aziende compromesse e altre 404 potenzialmente compromesse. I rimanenti sono, in prevalenza, sistemi in hosting presso service provider (tipico di queste campagne) in quanto sono sistemi non gestiti e a volte addirittura dimenticati. Di questi potenziali bersagli, una parte sono sicuramente honeypot, un sistema o componente hardware o software usato come “trappola” o “esca” utilizzati per osservare dall’interno il meccanismo di attacco e ricavarne gli opportuni IoC – Indicatori di compromissione.
Il Governo ha confermato l’assenza di vittime notevoli.
Per Marco Lucchina di Cynet, inoltre, l’allarme è stato lanciato in modo “eccessivo” – scatenando panico senza alcuna informazione di contesto: “Si è generata una situazione di infodemia: ieri sera abbiamo ricevuto decine di richieste di intervento senza che ci fosse alcun valido motivo. Stavamo osservando lo svolgersi dell’attacco già da diversi giorni e, negli ultimi anni, ne abbiamo dovuti affrontare anche di più pericolosi”.
Infine, secondo Marco Lucchina: “Occorre considerare che gran parte delle aziende nel mirino non ha potuto avere un approccio strutturato all’accaduto, in quanto non in possesso di adeguate soluzioni di monitoraggio dei propri sistemi.”
Sababa Security nota invece che ci sono ancora tre punti da chiarire.
- Prima di tutto è possibile notare come all’interno delle note di riscatto non siano presenti riferimenti a Nevada ransomware o link rimandanti ad un sito web del gruppo, ma solo un id di TOX, sistema di messaggistica peer-to-peer.
- Inoltre, il malware utilizzato per la campagna massiva sembra utilizzare l’algoritmo di cifratura Sosemanuk, probabilmente basato sul codice sorgente di Babuk, mentre Nevada utilizza l’algoritmo di cifratura Salsa20.
- In conclusione, in base alle evidenze indicate in precedenza, sembra molto probabile che il gruppo dietro all’attacco sia un nuovo threat actor e non il già citato Nevada ransomware, per quanto su queste tematiche sia quasi impossibile fornire una risposta certa.
Redazione
