Questo sito utilizza cookie per raccogliere informazioni sull'utilizzo. Cliccando su questo banner o navigando il sito, acconsenti all'uso dei cookie. Leggi la nostra cookie policy.OK

Direttore responsabile Alessandro Longo

l'attacco globale

Wannacry, le sciocchezze che dicono gli “esperti”

di Alberto Berretti, Università degli Studi di Roma “Tor Vergata”, autore di "L'Impero del Malware"

16 Mag 2017

16 maggio 2017

La situazione attorno a Wannacry è molto complessa e non serve cercare di applicare a quanto successo soluzioni o spiegazioni semplicistiche. Occorre, certo, cambiare mentalità e cominciare a dare alla sicurezza informatica il budget e l’attenzione che merita. Ma non tutto si riduce a questo

Tra le tendenze naturali dell’uomo vi è quella a trovare una spiegazione semplice per ciò che accade: e questo è sicuramente, nel lungo periodo, un fatto positivo, perché è la spinta che indirizza la mente umana verso quella comprensione razionale del reale che chiamiamo “scienza”. Il problema nasce quando cerchiamo spiegazioni troppo semplici, o quando tentiamo di assegnare con facilità – che sconfina troppo spesso nella faciloneria – responsabilità e colpe.

Questo principio appare in tutta la sua evidenza leggendo i commenti e le discussioni – sì, anche fra esperti – sulla vicenda del ransomware che ha colpito negli ultimi giorni una quantità di organizzazioni, tra cui, pesantemente, il servizio sanitario nazionale inglese. Vediamo di che si tratta.

(1) “È colpa dell’NSA che sviluppa cyberarmi”. Questo è un discorso molto frequente, ed incolpare gli amerikani cattivi è sicuramente un selling point molto efficace giornalisticamente. Il malware in questione utilizza in effetti delle vulnerabilità che fanno parte dell’arsenale dell’NSA trafugato e diffuso da un gruppo di hacker che si sono fatti chiamare “Shadowbrokers”, gruppo che con una certa probabilità potrebbe far capo all’intelligence russa.

Ci si dimentica il dettaglio che l’NSA è un’organizzazione di intelligence, e che l’intelligence nel XXI secolo si fa in parte – in una parte significativa – con tecniche digitali. L’NSA starebbe sprecando i soldi del contribuente americano se non avesse dei tool del genere. Una volta avvenuta la pubblicazione di questi tool, Microsoft ha rilasciato delle patch in tempi piuttosto celeri per correggere le falle che tali tool sfruttavano: la patch che correggeva la vulnerabilità sfruttata dal malware “WannaCrypt”, la MS17-010, è del 14 marzo scorso. Semmai è Shadowbrokers che ha rilasciato le vulnerabilità in modo irresponsabile: ma cos’altro ci si aspetta da un’organizzazione criminale?

Piuttosto, si può accusare l’NSA di leggerezza nella custodia di questi strumenti. Questo è un discorso molto complesso e delicato, e non credo che tutti quelli che commentano in materia siano esperti di intelligence. È molto probabile che la compromissione sia avvenuta tramite l’utilizzo di contractors, di esterni; e sicuramente un problema serio di sicurezza interna l’NSA ce l’ha (leggere alla voce “Snowden”…). Ma chi accusa l’NSA per il worm non ha certo in mente di migliorare la sicurezza di tale agenzia, che probabilmente vede come il fumo negli occhi.

(2) “Se le patch erano disponibibili fin da marzo, è colpa dei sistemisti delle organizzazioni colpite, che non hanno applicato tempestivamente tutte le patch”. In realtà è anche peggio: molti computer colpiti dal malware avevano Windows XP, che è fuori manutenzione da tre anni e che quindi non ha più (in realtà post factum Microsoft ha rilasciato una patch per MS17-010 anche per Windows XP, ma i buoi sono già scappati dalla stalla).

Può sembrare facile applicare le patch, far girare cioè “Windows Update”, una cosa da cinque minuti. Bene, a parte che nemmeno nel proprio computer di casa è una cosa da cinque minuti nella maggioranza dei casi (chi scrive ha tentato di aggiornare la propria macchina virtuale con Windows 7 ieri sera e dopo tre ore ancora tutte le patch non erano state installate), un conto è il contesto domestico, o quello di una piccola azienda, un conto è l’ambito corporate dove entrano in gioco tutta un’altra serie di questioni.

Innanzitutto, sebbene tutti gli aggiornamenti di Windows siano testati e controllati da Microsoft prima di rilasciarli, come è ovvio, ci sono una quantità di problemi che possono manifestarsi in fase di installazione degli aggiornamenti, problemi che non si sono realizzati nella fase di testing presso Microsoft: non tutte le configurazioni possono essere testate, non tutte le condizioni d’uso. Provate a fare una ricerca su Google di “Windows Update breaks”: avrete una quantità di pagine web in cui si riporta come un aggiornamento ha compromesso la funzionalità di qualche applicazione, o anche dell’intero sistema. Chi utilizza Windows in apparecchiature mission-critical dunque ci pensa due volte prima di fare aggiornamenti e li controlla ancora nel suo contesto di lavoro specifico prima di farli. Esistono tonnellate di applicazioni, stand-alone o web based, utilizzate in ambito corporate che possono rompersi semplicemente aggiornando il browser web: e la colpa non è in questo caso di Microsoft, né dell’utente, ma di chi ha scritto l’applicazione.

Il lavoro di ricontrollare ogni patch per verificare che non dia problemi nel contesto specifico non costa poco: non solo le ore di lavoro impegnate, ma anche la necessità di avere hardware “sacrificabile”, dei “muletti” sostanzialmente. Il problema diventa valutare se l’investimento in prevenzione del rischio informatico (che include procedure biecamente manageriali tipo appunto la gestione degli aggiornamenti) paghi: secondo chi scrive sì, eccome, ma mi pare chiaro che l’opinione degli esperti di informatica in generale e di sicurezza informatica in particolare sia un po’ biased, e comunque non bisogna convincere me ma il top management delle aziende.

Ma è ancora peggio: le patch potrebbero non essere applicabili, o il sistema operativo, non più supportato come Windows XP oramai da anni, potrebbe non essere aggiornabile ad uno supportato.

Non abbiamo elementi certi, e l’applicazione del dubbio sistematico a qualunque informazione ci arrivi dalla stampa non aiuta a ricostruire la vicenda. Non sappiamo se le interruzioni di servizio clamorose (i cartelli nelle stazioni ferroviarie, i servizi ospedalieri, la fabbrica Dacia in Romania che si ferma: insomma non solo qualche desktop su una scrivania, facilmente aggiornabile con un minimo di perdita di tempo da parte dell’impiegato) siano dovuti esattamente e con precisione a cosa, a quale rete erano connessi, come e per quale ragione. Tutti elementi senza i quali una valutazione di dove stanno le responsabilità è impossibile. Possiamo però, per fare un esperimento mentale, immaginare qualche scenario.

Immaginiamo il caso di un macchinario per utilizzi medici in un ospedale (che so, una macchina per la risonanza magnetica: non ho idea di come funzionino, è solo un’ipotesi). Macchine che possono costare migliaia o decine di migliaia di euro. Immaginiamo che questa macchina abbia un sistema embedded basato su Windows XP, sistema che contiene ovviamente dei device driver custom scritti ad hoc per l’hardware in questione. La macchina potrebbe avere facilmente cinque, sei, sette anni: non è il genere di cose che si cambia così come un cellulare. La ditta che l’ha sviluppata potrebbe non esistere più, ad es. potrebbe essere stata assorbita da un’altra ditta che sviluppa una linea di macchine distinta e che non mantiene più la vecchia linea della società che ha acquisito – sto ovviamente inventando, ma lo scenario è plausibile. Cosa fa l’ospedale, butta via un macchinario perfettamente funzionante e ne compra un’altro nuovo di zecca perché il software on board ha una vulnerabilità che qualche criminale potrebbe divertirsi a sfruttare? Provatelo a spiegare al manager dell’ospedale e ne riparliamo. Questo scenario, en passant, rende anche nullo il discorso “facciamo girare XP in una macchina virtuale”: l’XP del sistema embedded ovviamente deve girare sul bare metal, come si suol dire.

Ovviamente quello descritto è uno scenario limite. Ma perfettamente plausibile, dettaglio più, dettaglio meno. Il supermercato dove faccio la spesa ha le casse che girano con Windows Embedded POS Edition 2009, basato su Windows XP, e la fotocopiatrice che ho in Dipartimento ha Windows Embedded come OS (non so che versione) ed è ovviamente collegata in rete.

(3) “Ma i manager dell’infrastruttura informatica avrebbero dovuto mettere tutti i sistemi vulnerabili in una rete separata, controllata, air gapped…”. Sì, probabilmente sarebbe stata una buona idea. Peccato che dal punto di vista pratico questo vuol dire modificare una infrastruttura di rete locale anche dal punto di vista fisico (o solo logico se utilizziamo VLAN e ci fidiamo). Non è gratis (né come costi di personale né come costi di materiale), non è necessariamente facile da fare, e non risolverebbe necessariamente il problema, come sanno gli iraniani dell’impianto di arricchimento dell’uranio di Natanz (sto alludendo alla vicenda del worm Stuxnet).

(4) “Ma questi non capiscono nulla, dovevano fare i backup!”. Ovviamente. Ma chi ci dice che i backup non esistono? Pensate ad un attacco di ransomware che mette fuori uso qualche centinaio di computer. Quanti ci vuole per (a) ripulire i sistemi dal malware (b) ripristinare i backup dei dati? Che nel mondo reale ci sia un periodo che può passare da qualche ora a qualche giorno di down mi sembra ragionevole.

(5) “Basta con Windows! Passiamo tutti a Linux!”. Bene, chi scrive utilizza praticamente solo Linux ed è un fervente sostenitore dell’open source, quindi questo discorso, perlomeno con me, sfonda una porta aperta. Il problema è che non la deve sfondare con me ma con i responsabili IT di una quantità di aziende medio-grandi che hanno svariate buone ragioni per non seguire questo consiglio – purtroppo, aggiungo io.

Innanzitutto, vi sfido a (a) implementare tutto quello che si può fare su una rete Microsoft fatta bene (Active Directory etc.) utilizzando Linux (b) avere su tutta la baracca manutenzione, assistenza, e così via. Quando ci sarà una soluzione di questo tipo efficace, economica e mantenuta ne riparliamo. Ovviamente auspico questa soluzione, ed è possibile che questi eventi spingano in questa direzione: semplicemente ancora non ci siamo. Sono anche convinto che “più embedded Linux e meno embedded Windows” sia una cosa molto positiva – e che ha maggiori probabilità di realizzarsi: Linux ha molto successo nei sistemi embedded. Staremo a vedere.

Inoltre, bisogna tenere conto della situazione di partenza: una migrazione da Windows a Linux a fronte di risparmi ha anche dei costi (come minimo di training degli utenti). Li vogliamo mettere in conto?

Infine, per quanto io possa preferire software open anche dal punto di vista della sicurezza, chi ci dice che dal momento in cui Linux non diventa un target di alto profilo in termini di utilizzo non si manifestino vulnerabilità altrettanto gravi di quelle che troviamo in Windows? Anche Linux – kernel, sistema operativo ed applicazioni, l’intero ecosistema – è software scritto da umani che commettono errori esattamente come quelli che scrivono software per Windows.

Ci troviamo quindi in una situazione complessa. Non sto ovviamente sostenendo che non esistano soluzioni, ma che le soluzioni saranno sicuramente parziali e incrementali, e soprattutto verranno “dal basso”, diverse in contesti e settori diversi. Certamente occorre attenzione a scrivere applicazioni (sia stand-alone che web-app) che siano robuste rispetto agli aggiornamenti dell’OS. Certamente è necessario che le grandi organizzazioni diano alla sicurezza informatica il ruolo che giustamente gli compete anche in termini di budget. Certamente chi sviluppa sistemi embedded deve progettarli pensando alla loro aggiornabilità come elemento essenziale e chi li acquista deve prevedere e pianificare i loro aggiornamenti. Certamente occorre riconoscere la complessità come il maggiore nemico della sicurezza nello sviluppo del software e regolarsi di conseguenza. Ma non sono cose che si risolvono in pochi giorni. Nel frattempo, non resta che aggiornare i sistemi Windows e bloccare sul firewall le porte 139 e 445.

 

  • Leandro Gelasi

    Articolo che condivido totalmente e molto ben scritto. Troppa gente straparla senza aver gestito nulla di più di una rete casalinga. La realtà è che le infrastrutture di difesa serie costano centinaia di migliaia di euro all’anno e che tantissime realtà non possono permettersele. Paradossalmente è più semplice proteggere i server da attacchi di questo genere che i client (che scontano la presenza umana nell’equazione del rischio).
    Detto questo, la triste realtà è che moltissimi manager ICT (specie in pubblica amministrazione) non sono adeguati al loro compito, più in termini culturali che tecnici. Sempre ammesso che un manager ICT nell’organizzazione esista.

  • Che la situazione sia complessa non c’è dubbio. Ma credo che sia altrettanto vero che il rischio venga costantemente sottovalutato (e, in certi casi, addirittura ignorato). Che vada giù la rete di una piccola azienda può essere comprensibile, ma non che si fermino servizi essenziali – come è successo in mezzo mondo, stando alle fonti giornalistiche: non è accettabile. Strutture di una certa rilevanza economico o sociale dovrebbero avere delle efficaci e testate procedure di disaster recovery in grado di garantire il funzionamento dei servizi essenziali qualsiasi accidente capiti. Il problema non è informatico, ma esclusivamente economico: strutturarsi costa, manutenere costa, testare gli aggiornamenti prima di andare in produzione costa, e via di questo passo. Meglio la logica del ‘tanto funziona’, che impera un po’ ovunque. E certo, non aiuta la memoria corta: il virus sasser, nel 2004, che utilizzava tecniche di propagazione analoghe a wannacry, colpì centinaia di migliaia (se non milioni) di PC e causò danni per miliardi di euro. Anche in quel caso, il consiglio era quello di aggiornare i PC e bloccare la porta 445.

    • albbrt

      Voglio solo fare una precisazione: il numero di host colpiti da wannacry sembra essere minore (anche molto) ad altri malware: ad es. conficker ~10 milioni, contro i <100 mila di wannacry; traetene le conseguenze… Concordo sulla necessita' di forme serie di hardening, arrivando all'hardening delle procedure manageriali e del layer "umano" (gli utenti).

  • Sandrino

    “Ci si dimentica il dettaglio che l’NSA è un’organizzazione di intelligence, e che l’intelligence nel XXI secolo si fa in parte – in una parte significativa – con tecniche digitali.”
    Parlando di sciocchezze, giustificare una cosa del genere e’ altrettanto sciocco. Le falle di sicurezza (scoperte/acquisite e non riportate) da NSA potevano tranquillamente essere in possesso allo stesso tempo da altre organizzazioni criminali. Il compito di NSA e’ proteggere (https://www.nsa.gov/what-we-do/). Mettere a repentaglio la sicurezza informatica mondiale per un vantaggio tattico per lei non e’ criminale?

    • albbrt

      Come dirlo meglio di Defense One, blog del gruppo Atlantic Media?

      http://www.defenseone.com/technology/2017/05/stop-blaming-nsa-ransomware-attack/137893/

      • Sandrino

        Ho deciso di seguire il suo consiglio, ma mi sono spinto a leggere addirittura oltre il titolo.

        NSA ha quindi una addirittura una procedura, e si riuniscono per decidere quali vulnerabilita’ riportate. E se si accorgono che sono cadute in mani sbagliate allora rimediano.
        Ottimo. Conferma il suo punto di vista patriottico.

        Dunque.. quanto spesso si riuniscono? una volta al mese? Ogni settimana? Ogni sei mesi?
        Il pezzo forte: “As soon as we see any indications of that, then that decision immediately flips, and we move to disseminate and remediate.”

        Adesso le consiglio di rileggere il punto 2 del suo articolo. Ammette lei stesso che ci vorranno mesi solo per aggiornare i sistemi con windows update.

        Domanda.. Mettiamo caso che una falla cada nelle mani di un’organizzazione criminale, quanto tempo ci vorra’ per:
        1) Scoprirlo (e la sfido a dirmi come farebbero in maniera efficiente)
        2) Riunirsi a decidere
        3) Far riparare la falla
        4) Aspettare che si verifichi quello che lei spiega nel punto 2?

        Le sembra gestibile e appropriata come procedura? Su una cosa terribilmente veloce a diffondersi come un virus?

        Se invece, *ANNI FA* NSA avesse confidenzialmente detto a microsoft di questa falla (ai tempi quando Windows XP veniva ancora aggiornato) niente di questo sarebbe accaduto.

  • elena

    Bravo! Condivido ogni parola, le virgole e pure gli spazi! Aggiungo però che forse questo ‘scandalo’ di wannacry è stato esagerato dai media rispetto all’effetto concreto che ha avuto. Come altri hanno osservato, il numero di pc infettati è stato molto ridotto rispetto ad altre volte, e c’era pure un killer switch… Secondo me qualcuno ha voluto spaventare, far capire anche a chi finora non ascoltava, che basta un attimo e se non si è investito adeguatamente in sicurezza possono capitare davvero guai molto seri. E’ stato un altolà, speriamo che appunto sia servito a far ripensare il modo in cui sono scritti i sw specie delle infrastrutture critiche, e a far aprire i cordoni della borsa a chi -beato lui- può mitigare i problemi cambiando semplicemente s.o. o pc., o assumendo un informatico che si occupi degli aggiornamenti (cosa che nel mio ente non sempre avviene)

  • ffioren

    Sul “caso limite” dell’apparecchio per la risonanza magnetica … mi sembra evidente che questi apparati devono rientrare nella governance della sicurezza IT!

Articoli correlati