Red Hot Cyber
Sicurezza Informatica, Notizie su Cybercrime, Analisi Vulnerabilità e Intelligenza Artificiale
L'articolo analizza le implicazioni della cifratura BitLocker sui volumi quando il computer viene spento o il disco viene rimosso. Evidenzia la differenza tra lo stato "Unlocked" e la semplice presenza di dati cifrati, sottolineando l'importanza di verificare la disponibilità di chiavi di recupero prima di intervenire. Vengono discusse le scelte operative tra live acquisition e acquisizione offline, i rischi di modificare il sistema acceso e la necessità di documentare accuratamente lo stato di BitLocker per garantire la possibilità di accesso futuro ai dati.
Un computer acceso può avere il disco completamente cifrato e, nello stesso momento, permetterci di accedere normalmente ai file. Finché il volume è sbloccato, la cifratura quasi non si vede. Il problema può comparire dopo: quando spegniamo il computer, rimuoviamo il disco o modifichiamo le condizioni che permettevano al sistema di accedervi. Per questo, sapere che BitLocker è attivo non basta. Prima di cambiare lo stato della macchina dobbiamo capire se l’accesso che abbiamo davanti sarà ancora disponibile dopo.
E, se non ne siamo sicuri, decidere cosa vale la pena preservare prima di perderlo. Il notebook è acceso. Windows è avviato, l’utente ha effettuato l’accesso e dal disco C: possiamo aprire documenti, cartelle e file senza alcuna richiesta particolare. Controlliamo lo stato di BitLocker. Il volume risulta completamente cifrato. Protection Status: On. Lock Status: Unlocked. Possiamo spegnere il computer, rimuovere l’SSD e acquisirlo con la nostra workstation?
Tecnicamente sì.
Il problema è cosa succederà dopo. L’immagine forense potrà essere perfettamente acquisita e verificata, ma continuerà a rappresentare un volume cifrato. Se non disponiamo di un metodo per sbloccarlo, potremmo aver conservato integralmente il supporto e perso, nel frattempo, una condizione di accesso che avevamo davanti agli occhi pochi minuti prima.
BitLocker separa diversi stati che durante una first response è facile condensare nella frase “il disco è cifrato”. Non basta. manage-bde -status, per esempio, distingue lo stato di cifratura, quello della protezione, il Lock Status e i Key Protectors configurati sul volume. Ed è perfettamente possibile leggere insieme:
Percentage Encrypted: 100%
Protection Status: Protection On
Lock Status: Unlocked
Non c'è contraddizione.
I dati sul supporto sono cifrati, ma Windows dispone in quel momento delle condizioni necessarie per renderli accessibili. È questa seconda informazione che interessa particolarmente durante l’intervento. Perché “100% encrypted” descrive il disco. “Unlocked” descrive anche lo stato nel quale lo abbiamo trovato. Se quel computer viene spento, non abbiamo ancora dimostrato che potremo ricreare lo stesso stato. Magari sì. Il TPM potrebbe consentire nuovamente il normale avvio e lo sblocco del volume.
Oppure potremmo già disporre della recovery password. Ma prima di affidare l’accesso futuro a una di queste possibilità conviene verificarlo. Microsoft documenta diversi eventi che possono portare BitLocker in recovery: modifiche al boot, al firmware o al TPM, variazioni della configurazione e anche lo spostamento di un’unità protetta in un altro computer. Questo non rende pericoloso ogni riavvio. Rende semplicemente poco prudente trattare come equivalenti due stati che equivalenti non sono.
La domanda sembra semplice, ma anche qui serve qualche attenzione. Possiamo trovare un Numerical Password protector configurato sul volume senza avere materialmente a disposizione la relativa recovery password. Possiamo sapere che una chiave dovrebbe essere stata salvata in Active Directory o Microsoft Entra ID senza averla ancora recuperata. Possiamo ricevere dall’utente una recovery password e non aver ancora verificato che corrisponda proprio a quel volume.
Sono condizioni molto diverse da: “Abbiamo una chiave, l’abbiamo verificata e sappiamo di poter riaprire questa acquisizione.” Immaginiamo quindi due computer apparentemente identici. Sul primo troviamo BitLocker attivo, volume sbloccato e recovery password già disponibile. La verifichiamo e sappiamo di poter accedere successivamente al contenuto. Sul secondo troviamo lo stesso stato del volume, ma nessuna recovery password disponibile e nessuna certezza su dove recuperarla.
Il comando restituisce quasi le stesse informazioni. La decisione operativa può essere diversa. È uno di quei casi in cui il risultato di uno strumento non contiene ancora la risposta. Ci dice com’è configurato il sistema; sta all’esaminatore capire quale rischio produce quella configurazione nel caso concreto.
Se non siamo ragionevolmente sicuri di poter ricostruire l’accesso, mantenere per qualche tempo lo stato corrente può avere valore. Non necessariamente per copiare subito tutto. Potremmo prima documentare lo stato di BitLocker e i protector presenti. Verificare se esiste una recovery key accessibile nell’ambito dell’attività. Valutare l’acquisizione della memoria. Oppure, quando il caso lo richiede, acquisire attraverso il sistema live dati che sono in quel momento disponibili in forma leggibile.
SWGDE richiama esplicitamente il problema: in un sistema cifrato la live acquisition può rappresentare l’unica opportunità per ottenere determinati dati e l’acquisizione della memoria può assumere particolare rilevanza. “Può” è importante. Acquisire la RAM non garantisce che troveremo materiale crittografico utilizzabile. Una live acquisition non garantisce automaticamente un risultato migliore. Dipende dalla configurazione, dagli strumenti, dal tipo di acquisizione e da ciò che stiamo cercando di preservare. Inoltre, lavorare sul sistema acceso costa qualcosa.
Il software che avviamo occupa memoria. I comandi producono attività. Il collegamento di dispositivi e l’esecuzione degli strumenti possono modificare file, log, timestamp o altri elementi. In alcuni casi possiamo introdurre instabilità proprio sul sistema che stiamo cercando di preservare. È lo stesso problema incontrato parlando di live acquisition: preservare qualcosa che rischia di scomparire può richiedere di accettare una modificazione controllata del sistema.
Con BitLocker, però, quel compromesso diventa molto concreto. Da una parte abbiamo il footprint dell’intervento. Dall’altra potremmo avere una condizione di accesso che, una volta persa, non sappiamo ancora se riusciremo a ricostruire.
Supponiamo di scegliere comunque lo spegnimento. Acquisiamo offline l’SSD da 512 GB con write blocker, calcoliamo gli hash e documentiamo correttamente ogni passaggio. Dal punto di vista dell’acquisizione non c’è necessariamente alcun errore. Poi proviamo ad analizzare l’immagine. Il volume è BitLocker. Non abbiamo la recovery password. Il normale meccanismo di sblocco che funzionava sul computer acceso non è disponibile nella nostra workstation.
Il dato non è scomparso. È lì, nella nostra acquisizione. Ma la possibilità di interpretarlo è cambiata. Questo esempio mostra bene perché integrità e accessibilità non siano la stessa cosa. Possiamo preservare perfettamente i bit presenti sul supporto senza preservare automaticamente tutte le condizioni necessarie per utilizzarli. Naturalmente esiste anche il caso opposto.
Possiamo mantenere acceso il computer, eseguire numerose attività live, acquisire memoria, esportare file e introdurre modificazioni significative quando, in realtà, una recovery key era già disponibile e verificabile. Avremmo preservato un rischio che non esisteva realmente, pagando però il costo dell’intervento sul sistema. È per questo che BitLocker non dovrebbe produrre una reazione automatica. Dovrebbe produrre una verifica.
Nel verbale o nella documentazione tecnica, “presenza di BitLocker” è un’informazione utile ma incompleta. Serve sapere in quale stato si trovava il volume quando lo abbiamo osservato. Se era sbloccato. Quali protector risultavano configurati. Se disponevamo già di una modalità di recovery utilizzabile. Se quella modalità è stata effettivamente verificata oppure soltanto ipotizzata.
E poi viene la parte più importante: cosa abbiamo deciso di fare con quelle informazioni. Possiamo aver scelto di spegnere perché l’accesso futuro era ragionevolmente garantito. Possiamo aver acquisito prima la memoria perché quel presupposto mancava e lo stato corrente offriva un’opportunità che rischiava di essere irripetibile. Possiamo aver evitato ulteriori attività live perché il loro footprint non era giustificato dalle circostanze.
Sono decisioni diverse, tutte potenzialmente corrette. Quello che cambia è la capacità di ricostruire il passaggio tra ciò che abbiamo osservato e ciò che abbiamo fatto. Quando un volume cifrato è già aperto davanti a noi, quindi, la prima evidenza da preservare non è necessariamente un file o una chiave. Può essere la consapevolezza che quell’accesso esiste adesso e che la nostra prossima azione potrebbe cambiarlo. Da lì viene il resto: verificare, scegliere e documentare.
[1] Microsoft, manage-bde status, Microsoft Learn.
https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/manage-bde-status
[2] Microsoft, BitLocker recovery overview, Microsoft Learn.
https://learn.microsoft.com/en-us/windows/security/operating-system-security/data-protection/bitlocker/recovery-overview
[3] Scientific Working Group on Digital Evidence (SWGDE), Best Practices for Computer Forensic Acquisition, SWGDE 17-F-002-2.1, sezione 7.3 Live Acquisition.
https://www.swgde.org/documents/published-complete-listing/17-f-002-2-1/
RHC4Edu nasce dalla volontà della community di Red Hot Cyber di portare la cultura della cybersecurity, dell’intelligenza artificiale e del digitale direttamente nelle scuole, mettendo gratuitamente a disposizione degli studenti l’esperienza di professionisti, ricercatori e specialisti del settore. Il progetto è ufficialmente operativo e permette agli istituti interessati di richiedere workshop gratuiti e incontri con gli esperti della community, attraverso un coordinamento della redazione che mette in relazione le esigenze della scuola con le competenze e la disponibilità dei professionisti presenti sul territorio.
L’obiettivo di RHC4Edu non è trasformare gli studenti in tecnici informatici, ma aiutarli a sviluppare consapevolezza e pensiero critico davanti a un mondo sempre più digitale. Cybersecurity, truffe online, privacy, social network, cyberbullismo, fake news e intelligenza artificiale diventano così argomenti da affrontare con esempi concreti e con il contributo diretto di chi lavora quotidianamente nel settore. Un’iniziativa costruita sulla condivisione della conoscenza e sul volontariato della community, perché portare queste competenze nelle aule significa anche offrire ai ragazzi la possibilità di conoscere nuove professioni, sviluppare curiosità e imparare a vivere la tecnologia in modo più sicuro e consapevole.
Prenota il tuo workshop gratuito con gli esperti di Red Hot Cyber.