Un utente malintenzionato può compromettere una macchina Windows con UEFI, avvio sicuro e bitlocker?

Dopo aver condotto ricerche approfondite sulla piattaforma Bitlocker, credo di poter rispondere alla mia stessa domanda.

Riferimento chiave: Panoramica tecnica sulla crittografia unità Bitlocker

Nella nostra configurazione predefinita (almeno su MS Surface Pro 3), Bitlocker, UEFI e Secure Boot sono attivi. È abilitato TPM 2.0. UEFI non è protetto da password e l'ordine di avvio consente USB prima di SSD.

Gli hacker hanno interesse ad avviarsi in un SO alternativo perché i popolari strumenti di cracking delle password come Ophcrack vengono eseguiti da Linux (in realtà non funzionerebbe su Surface Pro 3 perché è un dispositivo UEFI di classe 3 che non supporta la modalità Legacy BIOS ). Inoltre, se il disco rigido non è crittografato, il sistema operativo alternativo ha la libertà di leggere i file dal disco rigido e persino di "resettare" la password di Windows facendo confusione con il SAM e il registro di Windows.

Nel nostro scenario, dal momento che la crittografia di Bitlocker è attiva, la partizione del disco rigido viene crittografata, quindi un sistema operativo avviato alternativo non sarà in grado di vedere i nostri file. Inoltre, il TPM eseguirà un controllo di integrità sui componenti di pre-avvio e rendiamo conto che stiamo effettuando il boot in un altro sistema, e quindi non rilasceremo le chiavi necessarie per decifrare la partizione del disco rigido. Inoltre, non si può semplicemente avviare un Live Linux USB, o installare Linux sul disco rigido, poiché Secure Boot non lo consentirebbe. Possiamo semplicemente disattivare Secure Boot, poiché non esiste alcuna protezione con password sulle impostazioni UEFI?

Sì, un utente malintenzionato ha la possibilità di disattivare Secure Boot e avviare in un sistema operativo alternativo. Tuttavia, non è un problema perché il criterio Bitlocker predefinito utilizzerà Secure Boot per la convalida dell'integrità e, disattivando Secure Boot, verrà attivato il blocco della chiave di ripristino Bitlocker. L'utente malintenzionato non dovrebbe avere la chiave di ripristino in suo possesso e la forzatura bruta non è fattibile. Poiché l'utente malintenzionato non può superare la schermata della chiave di ripristino, il disco rigido non verrà decrittografato e i dati rimangono protetti. Un utente intelligente dovrebbe anche percepire che qualcosa è attivo se gli viene richiesta la chiave di ripristino per nessun motivo legittimo come un aggiornamento del sistema (nel caso in cui temiamo attacchi di Maom diabolici).

NelleimpostazioniUEFI,l'utentemalintenzionatopotrebbeanchedisattivarelaprotezioneTPM.CiòinnescheràsicuramenteilbloccodellachiavediripristinodiBitlockerperchéBitlockersiaffidaaTPMperlesuesolitechiavididecodifica.Pertanto,èinutilefarlo.

Pertanto,mentreèpossibilerendereilsistema"più sicuro" proteggendo la UEFI con password, non sembra necessario farlo.

Inoltre, Surface Pro 3 è certificato come dispositivo "Connected Standby". In altre parole, non dobbiamo andare all'estremo di spegnere sempre il dispositivo o metterlo in ibernazione per maggiore sicurezza in alcune configurazioni. Non abbiamo davvero bisogno di avere anche un'autenticazione pre-boot (vale a dire solo l'autenticazione TPM). Non ha alcuna porta DMA, quindi l'attacco DMA non è possibile. Non è suscettibile agli attacchi Cold Boot, dal momento che la memoria di sistema non può essere facilmente rimossa. Consulta questo articolo di riferimento .

Nel suo discorso su " Costruire un Bitlocker antiproiettile ", Sami Laiho afferma che l'autenticazione solo TPM è sufficiente per il 90% delle persone. Se sei interessato, parla di Bitlocker e ha aggiunto configurazioni che potresti configurare (per dispositivi generali, non solo per Surface Pro).

Letture aggiuntive: Commenti su Bitlocker

Nota: potrebbero esserci backdoor e errori di implementazione sconosciuti. La risposta qui è basata sulle informazioni disponibili di Microsoft e sulla conoscenza generale dei sistemi FDE. Presuppone inoltre che il TPM possa essere considerato affidabile e che la forzatura bruta della crittografia stessa sia "impossibile" senza un supercomputer molto veloce (ad esempio, impiegheranno "troppe" vite per interrompere al momento attuale). Detto questo, sentitevi liberi di evidenziare ulteriori vulnerabilità in modo che possiamo essere più consapevoli delle potenziali minacce e in quali circostanze dovremmo essere preoccupati per loro (cioè ipotesi sull'attaccante). Vorrei solo commentare che una vulnerabilità in una parte del sistema non implica immediatamente che un utente malintenzionato possa progettare un attacco riuscito per estrarre informazioni da esso, anche se effettivamente aumenta le possibilità di successo.

L'accesso fisico è sempre una cosa molto rischiosa. Anche se ora non ho alcun difetto di sicurezza che ti darà accesso immediato ci sono molte altre cose che puoi fare, ad es. utilizzando un keylogger USB per intercettare la password dell'utente quando usa la macchina la volta successiva. Ci sono stati attacchi usando le schede PCI che utilizzano l'accesso diretto alla memoria ( link ). Le liste continuano.

Esiste un'intera letteratura nelle comunità Blackhat e Defcon che mostra come sfruttare il software che gestisce i TPM, recuperare le chiavi segrete dal TPM interponendo sulla comunicazione tra il TPM e la CPU e altri attacchi. La risposta di cui sopra di Kevinze e dei suoi commenti di follow-up semplicemente non è accurata (sostiene che tali exploit sono solo teorici). La sezione 5 di questo documento fornisce un breve riepilogo di alcuni metodi conosciuti per sfruttare il TPM: link