Hacking o disaster recovery?

Questa settimana è stata divulgata una vulnerabilità — YellowKey — che permette di bypassare BitLocker usando una chiavetta USB e l’ambiente di recovery di Windows. Se ne parla ovunque, e a ragione: dai forum di infosec alla carta di giornale usata per confezionare le uova.

Quindi non ti tedio con le mie elucubrazioni a riguardo. È già stato detto tutto, e meglio di quanto potrei fare io.

Voglio però andare oltre e registrare una piccola provocazione, che spero porti a una riflessione.

Cosa risponderesti se un tecnico IT venisse da te e ti chiedesse:

“Il CEO non riesce a entrare nel PC. Gli chiede la chiave BitLocker ma non la trovo da nessuna parte. Proviamo YellowKey e vediamo se riusciamo ad accedere?”

Probabilmente gli diresti di fermarsi.

L’idea è disturbante: usare una vulnerabilità per recuperare dati aziendali. Dati propri, legittimi, rimasti bloccati dentro un meccanismo di protezione.

Se una vulnerabilità arriva a sembrare una strada praticabile per il disaster recovery, vale la pena guardare a ciò che è successo prima.

Il recovery ufficiale potrebbe non esistere, non essere stato governato, non essere stato verificato, oppure essersi perso dentro uno stato intermedio che nessuno stava monitorando davvero.

Negli ultimi anni abbiamo delegato sempre più fiducia a meccanismi automatici: TPM, Secure Boot, BitLocker OEM, cloud escrow, provisioning invisibile.

Sono strumenti sensati, spesso necessari, ma richiedono una governance altrettanto solida.

Il punto debole, spesso, sta nelle transizioni tra uno stato e l’altro.

Un disco può risultare cifrato prima che esista davvero una recovery key governata. Un protector TPM può diventare incoerente dopo un aggiornamento firmware. Uno script può non trovare una chiave esplicita e concludere che BitLocker non sia attivo, mentre il volume è già completamente cifrato.

Finché tutto funziona, il problema resta invisibile.

Il computer parte, l’utente lavora, la console non segnala nulla, il monitoraggio resta verde.

Poi arriva l’evento che rompe l’equilibrio: un aggiornamento BIOS, un cambio nella catena di boot, un TPM che non riconosce più lo stato precedente, una schermata blu che chiede una recovery key.

A quel punto la domanda cambia: esiste un modo verificato per recuperare quel disco?

E se in quel momento qualcuno arriva a proporre un exploit come ultima opzione tecnica, dobbiamo analizzare tutto quello che è successo prima.

Una vulnerabilità non dovrebbe mai diventare il piano B.

È esattamente il tipo di lacuna che la NIS2 mette a fuoco. Non chiede di avere strumenti perfetti. Chiede di sapere cosa succede quando quegli strumenti cambiano stato, falliscono, o si comportano in un modo che nessuno aveva previsto.

Perché la NIS2, in fondo, mette in pratica il buon senso e un piano di continuità che non copre gli stati che nessuno ha deciso è un piano scritto solo per il mondo ideale.

Il mondo reale è fatto anche di automazioni che agiscono prima di te, configurazioni ereditate, transizioni invisibili tra uno stato e l’altro.

Prendiamo un esempio concreto.

Compri venti PC nuovi. Li consegni agli utenti. Li metti in dominio. Tutto normale, tutto come sempre.

Quello che non sai — e che nessuno ti ha detto — è che quei PC sono già cifrati.

Non “si cifreranno”.

Non “è consigliabile cifrarli”.

Sono già cifrati, dal momento in cui l’utente ha completato la configurazione iniziale, prima ancora che tu li prenda davvero in carico.

Quindi ecco tre domande semplici.

Chi ha deciso di cifrarli?

Nessuno. È successo in automatico.

Chi ha la chiave?

Dipende.

E “dipende”, in un documento di governance, non è una risposta.

Chi se ne doveva accorgere?

Questa è la domanda più interessante. Perché la risposta onesta, nella maggior parte delle organizzazioni, è: nessuno ci aveva pensato.

Non per negligenza.

Per un motivo più sottile: il sistema non ha mai segnalato che c’era qualcosa a cui pensare.

Nessun alert. Nessun log. Nessuna anomalia.

Il monitoraggio era verde perché il monitoraggio controlla quello che conosce. E questo era uno stato che nessuno aveva previsto, quindi nessuno stava cercando.

La governance è sapere cosa succede non solo quando tutto funziona o quando tutto è chiaramente rotto — ma soprattutto nei momenti di mezzo, quando qualcosa si perde senza che nessuno se ne accorga.

Fidiamoci pure dei meccanismi automatici. Ma ricordiamoci sempre che la fiducia è una forma di delega.

E per delegare, dobbiamo avere chiaro cosa stiamo passando di mano.

Ci sono stati che i nostri controlli non rilevano?

Ci sono processi che danno per scontato un ecosistema cloud-first che i nostri flussi interrompono senza validarne lo stato?

Se la risposta è “non lo so” — e spesso lo è, onestamente — allora non stiamo delegando.

Stiamo sperando.

Un paradosso, non una procedura

Spero sia chiaro: nessuno dovrebbe davvero avere YellowKey nel proprio sysadmin toolset.

Stiamo piegando la realtà per costruire un paradosso, non una procedura.

Stiamo osservando cosa succede quando la strategia di sicurezza non è abbastanza solida da rendere impensabile una possibilità che non dovrebbe nemmeno entrare nella discussione.

Il paradosso, però, funziona perché assomiglia a qualcosa che nel mondo reale succede già.

Quando un’azienda viene colpita da ransomware e decide di pagare un riscatto senza alcuna certezza di ripristino, non lo fa a cuor leggero.

Di solito ha in mente una cosa sola: sopravvivere.

Non pretendo di sapere cosa significhi trovarsi davvero in quella stanza, con l’azienda ferma, il tempo che scorre e decisioni imperfette da prendere comunque.

Proprio per questo non mi interessa fare la morale a chi paga.

Pagare un riscatto alimenta il mercato del ricatto, e nel migliore dei mondi possibili nessuno dovrebbe trovarsi a considerarlo. Ma il punto qui non è giudicare la scelta fatta nel momento peggiore.

La domanda, semmai, riguarda il prima: cosa deve esistere in tempi normali perché, nel momento peggiore, non resti visibile una sola strada?

Come possiamo evitare che una possibilità che non dovrebbe nemmeno entrare nella discussione diventi l’unica speranza rimasta, per quanto malriposta?

Il momento giusto per fare l’audit

Torniamo allora al tecnico IT di prima.

Quello che propone YellowKey per recuperare il disco del CEO.

In un certo scenario, quell’uomo diventa l’eroe della giornata. L’impiegato del mese. Quello che ha salvato la situazione quando sembrava impossibile. Magari gli mettono anche la foto sul muro.

Lasciagliela mettere.

Ma mentre tutti la guardano, usa quel tempo per fare l’audit che avresti dovuto fare prima.

Verifica quanti dischi sono in quello stato. Quante chiavi non esistono. Quanti processi davano per scontato un ecosistema che non c’era.

Fai in modo che quella storia diventi un aneddoto da raccontare.

Non una pratica di disaster recovery.

Quindi cosa puoi fare?

Se hai la coscienza a posto, torna pure a quello che stavi facendo.

Oppure apri la console, cerca i dispositivi con BitLocker attivo, e verifica se per ognuno esiste una recovery key recuperabile da un sistema sotto il tuo controllo.

Non presumere.

Non pensare “dovrebbe esserci”.

Verificala.

Se non sai da dove partire, qui trovi qualche spunto

Oppure, se gestisci un parco macchine e non hai mai fatto questo controllo in modo sistematico, contattami.

Per capire insieme dove sei.

Perché l’audit fatto oggi è un’ora di lavoro.

L’audit fatto dopo la chiamata dell’utente è un problema senza soluzione.