Quali sono le potenziali conseguenze dell'attacco "Golden Key" di Windows 10 agli utenti finali, in termini semplici?

8

Oggi, i media di tecnologia stanno discutendo la scoperta di un backdoor integrata nascosta all'interno della funzionalità SecureBoot dei sistemi operativi mobili Windows 10. Sembra che, da una lettura superficiale della natura della vulnerabilità, tale sfruttamento richieda l'accesso fisico. Vale a dire, non sembra essere un attacco che può essere eseguito da remoto; un utente malintenzionato dovrebbe effettivamente rubare il dispositivo per utilizzarlo.

Che tipo di utilizzo potrebbe avere questa vulnerabilità per un utente malintenzionato nei confronti degli utenti finali (che tipo di scenari si apre a un utente malintenzionato) e quali (eventuali) misure attenuanti dovrebbero prendere un utente finale?

    
posta Bradley Evans 12.08.2016 - 06:50
fonte

1 risposta

3

SecureBoot fa parte di UEFI e di altri firmware che possono essere utilizzati per verificare le firme sul software che verrà caricato all'avvio. Di solito è un bootloader, ma può anche essere il sistema operativo stesso.

Su alcune implementazioni l'utente può "masterizzare" un certificato personalizzato per il firmware da utilizzare per la convalida. In altri casi i certificati sono precaricati dal produttore e solo il software da loro firmato può essere utilizzato sul dispositivo.

I dispositivi incorporati come telefoni e tablet di solito rientrano nella seconda categoria, in cui l'utente non può modificare il software installato se non nei casi consentiti dal produttore (ad esempio, un aggiornamento del sistema operativo).

Rompendo questo blocco, gli utenti possono installare qualsiasi cosa vogliano. Questo è solitamente chiamato "jailbreak" del dispositivo.

Il problema con il jailbreaking è che consente anche ai cattivi attori di compromettere il dispositivo a un livello basso, il che rende le minacce più persistenti e difficili da rilevare.

Diversi dispositivi hanno avuto diversi metodi per il jailbreak nel corso degli anni. In questo caso è stato un problema da parte di Microsoft a permetterlo. Da alla scrittura originale (forse NSFW) :

[secure boot policy is] a file in a binary format that's embedded within an ASN.1 blob, that is signed. It's loaded by bootmgr REALLY early into the windows boot process. It must be signed by a certificate in db. It gets loaded from a UEFI variable in the secureboot namespace (therefore, it can only be touched by boot services). There's a couple .efis signed by MS that can provision such a policy, that is, set the UEFI variable with its contents being the policy.

Questo è uno schema molto intelligente ed estensibile che è stato interrotto da un trascuratezza durante lo sviluppo:

During the development of Windows 10 v1607 'Redstone', MS added a new type of secure boot policy. Namely, "supplemental" policies that are located in the EFIESP partition (rather than in a UEFI variable), and have their settings merged in, dependant on conditions (namely, that a certain "activation" policy is also in existance, and has been loaded in). [...] The "supplemental" policy contains new elements, for the merging conditions. These conditions are (well, at one time) unchecked by bootmgr when loading a legacy policy. And bootmgr of win10 v1511 and earlier certainly doesn't know about them. To those bootmgrs, it has just loaded in a perfectly valid, signed policy.

In altre parole, hanno un criterio firmato che consente loro di caricare i file binari non firmati, presumibilmente per consentire di testare le versioni di sviluppo senza dover firmare ciascuna.

Hanno spedito accidentalmente questa norma in alcuni dispositivi, qualcuno l'ha scoperta e pubblicata, e ora può essere caricata su qualsiasi dispositivo.

L'articolo contiene molti più dettagli su come funziona. Il punto è che questo è un exploit di jailbreak. Per alcuni è una buona notizia, per gli altri non così tanto.

Lo sfruttamento efficace richiede diritti di amministratore o accesso fisico.

@Bradley ha menzionato nei commenti che "Rende più facile per il malware che è già sul tuo PC prendere il controllo dell'avanzamento e superare completamente il tuo pc". Se è vero, significa che il malware ha già i diritti di amministratore sul dispositivo, quindi il compromesso di avvio è l'ultimo dei tuoi problemi.

Microsoft ha dichiarato:

The jailbreak technique described in the researchers’ report on August 10 does not apply to desktop or enterprise PC systems. It requires physical access and administrator rights to ARM and RT devices and does not compromise encryption protections.

Ma potrebbe essere stato un eufemismo. Hanno rilasciato due patch: MS16-094 e MS16-100. Il primo indica:

An attacker must have either administrative privileges or physical access to install a policy and bypass Secure Boot.

This security update is rated Important for all supported editions of Windows 8.1, Windows RT 8.1, Windows Server 2012, Windows Server 2012 R2, and Windows 10. [...] The security update addresses the vulnerability by blacklisting affected policies.

Quindi è uno root o accesso fisico, come menzionato prima.

E fa influisce sui desktop e sui server (vedi la discussione dei commenti per la speculazione sul motivo per cui avrebbero potuto dire che non ha funzionato).

Inoltre, la lista nera delle policy è stata giudicata insufficiente: il rollback a un bootmgr precedente poteva ancora consentire il caricamento del criterio (questo è menzionato nel write up). Anche la seconda patch oscura i vecchi boot manager per risolverli.

TL; DR : correggi i tuoi sistemi Windows e non preoccuparti troppo di questo. Ci sono problemi ben peggiori.

    
risposta data 29.08.2016 - 18:33
fonte

Leggi altre domande sui tag