Exploit: cosa sono e quanto dura la finestra di rischio

Un exploit è il codice che trasforma una vulnerabilità in un accesso. Senza di lui la falla resta un difetto teorico, documentato da qualche parte e sfruttabile in linea di principio.

Con lui diventa una porta. La distinzione sembra accademica e non lo è, perché fra i due momenti passa del tempo. Quel tempo è la cosa che decide se un’azienda viene colpita o no.

1. Che cos’è un exploit
2. Vulnerabilità, exploit e payload
3. La finestra fra pubblicazione e correzione
4. Dove entrano davvero oggi
5. Exploit noti e zero-day
6. Come si riduce l’esposizione

Che cos’è un exploit

Il verbo inglese to exploit significa sfruttare, ed è esattamente quello che fa: sfrutta un difetto specifico in un software, in un firmware o in una configurazione per ottenere un comportamento che il sistema non avrebbe dovuto permettere.

Un exploit non è un malware. Non ruba dati, non cifra file, non resta sul sistema. È il passaggio che apre la porta; quello che entra dopo è un’altra cosa.

La confusione fra le due è frequente e porta a una conclusione sbagliata: che un antivirus basti. Un antivirus riconosce quello che entra, non il modo in cui è entrato. E se l’exploit sfrutta una vulnerabilità in un servizio legittimo, il sistema non sta facendo niente di anomalo: sta facendo quello che il codice gli dice di fare.

La pubblicazione della correzione rende pubblica anche la vulnerabilità. I primi sfruttamenti arrivano nei giorni successivi, molto prima che l’aggiornamento sia applicato ovunque: quella distanza è la finestra in cui un exploit funziona.

Vulnerabilità, exploit e payload

Tre termini che si usano come sinonimi e che indicano tre cose distinte.

La distinzione conta in fase di difesa, perché ognuna delle tre si affronta in modo diverso. La vulnerabilità si corregge con un aggiornamento. L’exploit si blocca limitando chi può raggiungere il servizio. Il payload lo intercetta il rilevamento, quando ormai qualcosa è già successo.

Il punto in cui conviene intervenire è il primo, ed è anche l’unico che dipende interamente da voi. Sulle vulnerabilità che non si possono correggere resta il secondo.

La finestra fra pubblicazione e correzione

Qui sta il meccanismo che decide quasi tutto, e ha una dinamica controintuitiva.

Quando un produttore pubblica una correzione, pubblica anche l’informazione su cosa correggeva. Il bollettino descrive il difetto, le versioni interessate e l’impatto. Da quel momento la vulnerabilità non è più un segreto di chi l’ha trovata: è pubblica, e lo è per tutti.

Nei giorni successivi compaiono le prime dimostrazioni funzionanti. Poi gli strumenti automatici che scandagliano internet alla ricerca di sistemi ancora vulnerabili. Il tempo che passa fra la pubblicazione e la comparsa di uno sfruttamento di massa si misura in giorni, a volte in ore.

E dall’altra parte c’è il tempo dell’azienda: la finestra di manutenzione da concordare, il collaudo, l’applicativo che potrebbe non funzionare più dopo l’aggiornamento.

Quello scarto è la finestra di rischio, ed è il punto su cui si gioca la partita. Non serve essere presi di mira: basta essere ancora vulnerabili quando lo strumento automatico passa.

È la ragione per cui vulnerabilità corrette da anni continuano a comparire nei rilievi. La correzione di Log4Shell è del dicembre 2021, e la finestra su quel difetto in molte aziende non si è mai chiusa.

Dove entrano davvero oggi

Per anni il modello di riferimento è stato il browser: un utente visita un sito compromesso, un exploit kit analizza la sua macchina e installa qualcosa sfruttando una falla del browser o di un componente aggiuntivo. Era il modello dominante fino alla metà degli anni Dieci, ed è quello che la maggior parte degli articoli sugli exploit descrive ancora.

Per un’azienda oggi il vettore principale è un altro: i servizi raggiungibili da internet.

Concentratori VPN, sistemi di trasferimento file, portali di gestione, applicazioni web esposte, interfacce di amministrazione aperte per un’esigenza temporanea. Sono sistemi che rispondono a chiunque li interroghi, e quando esce una vulnerabilità che li riguarda diventano bersagli immediati.

La differenza rispetto al modello del browser è sostanziale. Non serve che nessuno clicchi su niente. Non c’è un’email da riconoscere, non c’è un allegato da non aprire, non c’è un comportamento da correggere. C’è un servizio che risponde e una versione che non è stata aggiornata.

Le campagne più ampie degli ultimi anni hanno seguito esattamente questo schema: una vulnerabilità pubblicata, una scansione di massa nei giorni successivi, e centinaia di organizzazioni compromesse perché non avevano ancora applicato l’aggiornamento.

Exploit noti e zero-day

La distinzione classica è fra exploit che sfruttano vulnerabilità documentate e exploit zero-day, che usano difetti non ancora pubblici né corretti.

Gli zero-day sono quelli di cui si parla, perché sono spettacolari e perché non esiste una difesa diretta. Vengono venduti a cifre alte, usati con parsimonia e riservati a bersagli di valore, perché ogni utilizzo aumenta la probabilità che il difetto venga scoperto e corretto.

Ma nella grandissima maggioranza degli attacchi che colpiscono aziende ordinarie non c’è nessuno zero-day. C’è una vulnerabilità nota, corretta da settimane o da anni, su un sistema che nessuno ha aggiornato.

Questa è una buona notizia, se la si guarda bene. Contro uno zero-day non si può fare molto; contro un exploit noto si può fare tutto, e il costo è un aggiornamento.

C’è poi una terza categoria che si nomina meno: gli exploit che sfruttano difetti dell’hardware o del firmware. Sono meno frequenti e molto più difficili da correggere, perché l’aggiornamento passa dal produttore del dispositivo e in certi casi non arriva mai.

Come si riduce l’esposizione

Le misure che incidono sono poche e non richiedono strumenti particolari.

• Sapere cosa è raggiungibile. Un servizio esposto di cui nessuno ricorda l’esistenza non viene aggiornato, perché non compare in nessun elenco. È il motivo per cui l’inventario degli asset viene prima di qualsiasi altra misura.
• Ridurre quello che risponde. Ogni servizio raggiungibile da internet è una superficie in più. La domanda da farsi su ciascuno è se debba davvero essere pubblico, e in molti casi la risposta è che lo è diventato per un’esigenza temporanea di anni fa.
• Aggiornare con una priorità. Non tutti gli aggiornamenti hanno la stessa urgenza, e trattarli allo stesso modo porta a non farne nessuno. Quello che conta è dove si trova il sistema e cosa protegge, non solo il punteggio di gravità: il tema è affrontato nell’articolo su severity e priorità reale.
• Limitare cosa si raggiunge da lì. Un exploit riuscito su un sistema periferico è un incidente contenuto se quel sistema non parla con il resto della rete. Diventa un problema serio se ci parla.

Resta una cosa che nessuna di queste misure copre, e vale la pena dirla. Il percorso che parte da un exploit riuscito passa quasi sempre da credenziali: quelle trovate sul sistema compromesso, quelle riutilizzate altrove, quelle di un utente che ha risposto a un messaggio ben scritto.