OVH NEWS | INNOVAZIONI E TENDENZE IT


Scopri, comprendi, anticipa









24/05/2017
Condividi

Articolo scritto da Sébastien Mériot & Hugo Bonnaffé


WannaCry: asciugatevi le lacrime… ma restate all'erta!


La pandemia WannaCry ha colpito principalmente i sistemi informatici delle aziende ma non ha risparmiato neanche i server con le versioni Windows non aggiornate. Di fronte a un fenomeno di tale portata, quali sono i mezzi di difesa di un hosting provider? La risposta non è semplice: la responsabilità è soprattutto degli utenti, gli unici a poter mantenere aggiornati i propri sistemi. Tuttavia, OVH ha messo in atto tutte le azioni possibili per frenare la comparsa di WannaCry sui server vulnerabili dei propri clienti e contenere questa epidemia particolarmente "contagiosa". In questa occasione è importante citare alcune importanti best practice, utili per contrastare questa minaccia che non rischia certo di scomparire.



Le nostre stime


In questi ultimi giorni, solo gli eremiti o chi era troppo preso dall'attualità politica non ha sentito parlare di WannaCrypt0r, il ransomware che si è diffuso a macchia d'olio in tutto il mondo sfruttando una vulnerabilità nella condivisione di file dei sistemi Windows. I media hanno monopolizzato l'argomento, riportando il disappunto di aziende come FedEx negli Stati Uniti, Renault in Francia e ancora i disagi degli ospedali pubblici inglesi, costretti a rinviare operazioni a causa dell'impossibilità di accedere alle cartelle cliniche dei pazienti. In che modo OVH ha individuato e gestito questa ondata di ransomware? Segue il racconto su come il nostro team di Security non ha seguito la nomina del nuovo Presidente della Repubblica francese alla televisione e ha trascorso una settimana insonne.



WannaCry (questo il nome dato al ransomware, con un chiaro riferimento alla reazione delle sue vittime) avrebbe già colpito tra 150.000 e 300.000 macchine nel mondo e queste cifre purtroppo continuano ad aumentare, perché l’epidemia è tutt'altro che terminata. Esistono seri motivi per temere un estendersi della diffusione a causa della comparsa delle nuove varianti di WannaCry. Il fenomeno resta tuttavia relativamente marginale in OVH, dove gli indirizzi IP coinvolti sarebbero appena 5.000 sugli oltre due milioni gestiti. Questi i risultati degli ultimi calcoli basati sulla nostra rete di honeypot, le macchine gestite dal team SOC (Security Operation Center) e volontariamente esposte sulla rete allo scopo di attirare qualunque tipo di minaccia in circolazione sul Web (malware, hacker, phishing…), permettendo così di farsi un'idea della loro pericolosità e velocità di propagazione. Anche se il numero delle macchine infettate all'interno della rete OVH sembra esiguo, soprattutto considerando la portata del nostro parco macchine, ci siamo comunque mobilitati per impedire la contaminazione dei nuovi server vulnerabili (una precisazione: si tratta di macchine fornite da OVH ai propri clienti e a rischio in quanto non aggiornate dai diretti responsabili. I server del sistema IT di OVH non sono stati in nessun modo colpiti da WannaCry, come vedremo successivamente nel dettaglio).



WannaCry: il prezzo della popolarità


Cos'è WannaCry? Si tratta di un ransomware, un software malevolo (malware) che prende in ostaggio i dati delle vittime, spesso codificandoli, e chiedendo un riscatto in denaro per farne recuperare l'accesso. Nella maggior parte dei casi il pagamento del riscatto viene richiesto in bitcoin, per rendere più difficile la tracciabilità dei flussi finanziari. Questo procedimento non è nuovo: è in forte aumento dal 2005, ed è un giro d'affari molto redditizio. Secondo una stima dell'FBI, nel 2016 il mercato dei ransomware ha superato gli 830 milioni di dollari. Solo per avere un'idea, è l'equivalente della dimensione del mercato inglese della SVOD (Subscription Video on Demand) nel 2015... o delle perdite di Uber nel 3° trimestre 2016 – identificate pure il paragone che appare più adeguato, noi non abbiamo trovato di meglio.



Immagine della finestra che compare sullo schermo delle vittime quando la macchina viene infettata da WannaCry.


I ransomware vengono diffusi solitamente tramite email che contengono in allegato, ad esempio, una fattura falsa, spesso in formato Word o .pdf. Una volta aperto, l'allegato esegue un codice malevolo (JavaScript, macro,VBScript…) che recupera su un server la chiave di cifratura che viene poi utilizzata per criptare i dati delle vittime.

Nel caso della recente epidemia WannaCrypt0r è importante evidenziare che eravamo di fronte alla versione 2.0 del ransomware. È evidente che i creatori del software non pubblicano note di release. La versione iniziale del malware, diffusa via email, non ha avuto il successo sperato. La versione 2.0 risulta essere più efficace, si basa sullo sfruttamento di una falla nella condivisione file di Windows (SMB) che, corretta da Microsoft il 14 marzo 2017 con la patch MS17-010, permette di eseguire arbitrariamente codici su una macchina remota esponendo pubblicamente il servizio di condivisione. In questo modo le macchine non aggiornate che utilizzavano prevalentemente Windows Server 2008 e le versioni precedenti del sistema operativo di Microsoft, sono state infettate. Soltanto a partire da Windows Server 2012 e Windows 10, infatti, il firewall è stato configurato in modo tale da non esporre il servizio a tutti di default. Questo spiega il numero inferiore di vittime. Per comprendere il seguito della storia, è importante ricordare che il servizio di condivisione di file avviene tramite la porta TCP/445.

Nella famiglia dei malware, o software malevoli, distinguiamo diverse sottocategorie. Abbiamo appena parlato dei ransomware, il cui obiettivo è prendere in ostaggio l'utente cifrandone dati. Ma ricordiamoci che, nel caso di WannaCry, per diffondere il ransomware è stata sfruttata la vulnerabilità. Lo sfruttamente delle falle è nelle mani dei worm. WannaCry è un pacchetto ibrido che associa un worm e un ransomware. E se WannaCry ha chiesto il pagamento di un prezzo, questo è strettamente correlato alla popolarità di Microsoft, il cui sistema ha invaso le postazioni di lavoro delle aziende.



Flashback: Blaster senza gloria


Vi ricordate di Blaster? Nell'agosto del 2003 centinaia di migliaia di computer Windows 2000 e Windows XP erano stati infettati da questo worm che, sfruttando una vulnerabilità per cui Microsoft non aveva ancora rilasciato le patch, costringeva i computer infetti a riavviarsi ogni 60 secondi. Blaster eseguiva poi una scansione della rete Internet alla ricerca di altri computer da contaminare in quanto, come per WannaCry, la sua propagazione si basava su un vettore di infezione Peer to peer (P2P).



Quando i nostri honeypot hanno iniziato a suonare


Venerdì 12 maggio circolavano già i primi tweet di @MalwareHunterTeam su una nuova minaccia dalla rapida diffusione chiamata WannaCry.
Durante la serata comparivano i primi articoli sullo sfruttamento della falla precedentemente corretta da Microsoft. Intorno alle 21:00, il nostro supporto tecnico in Canada era sorpreso dal numero esagerato di ticket aperti a causa di ransomware.

Come Cloud provider lottiamo contro la proliferazione di ransomware e malware, ma la battaglia sarà lunga: per arrivare fino all'origine delle organizzazioni criminali e denunciarle alle autorità competenti affinchè le smantellino, il team SOC di OVH effettua indagini molto complesse. Riuscire a sradicare il fenomeno con azioni diverse dalla prevenzione per ridurre il rischio rappresentato dal fattore umano è impossibile. Com'è noto ai responsabili IT, aggiornare costantemente il proprio sistema informatico è un'attività molto importante, che comporta una serie di difficoltà considerando l'eventuale incompatibilità delle applicazioni utilizzate con la nuova versione dell'OS (per questa ragione esistono ancora tante macchine con versioni di Windows precedenti al 2008). Al contempo bisogna sensibilizzare regolarmente i propri collaboratori sul secondo vettore di contaminazione: gli allegati dei messaggi di posta elettronica in arrivo (a costo di portare avanti, come fa OVH, campagne di test utilizzando false email infette per misurare la vulnerabilità dei propri dipendenti e fare formazione su una maggiore sicurezza informatica). Infine, non bisogna dimenticare che di fronte a un ransomware, così come alla maggior parte delle catastrofi informatiche che hanno un impatto sui dati, vi è un rimedio semplice ma estremamente efficace: fare il backup dei propri dati!

Tutto questo per spiegarvi che è abbastanza raro dover annullare una cena romatica il venerdì sera a causa di una campagna ransomware. Ma questa era un pò speciale. Sapevamo che Wannacry si diffondeva via EternalBlue, lo sfruttamento di una falla tramite l'attacco alla porta TCP/445. Molti di voi forse non lo sanno, ma già da diversi anni la porta TCP/445 utilizzata per la condivisione di file Windows (CIFS) viene filtrata dai router perimetrali della rete OVH per motivi di sicurezza (1). La porta TCP/445 (SMB), infatti, si è già rivelata essere un vettore di propagazione di malware e OVH ha ritenuto che dovesse essere esposta solo in una rete privata. Se un utente vuole utilizzarla per comunicare a distanza, deve farlo tramite una VPN (Virtual Private Network). Di conseguenza connettersi a una macchina ospitatata in OVH con la porta TCP/445 non è possibile, a meno che non si acceda con un IP appartenente a OVH (all'interno della rete OVH il filtro sulla porta non è attivo, in quanto la condivisione di file può servire ai clienti per motivi del tutto legittimi). OVH era quindi al riparo dal vedere macchine contaminate nella sua rete…

Eppure, nella notte tra venerdì e sabato, i nostri honeypot hanno dato l'allarme in seguito a un aumento improvviso del numero di scansioni provenienti da IP della rete OVH. Ci siamo subito attivati su diversi fronti: la ricerca metodica del paziente zero, cioè quello tramite il quale WannaCry era riuscito a penetrare all’interno della rete OVH per diffondere l’infezione; il reverse-engineering del ransomware per comprenderne il funzionamento; l'attuazione di misure per impedire il contagio di altre macchine vulnerabili e, ovviamente, la verifica scrupolosa delle macchine del nostro sistema interno.



Come funziona WannaCry e perché ha colpito più le aziende che i privati?


Con il reverse-engineering di WannaCry, la nostra priorità era identificare la modalità di diffusione del worm e la sua strategia per esplorare Internet alla ricerca di macchine da contaminare. Abbiamo notato che WannaCry ricorre a due modalità di scansione lanciate in multithreading. La prima consiste nella scansione della rete locale allo scopo di infettare le macchine connesse. Per non mettere in allerta gli strumenti che rilevano le intrusioni (IDS), il codice non supera mai il limite di dieci tentativi simultanei. Una precauzione che sembra indicare che a essere prese di mira erano sopratutto le reti aziendali interne.

La seconda modalità permette di eseguire la scansione di Internet con la creazione casuale di un IPv4 valido, generando uno a uno i quattro byte che compongono l’indirizzo ed eliminando gli IP che iniziano con 127 o con un byte >= 224. Quando un IP viene considerato vulnerabile, sembra che il worm tenti di eseguire la scansione dell’intera /24, che corrisponde ai 253 IP vicini. In base alla nostra analisi, le macchine infettate sono in grado di scansionare circa 30 IP/secondo.



Monitoraggio di un VPS infettato da WannaCry il 15 maggio 2017: la codifica sollecita molto il processore e consuma memoria, mentre la scansione della rete Internet mantiene un'attività più leggera della CPU.


Il timeout dei tentativi di manomissione costituisce un altro episodio interessante. Una tecnica utilizzata dagli esperti di sicurezza per rallentare la diffusione di questo tipo di malware consiste nel monopolizzare volontariamente la connessione per impedire a uno dei thread di eseguire la scansione (per fare in modo che resti in attesa della risposta dal server). Statisticamente è possibile mettere in pausa tutti i thread e bloccare gli scan. Questa tecnica è chiamata "tarpit". In questo caso, sembra che il creatore del worm abbia impostato un timeout di un’ora per chiudere la connessione in caso di mancata risposta da parte del server. Infine, ecco un altro elemento rivelato dall’ "autopsia" del codice: una macchina compromessa viene infettata anche da DoublePulsar, una backdoor utilizzata probabilmente dall’Equation Group per iniettare malware sulla macchina presa di mira. Questa stessa backdoor sembra essere riutilizzata per infettare ulteriormente una macchina con il codice di WannaCry.

Quale insegnamento possiamo trarre dalla dinamica di WannaCry? Prima di tutto, il suo codice utilizza le aziende come vettori di trasmissione privilegiati. Alcune scelte negli algoritmi ci hanno portato a questa conclusione. I parchi macchina delle aziende sono generalmente piuttosto omogenei; ci sono inoltre maggiori probabilità di trovare più rapidamente macchine vulnerabili su una rete locale, mentre la scansione dell’intera rete Internet è statisticamente meno efficace. Detto questo, se è vero che l’infezione dei server è meno massiva di quella delle postazioni aziendali, è altrettanto vero che è più importante dal punto di vista della propagazione di ransomware: un server possiede maggiori risorse e banda passante, moltiplicando la capacità del malware di ricercare su Internet macchine vulnerabili.



Chi ha la casa di vetro...


... non dovrebbe tirare le pietre contro quella degli altri. In altre parole, prima di voler salvare il mondo da WannaCry, dovevamo assicurarci che nessuna delle nostre macchine fosse compromessa.

La nostra politica interna di aggiornamento è molto rigorosa e prevede che le patch e gli aggiornamenti vengano installati sulle singole macchine subito dopo la loro pubblicazione. Tuttavia, nessuno può ritenersi completamente al riparo da una falla: la sicurezza informatica richiede una certa attenzione, ma anche una buona dose di modestia. Non bisogna mai pensare di essere invulnerabili. Il fattore preoccupante non era tanto la possibilità che l’infezione avesse colpito una macchina in produzione nel nostro sistema interno (le poche che utilizzano Windows sono monitorate con estrema attenzione), quanto scoprire che una VM utilizzata per effettuare test non era stata eliminata correttamente. In questo caso il problema non sarebbe stato la codifica dei dati da parte del ransomware, perché questi server sono in genere privi di contenuti interessanti, ma la presenza della backdoor DoublePulsar - che avrebbe permesso un’intrusione nei nostri sistemi - e la capacità del server di infettare altre macchine vulnerabili tramite la scansione della porta TCP/445, senza filtri attivi all’interno della rete OVH. E anche se la stampa ha ampiamente riportato le attività di WannaCry, ricordiamoci che non è l’unico malware a sfruttare queste vulnerabilità.



Identikit delle macchine infettate e vulnerabili


Non avendo trovato elementi da analizzare sulle macchine interne, ci siamo basati sui dati raccolti tramite la nostra rete di honeypot per disegnare l'identikit dei server a rischio di contagio da parte di WannaCry. Abbiamo così individuato diverse tipologie di server vulnerabili con sistema operativo Windows: alcuni VPS commercializzati direttamente o tramite reseller, server dedicati e VM Private Cloud con versioni di Windows 2008 o precedenti.



Ripartizione degli OS che eseguono la scansione della rete Internet caduti nella nostra rete di honeypot (quando le macchine infette contattano l’honeypot, comunicano la versione dell'OS durante i primi scambi). Si osservano soprattutto Windows Server 2008.


Questo ci ha portato a passare in rassegna le immagini distribuite da OVH per la preinstallazione e la reinstallazione dei sistemi operativi. Ci siamo allora resi conto che alcune immagini messe a disposizione non includevano le patch di sicurezza di Microsoft che correggevano la falla sfruttata da EternalBlue. Le immagini Windows fornite da OVH sono configurate per eseguire quotidianamente gli aggiornamenti automatici rilasciati da Microsoft, ma nel caso di Windows Server 2008 la porta era esposta pubblicamente all’avvio del Sistema Operativo e il server avrebbe potuto essere infettato prima di avere il tempo di aggiornarsi. Dovevamo quindi arginare il rischio effettuando la correzione senza aspettare le immagini Windows. La bassa velocità della piattaforma Microsoft Update ci ha suggerito che non eravamo gli unici alla ricerca della famosa patch…



Sabato 13 maggio l’aggiornamento dei template Windows ha richiesto del tempo... molto tempo. La piattaforma Microsoft Update girava a una velocità inferiore a 100 byte/secondo.


Abbiamo pubblicato i task relativi all’aggiornamento delle immagini Windows in tempo reale (2) e creato un robot per automatizzare l’aggiornamento e l’integrazione delle patch di sicurezza associate ai template Windows in futuro. Inoltre, abbiamo individuato l’insieme degli indirizzi IP delle macchine che avevano tentato di contagiare i nostri honeypot e sospeso i server in questione subito dopo aver avvisato i clienti coinvolti – un’iniziativa che prosegue ancora oggi. Abbiamo anche valutato attentamente la possibilità di interrompere temporaneamente gli scambi effettuati tramite la porta TCP/445 su tutta le rete OVH, ma questa misura, troppo radicale, rischiava di avere un impatto sui clienti che utilizzavano la condivisione di file Windows e avevano applicato correttamente le patch di sicurezza rilasciate da Microsoft due mesi prima. Abbiamo quindi deciso di sospendere il servizio degli utenti con server compromessi, inviando loro un messaggio per informarli del blocco dell’IP o dell'attivazione della modalità Rescue sul server:

"Your server is being used to conduct ransomware-spreading cyberattacks, we had to reboot it in rescue mode to stop the attack. If you have a Failover IP, we had to block it".

La "buona notizia" è che nessuno dei server infettati ha potuto contagiare altre macchine all’esterno della rete OVH, dal momento che il filtro applicato sulla porta TCP/445 impediva al worm di ricevere la risposta della sua potenziale vittima (il SYN-ACK non poteva essere ricevuto in quanto scartato dal router, e quindi la connessione TCP non poteva essere stabilita).



Principio di funzionamento dei filtri sul router perimetrale in caso di tentativo di infezione a partire da una macchina localizzata nella rete OVH.


Alla ricerca del paziente zero


In che modo hanno avuto inizio le scansioni della porta TCP/445 delle macchine ospitate in OVH nonostante il blocco della porta in entrata della nostra backbone? È una domanda che ci siamo posti immediatamente. Il nostro primo pensiero è stato controllare le regole applicate sui router. Invano: il filtro risultava attivo. Siamo allora tornati indietro nel tempo, analizzando gli eventi riportati nei NetFlows del nostro sistema di protezione anti-DDoS (VAC) per identificare l’IP che aveva iniettato WannaCry nella nostra rete. E' stato un processo a ritroso alla ricerca del colpevole. O meglio dei colpevoli, in quanto si trattava di PC infetti connessi a Internet tramite accessi xDSL forniti da OVH. Abbiamo osservato che, nella mattinata di venerdì 12 maggio, diversi IP associati ad accessi xDSL hanno iniziato a scansionare Internet per diverse ore, indipendentemente tra loro e alla ricerca di macchine vulnerabili. Come mostra il prossimo grafico, questi IP hanno iniziato progressivamente a infettare alcuni VPS e poi alcuni server dedicati. Potete capire facilmente che una connessione xDSL non ha la stessa forza d’urto di un server dedicato, soprattutto in termini di banda passante. Così, a partire dalla prima infezione di un server dedicato, abbiamo osservato una vera e propria esplosione di scansioni lanciate da macchine infette: la reazione a catena era iniziata.



Grafico del numero di IP che utilizzano la porta TCP/445 (in blu) e dei pacchetti monitorati (in grigio). Osserviamo una leggera impennata poco dopo le 12:00 del 12 maggio, corrispondente agli accessi xDSL infetti, prima che i server vengano contagiati tra le 15:00 e le 17:00 e provochino una vera e propria reazione a catena. Alle 20:00 un servizio di VPN fà esplodere il numero di IP che scansionano la rete prima di essere parzialmente bloccati. Il giorno dopo alle 15:00 è di nuovo un servizio di VPN a convogliare un gran numero di scansioni sulla nostra rete mentre applicavamo le contromisure necessarie. La situazione era sotto controllo dalle 20:00 di sabato 13 maggio per ritornare alla normalità il 14 maggio alle 5 del mattino.


Come prevedibile, sono poi entrate in gioco le VPN. Creando un tunnel protetto tra l’esterno e una macchina OVH, la VPN permette di evitare logicamente le regole della rete in entrata e, quindi, il divieto della porta TCP/445). I server che ospitavano i servizi VPN hanno iniziato a emettere un traffico molto intenso, in quanto in un servizio di questo tipo gli IP sono in genere condivisi. Il nostro sistema di rilevamento automatico dello scan delle porte si è spesso azionato, facendo uscire dalla rete le macchine coinvolte (riavvio in modalità Rescue).

Così, anche se i filtri in ingresso della rete non sono stati efficaci al 100% di fronte a questa epidemia particolarmente contagiosa, hanno comunque consentito di rallentarne la diffusione, lasciandoci più tempo per attuare le misure che hanno permesso di contenere il fenomeno a partire dal pomeriggio di sabato 13 maggio.



Killswitch: l’ultimo stratagemma dei malware per eludere i radar dei team di sicurezza


Avrete senz’altro letto la storia dell’esperto in Security che ha fermato la diffusione di WannaCry acquistando un dominio in grado di neutralizzare il ransomware. In molti si sono posti delle domande sul meccanismo, detto anche "killswitch", presente all’interno dello stesso codice del ransomware che consentiva di neutralizzarne la propagazione. Questo "pulsante di emergenza" è presente all’interno di diversi malware. Contrariamente alle apparenze, il killswicth non serve a neutralizzare il ransomware ma è un sistema di difesa destinato a complicare le analisi da parte dei team di sicurezza. Una volta che il ransomware viene catturato (si parla in questo caso di sample), gli esperti eseguono il file all’interno di una sandbox (un ambiente sicuro, isolato dalla rete) per effettuare il reverse-engineering del codice e comprenderne il funzionamento. È a questo livello che interviene il killswitch: con una chiamata di rete, che consiste ad esempio nel verificare l’inesistenza di un dominio (di solito generato casualmente), il ransomware ha la possibilità di rilevare se si trova all’interno di una sandbox (che simulerà una risposta positiva a questa chiamata, essendo isolata dalla rete e dovendo prepararsi ad altre chiamate di rete che saranno cruciali nell’analisi del sample). Se il sample intuisce di trovarsi in una sandbox e quindi di essere osservato da strumenti di profilatura, il ransomware non si attiva… impedendo ai nostri strumenti di mapparne il funzionamento. Chi installa i VMware Tools (presenti solitamente sulle macchine virtuali) sulla propria postazione di lavoro ha concrete possibilità di non subire attacchi, in quanto un gran numero di malware utilizza questo marcatore come possibile presenza di una sandbox.

Nel caso di WannaCry e del meccanismo utilizzato dal killswitch, il dominio non veniva generato casualmente: ecco perché, appena registrato, si è bloccata la propagazione. Bisogna però considerare che la diffusione potrebbe riprendere se il dominio tornasse disponibile o, come di fatto è avvenuto, con la comparsa di varianti con un codice simile ma un meccanismo di killswitch leggermente diverso.



Sei stato contagiato? Non cedere al ricatto!


Il pagamento del riscatto contibuisce ad alimentare le reti criminali e a dare modo a queste organizzazioni di sviluppare malware sempre più potenti e subdoli. A discapito della "reputazione" degli autori, che promettono di restituire i dati dopo il pagamento del riscatto (ciò di cui si vantano nel secondo messaggio inviato alle loro vittime, a loro avviso non abbastanza numerose ad aver pagato), sappiate che esistono persone molto meno scrupolose, che non esitano a cavalcare l’onda per fare soldi facilmente… Così, alcuni hanno contraffatto l’interfaccia grafica di WannaCryt0r, diffondendo un ransomware che invita a pagare anche se i file non sono stati cifrati. Attenzione alle truffe!

Nell'immediato, reinstallare i sistemi Windows e le patch di sicurezza rilasciate da Microsoft aggiornandole all’ultima versione disponibile è il modo migliore per arginare WannaCry.
Se si è fortunati, è possibile decriptare i propri dati grazie ad alcuni strumenti, come il progetto francese WannaKiwi, che ispeziona la memoria della macchina per trovare il tesoro perduto, o l'azienda Kaspersky Lab, che ha creato una piattaforma collegata ai diversi software che permette a chi è stato vittima di un ransomware di uscirne.

Ci si può rivolgere alle autorità competenti per sporgere denuncia e ottenere maggiori informazioni sulle possibili conseguenze penali. Infine, non lo ripeteremo mai abbastanza: non dimenticate di effettuare i backup dei vostri dati sensibili.

Durante questo attacco, in molti hanno segnalato siti Web completamente irraggiungibili. Se c’è la possibilità che anche il tuo sito si sia trovato in uno stato simile, cambia tutte le tue password, senza alcuna eccezione! Perché? Chiunque era in grado di scaricare i tuoi file, anche se cifrati. In questo modo si può impedire che il "config.php" venga decifrato e permettere l'accesso privilegiato al tuo database.



La minaccia non è scomparsa. Approfitta della copertura mediatica di questa epidemia per mettere la sicurezza IT in cima alla lista delle priorità della tua azienda!



« Conoscere il nemico significa conoscere se stessi. Se farai così, anche in mezzo a cento battaglie non ti troverai mai in pericolo.L’arte della guerra, Sun Tzu »





Come avrete capito, anche quando i media avranno distolto la loro attenzione da WannaCry, la minaccia resterà presente. Il grafico precedente mostrava un aumento dei tentativi di contagio negli ultimi giorni, effettuati da macchine infette a causa di varianti di WannaCry che continuano a contaminare nuove macchine vulnerabili. Del resto WannaCry non è il primo a sfruttare la falla presente nei sistemi Windows. Già molto prima di lui venivano utilizzate da "Adylkuzz" per infettare la macchina in vista di generare Monero, una criptovaluta alternativa al Bitcoin. Attualmente sono in circolazione numerosi malware basati su EternalBlue e i suoi simili: EternalSynergy, EternalChampion & EternalRomance. La comparsa di una botnet che utilizza questa stessa vulnerabilità per propagarsi e sferrare vasti attacchi DDoS, come accadde con MIRAI lo scorso settembre, è molto più probabilmente nelle ore immediatamente successive.



Esempio di un VPS infettato da Adylkuzz intorno alle 20:00: il mining consuma molta CPU e banda passante, mentre l’interruzione del servizio Samba libera la memoria.


Ricordatevi inoltre che una volta che una macchina è infetta, significa che su di essa è stata installata la backdoor DoublePulsar. La macchina resta quindi vulnerabile anche applicando la patch Microsoft MS17-010. Esisitono numerosi strumenti che permettono di sapere se la tua macchina è stata compromessa, come quello implementato dal creatore di "nmap", il famoso tool per l'esplorazione della rete.

In OVH sappiamo bene che credere che la minaccia scomparirà nei prossimi giorni è pura utopia. Questo pericolo resterà a lungo. Su Internet ci saranno sempre macchine da compromettere. Basti pensare alla falla sul servizio NTP rilevata nel 2013 e che, ancora oggi, continua a essere utilizzata per effettuare attacchi denial of service.

Quindi, quando avrete installato fino all’ultima patch su ogni singola macchina della vostra rete, dite a voi stessi che non tutti i mali vengono per nuocere. La copertura mediatica che ha conosciuto WannaCry ha aperto gli occhi di tutti sulla necessità di investire maggiormente nella sicurezza IT. Il capitale di un’azienda non è più rappresentato solo da beni immobili, risorse umane e reputazione. Anche i dati di una società, e per estensione il suo sistema informatico, sono beni preziosi. I tuoi colleghi o i membri del Comitato Esecutivo hanno gli occhi puntati su di te? Approfittane, prima che distolgano l'attenzione… fino alla prossima epidemia.



Note:


(1) Il 27 giugno 2016 Octave Klaba, fondatore e CEO di OVH, ha ricordato con un messaggio inviato su una mailing list interna che la porta TCP/445 della rete perimetrale di OVH è bloccata per motivi di siurezza. Questo blocco è attivo da ben 11 anni, e lo sarà per sempre. In un certo senso, l'aggiornamento che Microsoft ha apportato al suo sistema operativo segue questa direzione, in quanto consiste nel non esporre più di default questa porta, il cui utilizzo è stato concepito per lo scambio di file all'interno di una rete locale.

(2) I task pubblicati:
http://travaux.ovh.net/?do=details&id=24741
http://travaux.ovh.net/?do=details&id=24738
http://travaux.ovh.net/?do=details&id=24740
http://travaux.ovh.net/?do=details&id=24742
http://travaux.ovh.net/?do=details&id=24743