Come può il malware del firmware HDD di Equation Group aiutare a bypassare FDE?

2

Al momento ci sono molte discussioni in corso su Internet sulla famiglia di "Equation Group" di firmware di unità disco rigido malevolo.

Una cosa che mi ha chiesto è l'affermazione secondo cui il firmware di un HDD malevolo sarebbe in grado di accedere ai dettagli su qualsiasi schema di crittografia su disco completo. Ad esempio, abbiamo Come funziona l'hacking del firmware della NSA e perché è così sconveniente, da cablato che afferma, in parte (facendo riferimento qui alle porzioni inutilizzate della EEPROM del firmware):

“Taking into account the fact that their GrayFish implant is active from the very boot of the system, they have the ability to capture the encryption password and save it into this hidden area,” [Costin Raiu, director of Kaspersky’s Global Research and Analysis Team] says.

Forse mi manca qualcosa di ovvio, ma non capisco come ciò avvenga. Ci sono due casi che posso vedere qui:

  • Microsoft Windows, con Bitlocker abilitato. Il caricatore del firmware è apparentemente un eseguibile di Windows e Windows è un sistema operativo comune, quindi potresti avere un po 'di leva con il codice "pronto all'uso".
  • Qualche altro sistema operativo con FDE, ad esempio Linux con LUKS o FreeBSD con GEOM. Questi sarebbero, per lo meno, immediatamente non influenzati da un binario di Windows.

Quando si utilizza la crittografia a disco intero, il dispositivo di archiviazione (sia HDD, SSD, floppy, o qualsiasi altra cosa) ha il compito di conservare i bit crittografati. Alcune intestazioni sono note per esistere in diversi schemi FDE, spesso contengono materiale chiave e possono presumibilmente essere rilevati in base a numeri magici o posizione su disco, ma le parti carnose vengono crittografate dal momento in cui raggiungono il dispositivo di archiviazione.

In che modo il firmware di un dispositivo di memorizzazione può sovvertire in modo significativo la crittografia completa su disco , in cui il dispositivo di archiviazione visualizza solo i dati crittografati nei comandi READ e WRITE?

L'unica vera possibilità che posso vedere è se il firmware del dispositivo di archiviazione può in qualche modo influenzare altre parti del sistema, forse sfruttando DMA, ma il gestore della memoria della CPU non dovrebbe intervenire lì? Oppure il DMA viene sempre eseguito in modalità supervisore (anello 0 nella terminologia Intel)? Sembrerebbe aprire una lattina di vermi completamente diversa.

Supponiamo qui una tipica configurazione FDE: BIOS o UEFI, che passa a un piccolo bootloader non crittografato che richiede all'utente una password e procede a inizializzare lo stato di cryptosystem prima di resident per intercettare l'I / O del disco e fare la crittografia / decrittografia come i flussi di dati tra il normale livello I / O del sistema operativo e il dispositivo di memorizzazione stesso. Tutti "in un modo o nell'altro", lasciando da parte i dettagli di implementazione tecnica a meno che non riguardino direttamente la risposta alla domanda principale.

    
posta a CVn 23.02.2015 - 20:27
fonte

2 risposte

1

Questo è equivalente a un malvagio attacco da cameriera, che compromette il bootloader (non crittografato) per catturare la tua password FDE al prossimo avvio del computer.

Ciò presuppone che il bootloader sia mantenuto sulla stessa unità. Se questo non è il caso (ad esempio se si mantiene il bootloader su un'unità rimovibile) e si configura esplicitamente il computer per non di avvio dal disco rigido principale (in modo da non eseguire codice potenzialmente malevolo impiantato su di esso ) quindi questo attacco non funzionerà.

Per impostazione predefinita, con LUKS e Bitlocker, una piccola parte dell'unità non viene crittografata e il bootloader che riconosce FDE è presente e viene eseguito ad ogni avvio; quindi l'unità fa più di conservare i bit crittografati . Un TPM può aiutare a mitigarlo verificando l'integrità (hash) del bootloader prima di distribuire le chiavi e Bitlocker ne approfitta per impostazione predefinita. Per LUKS, non esiste un supporto ufficiale per TPM ma esistono alcune soluzioni come TrustedGRUB (per l'estensione effettiva della catena di trust) e tpm-luks per il salvataggio e il recupero della chiave LUKS dal TPM.

    
risposta data 26.03.2015 - 18:12
fonte
0

Immagino che il firmware venga aggiornato per presentare uno dei blocchi "di riserva" sul piatto al MOBO per l'avvio (dopo aver prima scritto un rootkit in quel settore nascosto) e poi per caricare a catena quello che dovrebbe essere il " vero "settore del settore di avvio" (cioè quello contenente il proprio caricatore di avvio del disco crittografato) dopo che il rootkit è in memoria.

Leggi qui sul bootkit lapidato: link Se un utente malintenzionato compromette il sistema operativo e può installare gli hack del firmware che lo fanno, l'attacco è una questione semplice. In realtà tutti gli aggiornamenti del firmware sono persistenza.

Non sono sicuro di come questo potrebbe funzionare con situazioni di bootstrap più moderne come UEFI, ma poi di nuovo sospetto che il tempo degli attacchi NSA sia anteriore all'adozione su larga scala (vale a dire di Windows 8).

Sarebbe bello se i responsabili della sicurezza potessero accedere a una di queste unità e vedere se, ad esempio, caricare il caricatore di avvio della crittografia del disco su un USB o CDROM lo evitasse.

Un'altra cosa che posso pensare è che il firmware collochi un bootkit che non faccia altro che scansionare il buffer della tastiera per le punture di certa lunghezza seguite da un ritorno a capo e quindi archiviarle nelle tracce di manutenzione del disco. O forse sta semplicemente seduto lì a scannerizzare la memoria finché non trova alcune chiavi AES e le scrive in memoria.

Il punto è che è un modo persistente di possedere un sistema e una volta che ciò accade (ring zero access baby), tutte le scommesse sono disattivate e una serie abbastanza ampia di attacchi è possibile.

    
risposta data 24.02.2015 - 00:10
fonte

Leggi altre domande sui tag