BlueKeep CVE-2019-0708: perché è ancora un problema nel 2026

A maggio 2019, Microsoft fece una cosa che non faceva da anni: rilasciò un aggiornamento di sicurezza per Windows XP e Windows Server 2003, sistemi fuori supporto da tempo.

La ragione era BlueKeep, identificata come CVE-2019-0708.
Si tratta di una vulnerabilità che permetteva di eseguire codice su una macchina Windows senza possedere alcuna credenziale, semplicemente raggiungendola in rete.

Poi non successe niente.
Il fatto che non sia successo niente è il motivo per cui, sette anni dopo, quelle macchine sono ancora accese e ancora vulnerabili.

1. Che cos’è BlueKeep
2. Quali sistemi sono colpiti
3. Come funziona, senza scendere nell’operativo
4. Perché fu definita wormable
5. La catastrofe che non è arrivata
6. Perché conta ancora oggi
7. Come si verifica se vi riguarda

Che cos’è BlueKeep

BlueKeep è il nome con cui è diventata nota la vulnerabilità catalogata come CVE-2019-0708, presente nei Servizi Desktop remoto di Windows.
Il punteggio di severity assegnato fu 9,8 su 10 secondo il Common Vulnerability Scoring System. Quel numero non era gonfiato: tre caratteristiche lo giustificavano insieme.

• La prima è che consente l’esecuzione di codice remoto, cioè permette a chi la sfrutta di far girare istruzioni proprie sulla macchina colpita, con i privilegi del servizio.
• La seconda è che non richiede autenticazione. Il difetto sta in una fase del dialogo che avviene prima che il sistema chieda chi siete.
• La terza è che non richiede alcuna azione dell’utente. Nessun clic, nessun allegato, nessuna distrazione.

Messe insieme, queste tre condizioni descrivono la classe di problemi più temuta: una macchina raggiungibile in rete può essere compromessa da chi la raggiunge. Punto. È lo stesso profilo che rende certi exploit immediatamente utilizzabili su scala industriale.

Quali sistemi sono colpiti

Qui va fatta una precisazione importante, perché la lista circola spesso incompleta.

Sono vulnerabili Windows 7, Windows Server 2008 e Server 2008 R2, Windows Vista, Windows XP, Windows Server 2003 e Windows 2000.
Non sono vulnerabili Windows 8, Windows 10, Windows 11 e le versioni server successive, perché il componente interessato è stato riscritto.

La presenza di Windows 7 nell’elenco è la parte che conta di più e viene omessa con una certa frequenza.
Nel 2019 quel sistema era ancora installato su una quota enorme di postazioni aziendali ed è tuttora presente in ambienti dove una macchina pilota un macchinario, un banco di collaudo o un gestionale che nessuno ha mai migrato. Sono le stesse macchine di cui parliamo quando affrontiamo il tema degli aggiornamenti rimandati.

Microsoft rilasciò la correzione il 14 maggio 2019 e fece uno strappo alla propria politica, distribuendola anche per XP e Server 2003 che erano fuori supporto.
È una decisione che l’azienda prende solo quando ritiene il rischio sistemico e serve a misurare quanto fosse considerata seria la situazione.

Come funziona, senza scendere nell’operativo

Il protocollo di desktop remoto organizza la comunicazione in canali virtuali, ciascuno dedicato a un tipo di traffico: la grafica, la tastiera, gli appunti, le stampanti condivise. È una struttura che abbiamo descritto nell’articolo dedicato ai rischi del Remote Desktop Protocol.

Fra questi ne esiste uno interno, previsto dall’implementazione ma non destinato all’uso da parte del client. In condizioni normali nessuno ci si collega.

Il difetto sta nel fatto che il server, in una circostanza particolare, associa quel canale in modo non previsto.
Da lì si apre un problema di gestione della memoria: una porzione di memoria dinamica viene liberata ma continua a essere referenziata e quella referenza rimasta attiva permette di scrivere dove non si dovrebbe.

È la famiglia di difetti che va sotto il nome di uso dopo il rilascio, imparentata con i problemi di corruzione dell’heap e con la più nota categoria del buffer overflow.

Ci fermiamo a questo livello di dettaglio.
Quello che conta per un’azienda non è la meccanica interna, ma la conseguenza: chi raggiunge la porta del desktop remoto su una macchina non aggiornata può arrivare a eseguire codice su quella macchina senza sapere nulla di chi ci lavora.

Perché fu definita wormable

Il termine che accompagnò BlueKeep in tutti i comunicati di quel periodo fu wormable, cioè adatta a essere sfruttata da un worm.

La logica è lineare.
Un worm è un programma che si propaga da solo, senza bisogno che nessuno apra nulla. Per riuscirci gli serve una vulnerabilità che non richieda autenticazione e non richieda interazione, esattamente le due condizioni che BlueKeep soddisfaceva.

Il precedente che tutti avevano in mente era WannaCry, che nel 2017 si era diffuso in tutto il mondo in poche ore sfruttando un difetto con lo stesso profilo in un altro protocollo Windows.
L’analogia era plausibile e la paura fondata: con oltre un milione di macchine raggiungibili da internet sulla porta del desktop remoto, un worm avrebbe avuto materiale a sufficienza.

Il paragone con WannaCry ha però un limite, e va precisato perché in molti articoli resta implicito.
WannaCry si è propagato davvero. BlueKeep no.

La catastrofe che non è arrivata

Fra maggio e ottobre del 2019 il settore rimase in attesa.
Comparvero dimostrazioni di fattibilità, aumentarono in modo vistoso le scansioni alla ricerca di sistemi vulnerabili, diversi enti nazionali di sicurezza emisero avvisi.
Ma l’epidemia non partì.

Il primo sfruttamento osservato su larga scala arrivò a novembre e non fu un worm.
Fu una campagna che installava software di estrazione di criptovaluta sulle macchine raggiunte, per giunta con risultati mediocri: in molti casi il tentativo mandava in blocco il sistema invece di riuscire.

Le ragioni tecniche sono note agli addetti ai lavori.
Sfruttare in modo affidabile un difetto di gestione della memoria richiede di conoscere con precisione la disposizione della memoria sul sistema bersaglio, che varia da versione a versione e da configurazione a configurazione. Fra il funzionare in laboratorio e il funzionare su decine di migliaia di macchine diverse c’è una distanza che in questo caso non è stata colmata.

È una distinzione che vale la pena tenere a mente ogni volta che esce una vulnerabilità con un punteggio alto: la gravità dice quanto sarebbe brutto, non quanto è probabile.

Perché conta ancora oggi

Qui arriva il punto che rende questa storia utile a un’azienda nel 2026, e non è tecnico.

Quando una minaccia annunciata non si materializza, l’attenzione che aveva prodotto si dissolve.
Le macchine che nel giugno 2019 erano nella lista degli interventi urgenti, a dicembre non lo erano più. Nessuno le ha aggiornate e nessuno ha più pensato di doverlo fare.

Quelle macchine però sono ancora lì.
Non le trovate nei data center. Le trovate accanto a un macchinario, in un laboratorio, in un ufficio periferico, collegate a un software che il fornitore non ha mai portato su un sistema più recente. Sono il tipo di apparato che nessuno rivendica e che nessuno rivede, lo stesso fenomeno descritto parlando delle vulnerabilità dei dispositivi IoT aziendali.

E c’è una seconda ragione, più concreta.
Il vettore che BlueKeep ha reso famoso, cioè il desktop remoto raggiungibile dall’esterno, non è mai stato abbandonato. È tuttora una delle vie d’ingresso principali degli attacchi ransomware, non attraverso quella vulnerabilità ma attraverso credenziali valide ottenute altrove.
Il difetto è stato corretto. L’esposizione no.

Come si verifica se vi riguarda

Le domande sono poche e nessuna richiede strumenti particolari.

La prima riguarda l’inventario.
Esiste in azienda una macchina con Windows 7 o Windows Server 2008 ancora accesa, e qualcuno lo sa? Nella maggior parte dei casi la risposta si trova solo guardando, non consultando la documentazione, per la ragione descritta parlando di inventario degli asset: si conosce quello che si è censito, non quello che c’è.

La seconda riguarda l’esposizione.
La porta 3389 del desktop remoto è raggiungibile dall’esterno su qualcuno dei vostri indirizzi pubblici? È una verifica che si conduce da fuori, con l’approccio descritto nell’articolo sul port scanning, e dà una risposta diversa da quella che vi darebbe la documentazione interna.

La terza riguarda le contromisure quando l’aggiornamento non è possibile.
Su una macchina che non può essere toccata perché pilota un impianto la strada è duplice: attivare l’autenticazione a livello di rete, che sposta la richiesta di credenziali prima del punto vulnerabile, e soprattutto togliere quella macchina dal perimetro raggiungibile, confinandola in un segmento separato e rendendola accessibile solo attraverso un canale di accesso controllato con secondo fattore di autenticazione.

La quarta è la più larga e vale oltre BlueKeep.
Quante altre vulnerabilità pubblicate negli ultimi anni sono ancora aperte nella vostra infrastruttura, per lo stesso motivo per cui lo è questa? Sono quasi sempre problemi noti da tempo, con una correzione disponibile, su sistemi che nessuno ha guardato. Non falle inedite, ma configurazioni e versioni rimaste indietro.