Ransomware WannaCry: Protezione e Best Practices

WannaCry, anche noto come WCry, WanaCrypt0r o Wana Decrypt0r 2.0, è un ransomware che si diffonde sfruttando gli exploit denominati EternalBlue e DoublePulsar.

L’exploit EternalBlue sfrutta una vulnerabilità del protocollo SMB v1 implementato nei sistemi Windows (CVE-2017-0145) risolta nel bollettino di sicurezza MS17-010 pubblicato il 14 marzo 2017 (per informazioni sull’SMB si veda la KB204279 Direct hosting of SMB over TCP/IP).

WannaCry sfrutta la vulnerabilità per diffondersi su reti pubbliche e private con modalità simili a quelle di un worm. Nella fase dell’infezione viene condotta una scansione della rete sulla porta TCP 445 (SMB) alla ricerca di sistemi Windows vulnerabili che poi vengono infettati con la backdoor DoublePulsar per ottenere l’accesso alla una macchina, quindi il malware crea una copia di sé stesso sul sistema e la esegue.

Di seguito una cronostoria sommaria degli eventi che hanno portato alla creazione e alla diffusione di WannaCry:

• 13 Agosto 2016: Il collettivo hacker che si fa chiamare Shadow Brokers comunica sul proprio canale Twitter di aver trafugato e pubblicato file trafugati all’Equation Group, un collettivo di hacker vicino alla NSA, contenti codici per fruttare vari exploit tra cui quelle relative all’SMB v1, a riguardo si vedano ad esempio NSA Hacked? ‘Shadow Brokers’ Crew Claims Compromise Of Surveillance Op e Hackerati gli hacker della Nsa?
• 16 Gennaio 2017: Lo US-CERT pubblica l’avviso SMB Security Best Practices riguardante un potenziale exploit zero-day di SMB (Server Message Block) messo in vendita nel Dark Web assieme ad altri exploit per i sistemi operativi Windows dal collettivo di hacker noto come Shadow Brokers, a riguardo si veda anche CERT Nazionale Italia: Avviso per possibile falla zero-day in SMB.
• 14 Aprile 2017: Pubblicazione del bollettino di sicurezza MS17-010 da parte di Microsoft per risolvere le vulnerabilità rese note da Shadow Brokers a riguardo si veda il post Protecting customers and evaluating risk.
• 12 Maggio 2017: Inizia la diffusione massiccia del ransomware WannaCry, a riguardo si veda CERT Nazionale Italia: Nuova campagna ransomware “WannaCry”.
• 12 Maggio 2017: Vendono rilasciate da Microsoft e altri le definizioni antivirus per rilevate il ransomware, a riguardo si veda Ransom: Win32/WannaCrypt.
• 12 Maggio 2017: Microsoft pubblica la Customer Guidance for WannaCrypt attacks in cui fornisce indicazioni su come proteggere i sistemi dal ransomware e annuncia anche la disponibilità della della fix di sicurezza per i sistemi fuori supporto come Windows XP e Windows Server 2003 che inizialmente  non erano stati inclusi nel bollettino MS17-010, viene inoltre pubblicato il post WannaCrypt ransomware worm targets out-of-date systems che fornisce un’analisi dettagliata del malware. Il 17 Maggio 2017 viene resa disponibile anche la WannaCrypt attacks: guidance for Azure customers in cui vengono fornite indicazioni per i clienti di Azure.
• Dal 12 Maggio 2017: I vari CERT nazionali e altre istituzioni governativi pubblicano linee guida per la difesa dal ransomware e analisi approfondite:
  • 12 Maggio 2017 – US-CERT: Alert (TA17-132A) Indicators Associated With WannaCry Ransomware
  • 14-05-207 – Polizia di Stato: Attacco informatico globale: ecco come difendersi
  • 15 Maggio 2017 – CERT Nazionale Italia: Come funziona il ransomware WannaCry e cosa fare per proteggersi
  • 15-05-2017 – CERT-PA: WannaCry: online le linee guida destinate alle PA per mitigare gli effetti del ransomware
  • 15-05-2017 – ENISA (European Network and Information Security Agency): WannaCry Ransomware Outburst
  • 17-05-2017 – US-CERT: ICS-CERT Releases WannaCry Fact Sheet
• 18 Maggio 2017: Rilasciato un tool per decriptare i file cifrati dal ransomeware, il tool è disponibile sul reposository GitHub wanakiwi, per ulteriori informazioni si veda l’articoloWannaCry Ransomware Decryption Tool Released; Unlock Files Without Paying Ransom.

Da questa breve cronostoria di questo questo ransomware possiamo trarre le seguenti conclusioni:

• Da quanto è stato reso pubblico lo zero day a quanto è stato resa disponibile una correzione per impedirne l’utilizzo e mettere in sicurezza il sistema sono trascorsi 87 giorni (ovvero 2 mesi e 27 giorni).
• Da quanto è stato reso pubblico lo zero day a quando il ransomware è stato diffuso sono trascorsi 115 giorni (ovvero 3 mesi e 25 giorni)
• Da quanto è stato resa disponibile una correzione per impedirne l’utilizzo e mettere in sicurezza il sistema a quando il ransomware è stato diffuso sono trascorsi 28 giorni.
• C’è stata una completa e tempestiva informazione sull’argomento sia da parte di fonti private che governative comprese le istituzioni italiane.

Di conseguenza appare chiaro come siano di primaria importanza le seguenti attività al fine di gestire al meglio la sicurezza di un’infrastruttura informatica:

• Informarsi sui canali istituzionali e/o privati dedicati alla sicurezza sulle minacce in corso.
• Mantenere aggiornati i sistemi client e server con almeno cadenza settimanale.
• Mantenere aggiornate le firme degli antivirus con una frequenza almeno giornaliera o se possibile ogni 6 ore.
• Assicurarsi che i sistemi antimalware sui server di sposta siano attivi, funzionanti e aggiornati ed evitare lo scambio di allegati che possono contenere malware tramite mail.
• Non esporre le porte utilizzate da SMB (TCP 139, TCP 445, UDP 137, UDP 138) tranne che agli host che ne hanno necessità,
• Disabilitare o rimuovere dai sistemi le funzionalità non utilizzate (nel caso specifico il supporto a SMB v1) .
• Assicurarsi che i backup siano funzionanti, aggiornati e protetti.
• Assicurarsi che ogni utente abbia solo i privilegi strettamente necessari per contenere i danni di una eventuale infezione.
• Monitorare l’infrastruttura per rilevare tempestivamente comportamenti sospetti in modo da bloccare rapidamente una una eventuale infezione (caso specifico una delle verifiche potrebbe essere quella di generare un alert se si rilevano file con estensioni .wcry tramite uno script che analizza le share più comunemente usate dagli utenti in base ad una schedulazione).

Inoltre per quanto riguarda le Pubbliche Amministrazioni le nuove Misure minime di sicurezza ICT per la PA oltre ad obbligare tutte le PA a seguire le precedenti indicazioni forniscono delle linee guida basate su SANS 2.0 (CIS Critical Security Controls for Effective Cyber Defense ) versione 6.0 di ottobre 2015 con fine di fornire un riferimento utile a stabilire se il livello di protezione offerto da un’infrastruttura risponde alle esigenze operative, individuando anche gli interventi idonei per il suo adeguamento.

Scendendo nel dettaglio di ciò che un amministratore di sistema deve fare per scongiurare un infezione la prima attività da eseguire è controllare l’aggiornamento dei sistemi per assicurarsi che le correzioni rilasciate col bollettino MS17-010 siano state installate e in caso contrario installarle per scongiurare che un sistema possa essere infettato tramite la rete.

Per verificare gli aggiornamenti di sicurezza installati filtrando in base al prefisso KB40 è possibile utilizzare il comando:

wmic qfe get hotfixid | Find “KB40”

Per verificare se la il bollettino MS17-010 è stato installato procedere come segue in base al sistema operativo da verificare:

• Windows XP e Windows Server 2003/R2: Verificare che sia presente la KB4012598.
• Windows 7 SP1 e Windows Server 2008 R2 SP1: Verificare che sia presente l’ultimo Monthly Rollup (ad oggi la KB4019264 del 9 Maggio 2017). Per l’elenco delle security e non-security updates pubblicate si veda Windows 7 SP1 and Windows Server 2008 R2 SP1 update history.
• Windows 8.1 e Windows Server 2012 R2: Verificare che sia presente l’ultimo Monthly Rollup (ad oggi la KB4019215 del 9 Maggio 2017). Per l’elenco delle security e non-security updates pubblicate si veda Windows 8.1 and Windows Server 2012 R2 update history.
• Windows 10 Versione 1511: Verificare che sia presente l’ultima OS Build (ad oggi la KB4019473 OS Build 10586.916 del 9 Maggio 2017). Per l’elenco delle security e non-security updates pubblicate si veda Windows 10 update history – Updates for Windows 10 Version 1511.
• Windows 10 Versione 1607 e Windows Server 2016: Verificare che sia presente l’ultima OS Build (ad oggi la KB4019472 OS Build 14393.1198 del 9 Maggio 2017). Per l’elenco delle security e non-security updates pubblicate si veda Windows 10 update history – Updates for Windows 10 Version 1607 and Windows Server 2016.
• Windows 10 Versione 1703: Verificare che sia presente l’ultima OS Build (ad oggi la KB4016871 OS Build 15063.296 del 9 Maggio 2017). Per l’elenco delle security e non-security updates pubblicate si veda Windows 10 update history – Updates for Windows 10 Version 1703.

Sebbene sia consigliabile aggiornare anche i sistemi Windows 10 nel post WannaCrypt ransomware worm targets out-of-date systems viene indicato che i sistemi con Windows 10 non sono affetti dalla vulnerabilità CVE-2017-0145 denominata EternalBlue e sfruttata da WannaCry:

“The exploit code used by WannaCrypt was designed to work only against unpatched Windows 7 and Windows Server 2008 (or earlier OS) systems, so Windows 10 PCs are not affected by this attack.

We haven’t found evidence of the exact initial entry vector used by this threat, but there are two scenarios that we believe are highly possible explanations for the spread of this ransomware:

• Arrival through social engineering emails designed to trick users to run the malware and activate the worm-spreading functionality with the SMB exploit
• Infection through SMB exploit when an unpatched computer is addressable from other infected machines”

La seconda attività che che un amministratore di sistema dovrebbe fare è disabilitare l’SMB v1 come peraltro già raccomandato nel post Stop using SMB1 del 16 Settembre 2016 in seguito al rilascio del bollettino di sicurezza MS16-114, ovvero dopo la pubblicazione da parte di Shadow Brokers degli exploit trafugati ma molto prima che questi venissero utilizzati per creare e veicolare malware:

“The original SMB1 protocol is nearly 30 years old, and like much of the software made in the 80’s, it was designed for a world that no longer exists. A world without malicious actors, without vast sets of important data, without near-universal computer usage. Frankly, its naivete is staggering when viewed though modern eyes. I blame the West Coast hippy lifestyle.”

Vi sono ormai pochi scenari in cui può essere necessario utilizzare ancora SMB v1 sempre come descritto nel post Stop using SMB1 come l’utilizzo di Windows XP o Windows Server 2003 in quanto tali OS sono in grado di accedere e/o esporre share solo tramite SMB v1, altre ragioni possono essere software che fanno uso della funzionalità network neighborhood o ancora stampanti multifunzioni con firmware datati che utilizzano funzionalità di scan to share:

• You’re still running XP or WS2003 under a custom support agreement.
• You have some decrepit management software that demands admins browse via the ‘network neighborhood’ master browser list.
• You run old multi-function printers with antique firmware in order to “scan to share”.

Per la disabilitazione dell’SMB v1 è possibile utilizzare le indicazioni della How to enable and disable SMBv1, SMBv2, and SMBv3 in Windows and Windows Server.

Disabilitazione Server SMB v1 in Windows 7, Windows Server 2008 R2, Windows Vista e Windows Server 2008 tramite PowerShell:

Per disattivare SMB v1 nel server SMB, eseguire il seguente cmdlet:

Set-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters” SMB1 -Type DWORD -Value 0 –Force

Dopo aver impostato le chiavi registro per disabilitare l’SMB v1 nel server SMB è necessario riavviare il computer

Disabilitazione Server SMB v1 in Windows 8, Windows Server 2012, Windows 10 e Windows Server 2016 tramite PowerShell:

Per ottenere lo stato corrente della configurazione del protocollo del server SMB eseguire il seguente cmdlet:

Get-SmbServerConfiguration | Select EnableSMB1Protocol, EnableSMB2Protocol

Per disattivare SMB v1 nel server SMB eseguire il seguente cmdlet:

Set-SmbServerConfiguration -EnableSMB1Protocol $false

Dopo aver disabilitato l’SMB v1 nel server SMB tramite il cmdlet Set-SmbServerConfiguration non è necessario riavviare il computer.

Disabilitazione Clinet SMB v1 in Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8 e Windows Server 2012 tramite il comando sc.exe:

Per ottenere lo stato del servizio SMB Client eseguire il comando:

sc.exe queryex mrxsmb10

Per disabilitare SMB v1 sul client SMB eseguire i comandi:

sc.exe config lanmanworkstation depend= bowser/mrxsmb20/nsi
sc.exe config mrxsmb10 start= disabled

Rimozione dell’SMB v1 in Windows 8.1, Windows 10, Windows 2012 R2 e Windows Server 2016 tramite PowerShell:

Per ottenere lo stato della funzionalità SMB 1.0 eseguire il seguente cmdlet:

Get-WindowsFeature FS-SMB1

Per rimuovere la funzionalità SMB 1.0 eseguire il seguente cmdlet:

Remove-WindowsFeature FS-SMB1

Rimozione dell’SMB v1 in Windows 8.1 e Windows 10 tramite PowerShell:

Per ottenere lo stato della funzionalità SMB 1.0 eseguire il seguente cmdlet:

Get-WindowsOptionalFeature -Online -FeatureName smb1protocol

Per rimuovere la funzionalità SMB 1.0 eseguire il seguente cmdlet:

Disable-WindowsOptionalFeature -Online -FeatureName smb1protocol

Conclusioni

Sebbene anche in questo caso l’infezione poteva essere semplicemente scongiurata mantenendo aggiornati i sistemi va comunque detto che le considerazioni riportate nel post The need for urgent collective action to keep people safe online: Lessons from last week’s cyberattack da Brad Smith (President and Chief Legal Officer) circa il dovere morale di un ente pubblico governativo di informare il produttore di un software di una vulnerabiltà se questa può causare danni a persone sono più che condivisibili.

Ovviamente sebbene l’alarme WannaCry sembra rientrato occorre continuare a tenere alta la guardia e aggiornare i sistemi in quanto come è ovvio aspettarsi compariranno altri malware che utilizzeranno gli stessi exploit o altri tra quelli trafugati dal collettivo hacker Shadow Brokers che non riguardano non solo i sistemi operattivi Microsoft, ma ad esempio, anche numerosi firewall.

Infatti oggi è già stato individuato un nuovo ransomware denominato UIWIX che si diffonde sfruttando l’exploit EternalBlue, a riguardo si veda CERT Nazionale Italia: Il ransomware UIWIX si installa sfruttando l’exploit EternalBlue. Inoltre pare che già prima di WannCry un altro malware abbia utilizzato l’exploit EternalBlu diffondesi forse già dal 24 Aprile 2017, a riguardo di veda CERT Nazionale Italia: Il malware Adylkuzz diffuso sfruttando gli stessi exploit di WannaCry.

Per ulteriori informazioni si veda anche il post Attacco ransomware #WannaCry : risorse utili e chiarimenti di Felicaino Intini (Microsoft Italia).