Il supply-chain attack a Kaseya rappresenta uno dei più vasti attacchi di questa categoria, secondo – per danni – soltanto a quanto avvenne con WannaCry e poi NotPetya nel 2017. In questo caso però l’attacco non ha avuto fini di intelligence ma di pura estorsione. Il gruppo noto come REvil – che in una intervista rilasciata lo scorso sabato ha dichiarato di generare 100 milioni di dollari l’anno di introiti – tramite una vulnerabilità in Kaseya VSA, un software di gestione per infrastrutture IT, ha distribuito il proprio ransomware ad oltre 30 Managed Service Providers (MSP).
Il ruolo degli MSP per l’attacco Kaseya
Gli MSP gestiscono generalmente decine o centinaia di business, gli attaccanti sono quindi riusciti a sfruttare la posizione privilegiata dell’MSP per diffondere il ransomware su tutti i loro clienti che, con le ultime informazioni disponibili, sembrerebbero essere oltre 1000. Mentre REvil ha annunciato di aver compromesso oltre 1 milione di dispositivi, chiedendo 70M$ di riscatto, notizia che se confermata porterebbe questa operazione al secondo posto della triste classifica degli attacchi ransomware più vasti.
La richiesta di riscatto arriva con la promessa di pubblicare un decryptor universale valido per tutte le vittime, evitando a REvil di dover contrattare singolarmente con 1000+ differenti business.
Ma cerchiamo di capire cosa e’ avvenuto, perche’ le informazioni sono ancora frammentarie e non e’ immediato ricostruire lo scenario completo.
Il 2/Luglio Kaseya riporta un possibile attacco alla loro piattaforma:
Com’è avvenuto l’attacco cyber a Kaseya
Tuttavia l’impatto dell’attacco non è ancora chiaro, tanto che l’azienda stessa parla di “un piccolo numero di installazioni on-premise” e raccomandano di mettere i server offline per evitare problemi, dal momento che gli attaccanti disabilitano immediatamente l’accesso amministrativo una volta ottenuto l’accesso alla piattaforma VSA.
Contemporaneamente, il DIVD (Dutch Institute for Vulnerability Disclosure) entra in contatto con Kaseya poiché l’istituto stava già lavorando all’analisi della piattaforma VSA ed aveva identificato una serie di vulnerabilità critiche. Una di queste era stata riportata come CVE-2021-30116 al momento della stesura di questo pezzo la vulnerabilità non è ancora annunciata pubblicamente, ma sappiamo essere la stessa utilizzata da REvil per fare breccia negli MSP che utilizzano Kaseya VSA.
La vulnerabilità sembra essere una SQL injection che consentirebbe di effettuare il bypass dell’autenticazione alla piattaforma, consentendo a chiunque di fare login con privilegi massimi. Non è chiaro come REvil sia entrato in possesso della vulnerabilità, sappiamo soltanto che Kaseya stava lavorando attivamente al patching del problema ma il gruppo dietro REvil è riuscito ad attivarsi prima ancora che una patch fosse distribuita. E’ possibile che REvil abbia identificato il problema contemporaneamente al DIVD come pure è possibile che ci sia stato un leak del report su altri canali.
A questo punto il DIVD, che aveva già effettuato un mass-scan dell’intera rete per identificare le installazioni di Kaseya VSA raggiungibili da internet (2200 per la precisione), inizia a contattare i vari CERT e direttamente le infrastrutture potenzialmente vulnerabili, chiedendo di spegnere immediatamente i propri server. Nel giro di poche ore le 2200 installazioni online diventano appena 140. Questa operazione ha ridotto l’impatto totale dell’attacco ma i numeri in gioco rimangono comunque importanti.
Mentre Kaseya e DIVD si occupano di notificare le potenziali vittime, REvil procede con la compromissione dei server ancora online. Gli attaccanti sfruttano l’authentication bypass per per avviare la trasmissione di un file chiamato “Kaseya VSA Agent Hot-fix”” che quando avviato esegue una serie di operazioni, tra cui la disabilitazione di alcuni componenti di sicurezza della macchina, per poi eseguire tramite side-loading l’avvio del ransomware vero e proprio. Per abbassare il profilo di detection, il ransomware è stato firmato con un certificato legittimo a nome di “PB03 TRANSPORT LTD.”:
Il tool Kaseya
Kaseya ha anche rilasciato un tool per aiutare le possibili vittime ad identificare le proprie istanze vulnerabili e per identificare possibili endpoint compromessi. La catena di attacco ad ogni modo non sembra esser stata pianificata con largo anticipo, lasciando pensare che REvil possa aver ottenuto accesso alla vulnerabilità in tempi estremamente recenti, magari proprio successivamente alle prime segnalazioni, tuttavia non ci sono ancora elementi forti in un verso o nell’altro che consentano di formulare ipotesi ragionevoli.
Cosa si impara da questo attacco ransomware a Kaseya
Questo attacco dimostra come, col crescere degli introiti – Revil chiede 70 milioni di dollari per sbloccare tutti – , i gruppi ransomware riescono a ricercare o ottenere vulnerabilità 0-day che poi vengono utilizzate per sferrare attacchi ad elevato impatto. Non è la prima volta che vediamo un ransomware utilizzare uno 0-day, e certamente non sarà l’ultima, ma è la prima volta che ne vediamo uno utilizzato per effettuare un supply-chain attack su tale scala.
Gli MSP rimangono obiettivi altamente appetibili, sia per operazioni di spionaggio che a fini di estorsione, visto il livello di accesso alle infrastrutture dei propri clienti. Oramai quando si parla di ransomware sappiamo che non si tratta più di attacchi opportunistici, quanto di operazioni mirate con un livello crescente di sofisticazione che assomigliano sempre più agli attacchi di alto profilo che siamo abituati a vedere con i gruppi APT.
I business, specie quelli medi e piccoli, si trovano oggi a dover far fronte ad una minaccia che cresce rapidamente e che si sta dimostrando sempre più difficile da eradicare. Gli attacchi di tipo supply-chain sono estremamente efficaci, come abbiamo visto nel caso di SolarWinds, e mettere in sicurezza un’infrastruttura da questo tipo di minacce è un percorso estremamente complesso che oramai non possiamo più sottovalutare.
Come si protegge da un supply-chain attack e ransomware?
Questo attacco apre quindi la porta ad una serie di quesiti che non hanno ancora una risposta concreta: come ci si protegge da supply-chain attack e ransomware? Perché i ransomware group operano inpuniti sulla scena internazionale?
La risposta a queste domande è tutt’altro che immediata e come sempre più spesso accade è formata da un mix di tecnologie, processi e policies che devono entrare a far parte del DNA di ogni entità che gestisce dati ed infrastrutture. I supply-chain attack sono estremamente complessi da identificare, perché’ sfruttano il canale fidato che esiste tra il vendor ed il cliente. I vendor infatti non hanno interessi a danneggiare i propri clienti ed il cliente non ha ragioni per non fidarsi. Una via percorribile, sebbene complessa, è quella di effettuare il profiling di ogni singola applicazione presente in un’infrastruttura ed allertare il team di sicurezza ogni qual volta un update modifica il comportamento dell’applicazione in maniera significativa.
Nel 2018 in ReaQta, durante uno studio sulla mitigazione dei supply-chain attack tramite analisi comportamentale, avevamo compilato una statistica scoprendo che una generica infrastruttura di 1000 computer, veniva in contatto in media con 6000 nuovi file eseguibili (nuovi o come risultato di update) ogni 30 giorni.
Questo numero mette il profiling applicativo fuori dalla portata delle maggior parte delle strutture, e richiede un approccio ad elevata automazione per non soffocare di lavoro gli analisti che devono farsi carico di identificare eventi ad altissimo impatto ma rari. Ma questo approccio non è certamente una panacea, i ransomware seguono ogni percorso disponibile ed attaccano qualunque posizione sono in grado di raggiungere.
Una parte del problema è fondamentalmente geopolitica, tali gruppi operano infatti in maniera impunita da una serie molto ristretta di territori, con un patto più o meno tacito di non arrecare danni al paese di appartenenza. Un modus operandi che sembra funzionare bene perché’ crea un’asimmetria che mette il paese ospitante al sicuro da una serie di problemi, e disturba l’operatività di altri paesi, che devono spendere tempo e risorse per mettersi al sicuro da queste minacce perdendo in risorse e competitività. Senza considerare altri possibili scenari, dove i dati quasi sempre rubati alle vittime finiscono per vie traverse alle intelligence degli stessi paesi ospitanti.
Diventa quindi necessario agire in maniera forte quando la provenienza di un attacco può essere attribuita con un alto livello di sicurezza ad un determinato paese. La minaccia di sanzioni severe e coordinate, così come avviene per una parte degli stati che finanziano o proteggono organizzazioni terroristiche, rappresenta un forte disincentivo ad offrire asilo a strutture di attacco che non si limitano più a rubare dati ma a creare ingenti danni con ripercussioni importanti.
Gli attacchi ransomware evolvono sempre più rapidamente, REvil ha lasciato intendere che anche le modalità stesse stanno per cambiare in modo da rendere i ransomware più rapidi ed efficienti di quanto non lo siano già. I provider di servizi e sicurezza vengono attaccati ed utilizzati per amplificare la potenza di attacco di tali gruppi, in questo momento siamo quindi dal lato debole della barricata ma non è questo il momento di tremare. Come abbiamo appena visto, l’approccio del DIVD ha contribuito a ridurre l’impatto dell’attacco in maniera significativa, quel milione di dispositivi dichiarato da REvil sarebbe potuto diventare 10M o 100M se non ci fosse stato uno sforzo coordinato a mettere offline le macchine vulnerabili.
E la chiave per ridurre questi rischi è proprio nello sviluppare un’infrastruttura di condivisione real-time delle minacce, seguita da strumenti di identificazione, response e remediation assieme ad una preparazione mirata ad insegnare come gestire disaster-scenario come quelli appena visti. La protezione deve quindi arrivare da due fronti, uno interno, mettendo assieme i fattori appena visti, ed uno esterno mirato a rendere il terreno sotto i piedi degli attaccanti molto meno stabile. Se chi attacca non ha la certezza dell’impunità, avrà un problema in più di cui doversi seriamente preoccupare.
—
Link utili
Encryptor (agent.exe):
DLL usate nel sideloading:
