OpenSMTPD, patch e il panorama della sicurezza odierno. Ne parliamo con Qualys

A fine gennaio Qualys ha scoperto una importante vulnerabilità in OpenSMTPD, il software utilizzato sui server OpenBSD per la gestione dei servizi di posta elettronica. La vulnerabilità scoperta permetteva di eseguire codice con permessi di root da remoto, mettendo a repentaglio la continuità operativa dei server e l'integrità dei dati contenuti al loro interno.

La vulnerabilità, i cui dettagli sono disponibili a questo indirizzo, è tanto semplice quanto efficace: quando viene ricevuta una email il programma controlla sia la parte locale che quella relativa al dominio dell'indirizzo email (ad esempio, "mario.rossi@dominio.it"). Nel caso in cui la parte locale non sia valida e il dominio sia vuoto, però, la funzione che si occupa di effettuare il controllo aggiunge semplicemente il dominio predefinito lasciando che il messaggio venga poi interpretato dalla shell. Qui si nasconde il vero pericolo, perché una email malevola appositamente creata può inserire comandi arbitrari fino a 64 caratteri, potenzialmente causando danni di notevole portata.

Ne abbiamo parlato con Marco Rottigni, Chief Technology Security Officer di Qualys per l'area EMEA, per avere maggiori dettagli.

Qualys e la vulnerabilità in OpenSMTPD: come affrontare le vulnerabilità nei sistemi?

Edge9: Come è arrivata Qualys a scoprire questa vulnerabilità e quali attività e strategie impiega normalmente per scoprire nuove vulnerabilità?

Marco Rottigni: Qualys ha investito negli scorsi due decenni nella creazione di centri di ricerca sulle vulnerabilità, il malware, la cyer threat intelligence e così via. Quello per cui siamo più conosciuti è la ricerca sulle vulnerabilità, distribuita a livello globale con diversi centri che esaminano una serie di fonti e una serie di piattaforme per fare attività di ricerca. L’attività più importante svolta da questi centri è di codificare un meccanismo di detection della vulnerabilità che sia il più possibile accurato; l’altra attività è quella di fare ricerca in proprio sulle vulnerabilità grazie a un laboratorio con migliaia di dispositivi business tra i più frequentemente utilizzati. Parte di questa ricerca avviene all'interno delle piattaforme che Qualys stessa utilizza per operare la propria piattaforma e infrastruttura IT. All'interno di questa attività abbiamo scoperto la vulnerabilità all'interno di OpenSMTPD.

L'accuratezza della rilevazione è un tema particolarmente caro a Qualys. Tipicamente un sistema di rilevazione delle vulnerabilità dà una quantità di informazioni che nemmeno il centro di elaborazione più fornito dell'azienda più potente è in grado di gestire: si parla di centinaia di migliaia se non di milioni di vulnerabilità nel panorama digitale di un'azienda moderna. Il tema fondamentale diventa quindi quanto è accurata la tecnica di rilevamento e quanto si possa essere certi che una vulnerabilità individuata non sia potenziale ma confermata (ovvero che ci sia sicuramente una falla che si può sfruttare). Ci sono vulnerabilità potenziali, nel senso che un software è sicuramente vulnerabile ma i meccanismi che permetterebbero a un attaccante di scardinare quella vulnerabilità e compromettere il sistema non sono esposti e, di conseguenza, la vulnerabilità è sicuramente presente ma non sfruttabile. L'accuratezza del rilevamento permette di confermare che tale vulnerabilità sia presente senza sfruttarla.

L'altro tema è quello di dare priorità alle vulnerabilità che è possibile rimediare in tempo. Vista l'enorme quantità di vulnerabilità è importante saper capire qual è il grado di attaccabilità e capire quanto un attaccante possa scardinare il sistema. Dal momento che bisogna proteggere per primi i sistemi più esposti e più critici, che contengono le logiche di business, il tema della priorità è fondamentale per tutte le aziende di tutti i settori del mondo in questo momento.

Edge9: Qualys dunque segue i propri clienti nel creare una strategia per chiudere le vulnerabilità trovate?

Marco Rottigni: La piattaforma Qualys permette di fare tre cose: comprendere cosa sia presente nel panorama digitale dell'azienda, identificare la superficie vulnerabile, identificarne la superficie attaccabile e mettere l'azienda nelle condizioni di individuare un rimedio. Ci sono poi anche dei sistemi di patch management, ovvero: non solo si è a conoscenza del rimedio, ma si sa esattamente cosa bisogna applicare e si può fornire questa informazione ad altre piattaforme usando una comunicazione basata su API per eseguire l'attività di patching in maniera automatica. È anche possibile affidare la soluzione a Qualys Patch Management, ovvero un altro modulo della piattaforma che sfrutta la stessa base di dati con cui si sono analizzati gli asset, determinate le vulnerabilità e assegnata la priorità per portare la patch direttamente a destinazione e applicarla.

Edge9: Nel caso in cui la patch non sia disponibile - prendiamo appunto il caso di OpenSMTPD nella piattaforma OpenBSD - come si comporta Qualys?

Marco Rottigni: Qualys segue i principi della responsible disclosure, ovvero della collaborazione con il vendor del software su cui individua la vulnerabilità. OpenBSD - e BSD in generale - è un sistema operativo che merita il massimo rispetto perché è stato sviluppato sulle fondamenta di UNIX da una comunità che ha sempre avuto la sicurezza quasi come un'ossessione e per questo OpenBSD è considerato uno dei sistemi operativi più sicuri sul mercato. Questa non è la prima vulnerabilità che Qualys scopre su OpenBSD; quello che ha sempre contraddistinto questa comunità è la velocità di reazione elevatissima e l'attenzione totale alle patch, tanto è vero che la vulnerabilità è già stata risolta e c'è già una patch disponibile.

Ciò è accaduto anche per le precedenti vulnerabilità, con la comunità che ha sviluppato patch nel giro di ore. È decisamente un tempo di reazione minimo se pensiamo alla complessità dell'individuazione della vulnerabilità e allo sviluppo di una soluzione che non vada a introdurre regressioni di altro tipo. Questo significa che i processi di controllo e di sviluppo del software hanno un'implementazione a livello di eccellenza, perché altrimenti non sarebbe possibile intervenire così velocemente.

La vulnerabilità scoperta su OpenSMTPD è davvero importante perché permette di passare del codice all'interno del campo indirizzo del mittente - codice che viene poi eseguito con diritti di root sulla macchina. Il tema non è quello di creare patch, vista la risposta stellare della comunità, né quello della qualità della patch. La vera sfida, che è anche la vera fonte di preoccupazione, sta nella velocità dei processi di patching delle aziende che usano OpenBSD e OpenSMTPD. Le aziende hanno processi di patching che nelle migliori delle ipotesi coprono trenta giorni, quindi un'esposizione di 30 giorni su vulnerabilità critiche diventa una fonte di attacco importante proprio per la velocità di esecuzione dell'attacco.

La scelta su quale sia il grado di urgenza rispetto al potenziale impatto sul business, che deve essere in ultima analisi fatta dal CISO [Chief Information Security Officer, la persona che deve gestire la sicurezza delle informazioni], è una scelta non sempre semplice. Ciò appare ancora più evidente se consideriamo che OpenSMTPD può essere usato anche in contesti di forniture di servizio in cui ci sono degli SLA [Service Level Agreement, contratti in cui si specifica il livello minimo di disponibilità del servizio]. Tutto ciò aggiunge complessità non tanto al rimedio delle vulnerabilità ma all'applicazione pratica di questo processo di rimedio.

Qualys: la sicurezza è un problema organizzativo delle organizzazioni

Edge9: Il problema della sicurezza non è dunque solo a livello di codice, ma anche (ed eminentemente) a livello organizzativo.

Marco Rottigni: È soprattutto un problema organizzativo! Questo è anche il motivo per cui Qualys non ha mai creduto nel vulnerability assessment fine a se stesso - che può essere fatto da dei penetration tester o da persone esperte di sicurezza. Deve esserci l'elevazione da vulnerability assessment a vulnerability management, che include anche il rimedio, e addirittura a threat vulnerability management, che prende in considerazione anche lo sfruttamento da parte degli attaccanti.

Ci sono due metriche importanti che vanno prese in considerazione e che vanno in contrapposizione l'una all'altra. Da un lato il cosiddetto time to weaponise, ovvero il tempo che la comunità degli attaccanti impiega a trasformare la vulnerabilità in un'arma d'attacco; questo tempo è in decrescita, tanto è vero che oggi non si parla più molto di zero day ma di vulnerabilità che vengono sfruttate in maniera facile perché restano per molto tempo prima di essere risolte. Per un cybercriminale è molto più facile ed economico investire in un'arma già creata o facile da creare rispetto a codificare uno zero day a partire da una ricerca di vulnerabilità.

L'altra metrica è il cosiddetto time to remediate, ovvero il tempo in cui si riesce ad applicare un rimedio efficace dopo la scoperta della vulnerabilità. Questo tempo dovrebbe essere tracciato e misurato perché rappresenta la metrica più precisa dell'efficacia dell'intero programma di sicurezza. Il tempo di reazione rappresenta il vero problema nella chiusura delle falle ed è il motivo per cui quando qualcuno arriva a occupare il primo posto sulle pagine dei giornali perché ha perso dati o è stato attaccato.

Le vulnerabilità tra cloud e on premise: il punto di vista di Qualys

Edge9: Il problema che si pone è anche quello della dualità dei sistemi, nel senso che il mondo attuale si sta spostando verso il cloud ma ha ancora una forte componente on premise. La gestione della sicurezza di questi due paradigmi è molto differente. Quanto incide lo spostamento dei sistemi verso il cloud sull'individuazione e la chiusura delle vulnerabilità rispetto al mondo on premise? Quanto differiscono i due modelli rispetto all'effettiva esposizione alle vulnerabilità?

Marco Rottigni: Se da un lato il punto focale diventa la velocità di reazione dell'azienda nel chiudere la falla su un sistema oppure nel rendere quel sistema irraggiungibile (che porta comunque al rimedio, ancorché temporaneo, della situazione), nel cloud il tema non è più la vulnerabilità intesa come falla software. I provider cloud sono di dimensioni tali e capacità tali in termini di infrastruttura e team di sicurezza, ma soprattutto hanno un business tale legato al fatto che il cloud sia costantemente aggiornato e operativo, che hanno tutto l'interesse a ridurre questi tempi di intervento a zero. Piuttosto spengono un pezzo di nuvola, lo aggiornano e spostano i clienti su un altro pezzo! Da questo punto di vista l'elasticità del cloud è quella che mi permette di fidarmi del fatto che il cloud sia non solo sicuro, ma sia anche patchato e aggiornato. 

Il tema si divide in due aree importanti: il primo è la comprensione dei clienti che usano il cloud di quello che si chiama shared responsibility model, cioè il modello a responsabilità condivisa tale per cui il cliente istanzia una propria macchina in ambiente cloud o usa le risorse in ambiente cloud per creare un parco applicativo. Per creare un'applicazione oggi ci sono due alternative: si crea un'istanza di una macchina Linux o Windows e ci si installa l'applicativo, oppure si stanziano risorse come un'istanza di database, un pezzo di storage, un'unità computazionale e li si mette in comunicazione l'uno con l'altro; nel primo caso sto usando un modello infrastructure as a service, nel secondo platform as a service.

Il modello a responsabilità condivisa è molto chiaro dal punto di vista del service provider, ma raramente compreso dai clienti: se installo una macchina Windows bucata come un pezzo di groviera svizzero è mia la responsabilità nel tenerla aggiornata! Se la macchina viene scardinata da un attaccante non importa che sia installata in cloud: è mia la responsabilità di mantenere la macchina aggiornata e patchata. In questo caso le sfide sono le stesse di un ambiente tradizionale amplificate dall'esposizione pressoché pubblica della macchina in cloud.

Nel secondo caso ci si può fidare del fatto che un database sul cloud Amazon sia aggiornato, ma bisogna fare attenzione ai controlli di sicurezza che si applicano a quell'istanza di database perché se si dimentica la cifratura dei dati o il cambio della password di default poi si arriva a quei leak di dati di cui si parla costantemente. In cloud il modello di sicurezza cambia perché bisogna fare molta più attenzione al rispetto della compliance, ad esempio con i controlli CIS, rispetto a un ambiente più tradizionale dove invece è l'intero processo di configurazione e patch del software che è a proprio carico.