Sono apparsi in questi giorni più rapporti che analizzano le vulnerabilità usate nelle intrusioni contro infrastrutture ICT che dimostrano che sempre più frequentemente vengono rilevate intrusioni che utilizzano vulnerabilità 0-day.
I numeri di 0-day di cui è stato rilevato l’utilizzo non sono perfettamente identici nei vari rapporti e vanno da 58 a 66. Anche il più piccolo di questi numeri è comunque più del doppio sia di quello rilevato nel 2015, anno che fino ad ora aveva visto il massimo uso di 0-day, sia delle 25 vulnerabilità rilevate lo scorso anno. Inoltre, il maggior uso di 0-day è stato uniforme in tutto l’anno come già provato dai dati raccolti alla fine del secondo e del terzo trimestre del 2021.
Si tratta, quindi, di una tendenza costante più che di una crescita anomala e temporanea provocata da una qualche situazione contingente. Un’altra interessante caratteristica è che la singola 0-day rilevata viene utilizzata in più intrusioni e non in modo mirato in una singola intrusione, comportamento tipico di un gruppo che opera per conto di uno stato.
Vi sono più ragioni per spiegare l’aumento nel numero di rilevazioni di 0-day. Non sono mutuamente esclusive e ognuna ha un suo ruolo nello spiegare il fenomeno.
Indice degli argomenti
Una migliore capacità di analisi
Una prima ragione della scoperta di un maggiore utilizzo di 0-day è una migliore capacità di rilevazione delle intrusioni e di ricostruire la timeline delle azioni dell’attaccante. Non si tratterebbe quindi di una nuova strategia degli attaccanti ma di una migliore capacità di analisi da parte dei difensori.
Questa migliore capacità di analisi può permettere di individuare i vari passaggi della catena di attacco e quindi di scoprire che in un certo punto un meccanismo di difesa è stato violato usando una 0-day. In molti casi, in passato, ci si limitava a spiegazioni basate sulle eccezionali competenze dell’attaccante. Una conferma viene anche dal tempo, in media estremamente lungo, per scoprire un’intrusione.
Quando l’intrusione viene scoperta più di 100 giorni dopo che ha avuto luogo, può essere molto complesso individuare il momento esatto in cui è avvenuta, e quindi determinare se le vulnerabilità usate erano o no pubbliche quando sono state utilizzate.
Migliori capacità di rilevazione e di logging delle informazioni semplificano la classificazione delle vulnerabilità usate.
Infrastrutture più complesse
Una seconda spiegazione è la maggiore complessità delle infrastrutture utilizzate. Un’infrastruttura ICT che poggia su una architettura cloud, invece che su una fisica, ha un numero di livelli e di componenti molto più elevato e richiede una catena di attacco più lunga.
È possibile che in alcuni passaggi di questa catena convenga usare 0-day per accelerare l’attacco o perché nel caso di attacchi contro infrastrutture fisiche i componenti da attaccare erano diversi. In questo caso, la necessità di attaccare per la prima volta alcuni moduli può spiegare l’uso di 0-day.
Questa spiegazione è confermata dal fatto che la criticità di molte delle vulnerabilità usate non è particolarmente elevata se misurata, per esempio, con il Common Vulnerability Scoring System.
Ciò potrebbe confermare che le 0-day vengono usate per fondere più sottocatene in una singola catena più che in un singolo attacco contro una infrastruttura.
Il mercato delle 0-day
Terza considerazione è legata al fatto che da tempo conosciamo l’esistenza di un mercato delle 0-day dove molti ricercatori di vulnerabilità trovano più conveniente mettere in vendita quanto scoperto che comunicarlo al produttore perché venga prodotta una patch o una qualche contromisura. Se, in passato, solo attaccanti in qualche modo supportati da uno stato potevano permettersi l’acquisto di 0-day, ora la situazione è cambiata per il diffondersi di ransomware e per l’intero ecosistema che ruota intorno agli attacchi ransomware.
Consideriamo, ad esempio, la presenza di ransomware-as-a-service in cui un gruppo criminale produce un malware per attacchi ransomware, che poi fornisce a più gruppi di criminali che lo usano nei loro attacchi e girano al fornitore del malware parte dei loro profitti. Il volume dei riscatti pagati e la presenza di un basso numero di famiglie di malware rispetto al numero degli attacchi permette una stima del rapporto costi/profitti del costruttore.
Questo rapporto indica che il costruttore di malware può pagare cifre non banali per una vulnerabilità 0-day che migliori significativamente la probabilità di successo del malware che produce, e aumenti l’insieme dei target possibili.
Nel caso del ransomware, anche un costo di alcune centinaia di migliaia di dollari per la vulnerabilità può essere ammortizzato visto che questo è il valore del riscatto medio. In breve, le risorse finanziare a disposizione del crimine non sono molto inferiori a quelle che possono utilizzare gruppi di attaccanti sponsorizzati da uno stato.
Tra l’altro, grazie alla scrittura di malware particolarmente efficaci, il fornitore di malware può acquisire nuove quote di mercato eliminando alcuni concorrenti. Sempre in riferimento all’ecosistema criminale per la produzione, distribuzione ed utilizzo di malware per ransomware, non è da escludere che nell’ecosistema siano apparsi attori specializzati nella ricerca di vulnerabilità per ransomware. Le vulnerabilità scoperte vengono poi trasmesse al fornitore di malware, senza nemmeno apparire sul mercato delle 0-day.
Tecniche di attacco
Un’interessante considerazione nel rapporto del team del Project Zero di Google, molto attivo nella raccolta ed analisi di 0-day, riguarda le tecniche di attacco. In particolare, il team segnala che mentre è stato rilevato l’utilizzo di vulnerabilità 0-day non sono ancora state rilevate nuove tecniche di attacco. Ovvero sappiamo che gli attaccanti usano nuove vulnerabilità in vecchie tecniche ma non abbiamo informazioni su eventuali nuove tecniche di attacco.
Osservazione estremamente corretta, e forse l’analisi di vulnerabilità e tecniche potrebbe migliorare se venissero condivise maggiori informazioni che permettano di analizzare i vari passi dell’ intrusione.
Strategie di difesa
Dando per scontato un maggiore utilizzo di 0-day in tecniche note, resta da capire se e come sia possibile difendersi in questo contesto. Una prima strategia reattiva è migliorare la rilevazione di intrusioni.
Questo miglioramento è già in atto, come dimostrato dalla scoperta dell’utilizzo di 0-day, ma deve essere rafforzato. In particolare dovranno essere privilegiati quei SIEM che permettono la correlazione di attacchi e possono scoprire anelli mancanti nella catena di attacco che viene usata. Questi anelli mancano perché l’attaccante è in grado di sfruttare 0-day che i nostri sensori di intrusione non possono rilevare, ma la cui presenza può essere dedotta ragionando su tutta la catena usata.
Il ragionare su tutta l’intrusione invece che focalizzarsi sui singoli passi, come fa un sensore di intrusione, è fondamentale per ricostruire tutta la catena ed, in particolare, parti mancanti della catena. Ciò è anche utile per scoprire nuove tecniche di attacco.
Analisi what if
Una diversa strategia proattiva che ragiona ancora sulle possibili catene d’attacco è quella che sfrutta un’analisi what if. Questa analisi ipotizza l’esistenza di una vulnerabilità sconosciuta in un qualche componente, scopre le eventuali catene di attacco che la vulnerabilità permette di costruire e le interrompe operando sulle vulnerabilità note che la catena utilizza.
Il grande vantaggio di operare considerando non gli attacchi isolati ma le catene, o percorsi, di attacco è proprio che possiamo interromperle operando su una singola vulnerabilità che abilita uno degli attacchi nella catena. Basta quindi conoscere una contromisura per una delle vulnerabilità usate per interrompere la catena e fermare l’attaccante.
Implementare una analisi what-if è ovviamente molto più sofisticato che eseguire un penetration test, che può lavorare solo sulle vulnerabilità note a chi esegue il test.
Il possibile utilizzo di vulnerabilità sconosciute riduce quindi ulteriormente l’affidabilità dei risultati di un penetration test. Attualmente, le uniche soluzioni in grado di eseguire in modo automatico analisi di tipo what-if sono quelle che usano un modello o twin del sistema da difendere. In questo modo, si estende alle infrastrutture informatiche la tecnologia del gemello informatico molto popolare per manutenzione predittiva nell’industria 4.0.
Difendersi con la segmentazione
Assumendo di aver scoperto, in modo proattivo o reattivo, il possibile uso di 0-day in un’intrusione esiste, un’ulteriore strategia di difesa da utilizzare in modo integrato con l’ interruzione delle catene di attacco. Questa strategia è la difesa in profondita che richiede una segmentazione delle reti in sottoreti, separate da opportuni firewall.
Allungando le catene di attacco, la segmentazione ostacola l’utilizzo di 0-day perché impedisce all’attaccante di poter interagire con modulo contro cui lanciare l’exploit 0-day.
In altre parole, l’attaccante deve ottenere un maggior numero di privilegi per eseguire l’attacco e ciò richiede sicuramente più tempo e l’utilizzo di un maggior numero di exploit, semplificando la rilevazione dell’intrusione e diminuendo la probabilità che essa abbia successo. È spesso utile utilizzare anche la microsegmentazione, allocando su macchine virtuali diverse le applicazioni che sono allocate ad uno stesso nodo.
Questa ulteriore segmentazione, naturale e poco costosa quando si lavora su architetture cloud crea ulteriori ostacoli ad un attaccante anhe se può utilizzare 0-day.
Pensiamo alle infrastrutture
Infine, l’accenno alla defence in depth e alla segmentazione, mi permette un commento a un’altra notizia che ha avuto grande risalto in questi giorni: l’attacco con successo ad un sistema per il controllo industriale, ICS, in una delle tante competizioni di tipo capture-the-flag che tanto hanno fatto per aumentare la sicurezza delle nostre infrastrutture. Questo successo ha provocato forti lamenti che si sono uniti a quelli dovuti ai tempi lunghi richiesti dal patching degli ICS in infrastrutture critiche.
Difficile capire queste lamentele, perché chiunque opera su infrastrutture critiche sa da tempo che molte normative esistenti impongono di utilizzare ICS che sono stati patchati solo dopo una serie di controlli sul comportamento di tali ICS da parte di enti terzi.
Queste norme sono del tutto ragionevoli e giustificate dal rischio generato dall’utilizzo di ICS non patchati in modo corretto. Le normative fanno si che sia conveniente concentrare un gran numero di patch in un singolo intervento per ridurre i costi dell’ispezione dell’ente terzo. Ciò dilata i tempi per il patching.
Il vero problema non è quindi se e quante volte si patchano gli impianti di controllo, ma quello di segmentare le infrastrutture informatiche in modo che non sia possibile, come purtroppo spesso avviene, un accesso diretto all’ICS da una rete remota.
Se si utilizza una segmentazione corretta, l’accesso di un attaccante ad un ICS diventa estremamente complesso e può richiedere uso di più 0-day. Ciò riduce la probabilità di una intrusione e quella di successo dell’intrusione tentata, e quindi possiamo operare in modo sicuro anche se nell’ICS sono presenti delle vulnerabilità.
Spesso dimentichiamo l’importanza dell’architettura complessiva sulla sicurezza di una infrastruttura ed adottiamo un approccio alla sicurezza che pare considerare i patch e la rilevazione delle intrusioni le uniche armi a disposizione del difensore.
Fortunatamente non è cosi, perché l’arsenale del buon difensore comprende anche, ma non solo, segmentazione, analisi what-if e correlazione degli attacchi in percorsi di attacco.
Ricordarlo è il primo passo di una strategia difensiva efficace.
