Una recente fuga di notizie di una "chiave d'oro" da parte di Microsoft, abbinata alla presenza di una modalità di debug, ha consentito di disabilitare l'avvio sicuro sui dispositivi Windows. Continuare a leggere!
I sistemi operativi basati su Windows non sono più la scelta predefinita e principale nella scena mobile. La natura Open Source di Android ha trovato molti sostenitori negli OEM e, di conseguenza, oggigiorno sempre meno telefoni utilizzano Windows.
Ma se sei tra coloro che continuano ancora a utilizzare un dispositivo Windows nella vita quotidiana, c'è una novità per te. Bene o male, ciò dipenderà dalla tua posizione e dall'interpretazione dei casi d'uso di questa notizia.
Come riportato da Ars Tecnica E Il registro con la notizia proveniente da a sito web che probabilmente ti farà venire il mal di testa (non sto scherzando), alcuni sviluppatori (@never_released E @TheWack0lian) hanno scoperto che una backdoor inserita da Microsoft a scopo di debug ha aperto la possibilità di disabilitare l'avvio sicuro sui dispositivi Windows.
Avvio sicuro e che cos'è?
Quando si avvia per la prima volta un dispositivo Windows, la procedura di avvio segue questo ordine generale: UEFI (Unified Extensible Firmware Interface, che sostituisce il BIOS) -> Boot Manager -> Boot Loader -> Finestre. UEFI è dove è presente la funzionalità Secure Boot. Come suggerisce il nome con Avvio sicuro, mira a migliorare la sicurezza richiedendo firme digitali sui prossimi passi. In sostanza, se il bootloader non è firmato con le chiavi che UEFI si aspetta, la procedura di avvio del dispositivo non verrà completata.
Secure Boot è una funzionalità opzionale, ma Microsoft ha reso obbligatoria l'attivazione per ottenere la certificazione Windows da Windows 8 e versioni successive. Il ragionamento era che Secure Boot avrebbe reso difficile per gli autori di malware inserire codice nella procedura di avvio. Tuttavia, un effetto collaterale di Secure Boot era che rendeva un po' complicato il dual-boot su macchine Windows o anche il secondo sistema operativo e tutti i suoi prerequisiti devono essere firmati digitalmente, oppure dovrebbe esserlo Secure Boot Disabilitato. Ci sono molti altri problemi a questo proposito, e gli esperti dual booter ne saprebbero più di quanto potrei spiegare in un paragrafo.
Ora, ci sono alcuni dispositivi su cui Secure Boot non può essere disabilitato dall'utente anche se lo desidera. Questo è il regno in cui il nostro argomento viene drasticamente ristretto da tutti i dispositivi Windows (inclusi desktop) a dispositivi Windows specifici come dispositivi Windows Phone, dispositivi Windows RT, alcuni dispositivi Surface e persino HoloLens. Questi dispositivi per gli utenti finali hanno Avvio protetto bloccato, il che significa che un l'utente finale non può modificare o disabilitare aspetti relativi a Secure Boote, per estensione, non possono toccare il sistema operativo in modi non autorizzati da Microsoft per l'utente finale.
Ma ai fini dello sviluppo ufficiale in corso, Secure Boot deve essere leggermente allentato. Sui dispositivi su cui Secure Boot è bloccato, esistono policy di Secure Boot che possono aiutare con lo sviluppo autorizzato senza la necessità di disabilitare Secure Boot. Come menzionato dagli utenti che effettuano ricerche, questo file di criteri di avvio sicuro viene caricato da Boot Manager nelle prime fasi del processo di avvio di Windows. I file delle policy possono anche contenere regole di registro che a loro volta hanno la capacità di contenere, tra le altre cose, configurazioni per la policy stessa. Anche in questo caso, il file delle policy deve essere firmato e sono in vigore altre disposizioni per garantire che solo Microsoft possa fornire queste modifiche.
L'elemento di firma si basa anche su quello che viene chiamato DeviceID, che viene utilizzato durante l'applicazione. Lascerò che sia il post del blog a spiegare qui, poiché ci sono alcune parti che non mi sono così chiare:
Inoltre, esiste una cosa chiamata DeviceID. Sono i primi 64 bit di un hash SHA-256 salato, di alcuni output UEFI PRNG. Viene utilizzato quando si applicano criteri su Windows Phone e Windows RT (mobilestartup lo imposta su Phone e SecureBootDebug.efi quando viene avviato per la prima volta su RT). Sul telefono, la policy deve trovarsi in una posizione specifica sulla partizione EFIESP con il nome file che include la forma esadecimale del DeviceID. (Con Redstone, questo è stato cambiato in UnlockID, che è impostato da bootmgr, ed è solo l'output UEFI PRNG non elaborato).
Fondamentalmente, bootmgr controlla la policy quando viene caricata, se include un DeviceID che non corrisponde al DeviceID del dispositivo su cui è in esecuzione bootmgr, la policy non verrà caricata. Qualsiasi policy che consenta di abilitare la firma di prova (MS chiama queste policy Retail Device Unlock/RDU) e to installarli sta sbloccando un dispositivo), dovrebbe essere bloccato su un DeviceID (UnlockID su Redstone e Sopra). In effetti, ho diverse policy (firmate dal certificato di produzione di Windows Phone) come questa, dove le uniche differenze sono il DeviceID incluso e la firma. Se non è installata alcuna policy valida, bootmgr ricorre all'utilizzo di una policy predefinita ubicata nelle sue risorse. Questa policy è quella che blocca l'abilitazione della firma di test, ecc., utilizzando le regole BCD.
Questa è la parte in cui le cose si fanno interessanti. Durante lo sviluppo di Windows 10 v1607, Microsoft ha creato un nuovo tipo di Secure Boot Policy (d'ora in poi denominata SBP per brevità) per scopi di test interni e debug. La policy è di natura "supplementare" senza DeviceID presente e fa sì che le sue impostazioni vengano unite in una policy di avvio esistente. Il Boot Manager carica i tipi precedenti di SBP, quindi ne verifica la firma e l'autenticità, quindi carica queste policy di avvio supplementari. Il problema qui è che non è prevista alcuna ulteriore verifica sulla polizza integrativa stessa. Inoltre, i Boot Manager precedenti a Windows 10 v1511 non sono a conoscenza dell'esistenza della natura supplementare di queste policy e, quindi, reagire come se caricassero una polizza perfettamente valida e firmata. Ancora una volta, questo comportamento era probabilmente dovuto allo sviluppo interno, quindi gli sviluppatori non avrebbero dovuto firmare ogni singola versione del sistema operativo e ogni piccola modifica che dovevano apportare sul dispositivo.
Questo SBP viene definito "chiave d'oro" poiché sostanzialmente annulla lo scopo del controllo delle firme. Questo SBP è stato involontariamente spedito sui dispositivi di vendita al dettaglio, anche se in stato disattivato. Gli sviluppatori hanno trovato questo SBP e hanno reso note le loro scoperte. Ora, il SBP può esserlo trovato in giro su internet, con questo particolare zip utilizzato per installare SBP sui dispositivi Windows RT.
Cosa significa questo?
Se hai caricato un SBP supplementare, puoi abilitare la firma di prova per Windows per consentire il caricamento di driver non firmati. Inoltre, poiché queste policy entrano in gioco prima della fase Boot Manager nella procedura di avvio, è possibile compromettere la sicurezza dell'intero ordine ed eseguire codice non autorizzato (leggi autofirmato). Ciò apre molte possibilità, sia per gli utenti che intendono modificare parti di Windows oltre l'autorizzazione che per i creatori di malware.
Gli autori di questa constatazione si concentrano sull'ironia dell'intero fiasco. Microsoft ha bloccato l'avvio sicuro su determinati dispositivi per tenere lontane le modifiche non autorizzate, ma poi ha creato una backdoor per consentire loro di continuare con lo sviluppo e il debug. Ma proprio questa backdoor apre la strada alla disabilitazione di Secure Boot su tutti i dispositivi che eseguono Windows, rendendo l’intera dura prova inutile.
Gli utenti disponibili ora non solo possono installare distribuzioni Linux (e possibilmente Android) su tablet e tablet solo Windows Sui telefoni degli utenti non consenzienti possono anche essere installati bootkit dannosi se compromettono l'accesso fisico ai propri dispositivo. Mentre il primo è qualcosa su cui possiamo saltare in aria, il secondo non infonde molta fiducia. Funziona in entrambe le direzioni e ci mostra perché la sicurezza è un’arma a doppio taglio. Inoltre, l'SBP è di natura universale e ne consente l'utilizzo su qualsiasi dispositivo indipendentemente dall'architettura. Non è particolarmente utile per i casi di desktop in cui Secure Boot può essere disattivato facilmente, ma ha una portata immensa per i dispositivi in cui non è possibile scherzare con Secure Boot.
Allora, qual è la soluzione?
Microsoft ha rilasciato alcune patch, ma gli sviluppatori insistono sul fatto che il problema non è stato completamente risolto. Puoi dare un'occhiata a queste patch (MS16-094 E MS16-100) e poi leggi il file post sul blog si chiede perché non risolvono il problema. Se hanno ragione, questo problema non ha una soluzione o una patch in vista, anche se ciò non impedirà a Microsoft di tentare di posizionare ulteriori ostacoli sulla strada.
E dopo?
C'è un mondo di possibilità e alcune di esse stanno emergendo nei nostri forum Windows. Puoi controllare i nostri forum su Sviluppo e hacking di Windows Phone 8 e i nostri forum per Windows 8, Windows RT e sviluppo e hacking di Surface. Puoi anche trovare thread di istruzioni per alcuni dispositivi, dove altri utenti discutono dello stesso.
La presenza di questa backdoor di debug e la fuga dell'SBP non sono importanti solo per terzi sviluppo di dispositivi Windows bloccati, ci mostrano anche un triste promemoria su cosa può accadere se intenzionale restano le backdoor. La recente attenzione alla sicurezza si è spostata verso le agenzie investigative che premono affinché la presenza di tali backdoor venga utilizzata per facilitare i loro scopi investigativi legali. Ma prima o poi, questi metodi Volere cadere nelle mani sbagliate. Ciò che dovrebbe essere utilizzato come strumento per combattere la criminalità e favorire la giustizia, un giorno diventerebbe lo strumento per il crimine stesso.
Cosa ne pensi della fuga di dati del Debug SBP? Pensi che "Chiavi d'Oro" come queste dovrebbero esistere? Fateci sapere nei commenti qui sotto!