Considerate le rivelazioni dal The Equation Group è stato scoperto. Inoltre, è possibile non garantire rimozione di un rootkit anche con una bomba nucleare ad alta orbita .
Quali proprietà dell'hardware un hard disk possono essere aggiunte per impedire a questi rootkit di assumere il controllo / la sostituzione del firmware?
Una soluzione è richiedere che tutti i firmware siano firmati e che il dispositivo verifichi la firma prima di scrivere quell'immagine del firmware nella sua memoria; il mio laptop attuale ha un'opzione per abilitarlo nel suo BIOS (l'opzione è permanente - se lo abilito ora non posso più disabilitarlo, ecco perché non l'ho abilitato).
Tuttavia ci sono molti svantaggi:
induce un falso senso di sicurezza, in quanto non sappiamo in che modo il produttore protegge la chiave privata utilizzata per la firma e non mi aspetto che ammettano il loro fallimento e invii un bel "Scusa se il codice firmware è trapelato "email a ciascun cliente; anche se la chiave non ha perso, l'NSA e altre agenzie malvagie potrebbero averlo rubato e nessuno lo saprebbe.
rendere impossibile il firmware personalizzato - mentre io sto bene con il fatto che sono aziende a scopo di lucro e il loro firmware è chiuso, non sto certo bene che mi impediscano di installare quello che voglio su i miei dispositivi personali per cui ho pagato del denaro, per alcuni cosiddetti "security" anche se la NSA ha già rubato la chiave da loro (ricordo di aver installato un BIOS personalizzato sul mio vecchio Thinkpad perché quello originale aveva una whitelist PCI ID scheda wireless che mi impediva dalla modifica del loro obsoleto 802.11g per un modello 11n, qualcosa di impossibile con i controlli della firma del firmware in atto).
Un'altra soluzione migliore consiste nel richiedere un intervento fisico (premendo un pulsante hardware sul dispositivo stesso) per consentire l'installazione del firmware, che non presenta gli inconvenienti sopra riportati; il controllo di autenticità del firmware deve essere eseguito dall'utente ed è libero di installare ciò che desidera. Se l'utente desidera installare il firmware, preme il pulsante e il dispositivo consente l'installazione di un firmware prima di bloccarsi di nuovo (o il timeout dopo un minuto se non è stato installato nulla).
L'unico inconveniente di questa opzione è che ogni dispositivo avrebbe il proprio pulsante hardware, su un tipico computer desktop c'è il BIOS / EFI (che aggiornerà spesso tutto il resto incorporato nella scheda: NIC, controller RAID "falso", ecc. ), possibilmente l'opzione ROM della scheda video di terze parti (chiamata anche video BIOS), controller RAID di terze parti o NIC, unità di archiviazione, ecc.
Mentre tutto sulla scheda poteva essere collegato a un singolo pulsante, tutto l'hardware di terze parti avrebbe il proprio pulsante, a volte difficile da premere a causa dell'hardware che si trova all'interno del case del computer. Questo non è troppo problematico in quanto gli utenti incapaci di aprire un case del computer di solito non aggiornano il firmware comunque a causa del "rischio" (è minimo ma creare dischi DOS avviabili fa paura) e complessità.
Una soluzione teorica consisterebbe nel richiedere che tutte le porte comunemente utilizzate (SATA, PCIe, ecc.) includano una linea dedicata "firmware flash" che sia collegata al pulsante flash firmware principale della scheda.
L'unico modo in cui può essere completamente evitato è di non avere alcun tipo di memoria non volatile scrivibile sul dispositivo. Il problema con questo è che impedirebbe il cambiamento del firmware che potrebbe complicare le cose.
Il problema in questi giorni, da quanto ho capito, è che ci devono essere comandi di lettura / scrittura di basso livello per accedere agli spazi in memoria che contengono il firmware. Anche quando non sono resi pubblici, questi comandi possono essere trovati tramite brute-force, se necessario (se non si sta sniffando un'interfaccia durante l'aggiornamento). Quindi penso che la domanda sarebbe migliore "È possibile impedire completamente la lettura / scrittura alle posizioni in cui si trova il firmware?" Il che mi riporta alla prima frase.
Un'opzione potrebbe essere quella di implementare i certificati firmati e di conservare un certificato dal produttore nella ROM. Il firmware potrebbe essere firmato e controllato tramite il certificato all'accensione. Ciò aggiungerebbe un sacco di spese generali che non esiste oggi e non è privo di problemi. Se un certificato è compromesso, come lo revochi in una situazione come questa. Cosa accadrebbe se dovesse scadere? Potrebbe scadere? Inoltre, è necessario aggiungere capacità (elaborazione e memoria) per utilizzare qualsiasi funzione crittografica a bordo del dispositivo e non accessibile tramite il normale I / O. Tutto ciò probabilmente aggiungerebbe un significativo aumento dei costi (sia nella progettazione che nella produzione).
Come commento finale, direi che probabilmente è possibile renderlo molto più difficile, ma probabilmente non varrebbe la pena l'aumento dei costi per l'utente finale. Basare la mia opinione su questo sarebbe molto costoso per fare contromisure e che ci vuole un pezzo di malware appositamente predisposto (per il modello e la probabile versione del firmware) da sfruttare, direi che probabilmente non è fattibile per quasi nessuna applicazione. Questo potrebbe escludere chiunque abbia tasche estremamente profonde (o tasche che si estendono fino ai contribuenti).
Mi piace la risposta di André di avere un interruttore o un pulsante per programmare il firmware. Alcuni dispositivi hanno già questo, molte schede madri ad esempio dispongono di un ponticello per proteggere il BIOS dalla scrittura.
Costringere il dispositivo a non funzionare correttamente in modalità programma firmware consentirebbe all'utente di vedere se qualcosa fosse incerto. Come un dispositivo audio che non emette audio o una scheda video che consente solo la modalità video di base. La combinazione di un ponticello di protezione da scrittura con un pulsante di programma potrebbe essere eccessivo, ma sarebbe più sicuro.
Un'altra opzione è quella di avere un codice di scrittura impresso all'esterno di un circuito stampato o di un circuito integrato e avere lo stesso codice inciso in modo permanente nell'intestino del circuito integrato. Un flash del firmware potrebbe riuscire solo se si inserisce questo codice durante la programmazione. Il codice non può essere letto dal dispositivo stesso, solo verificato se è corretto o meno. Ciò richiederebbe l'accesso al circuito per ottenere il codice e non è un ostacolo a un attacco mirato. Anche un produttore di dispositivi può colludere e fornire un elenco di numeri di serie del dispositivo e dei relativi codici. Tuttavia, quando combinato con il firmware firmato e un ponticello di blocco della scrittura, renderà la programmazione del firmware dannoso molto più difficile.
Potrebbe essere utile anche uno sforzo a lungo termine per creare uno standard per la catena di custodia per i dispositivi hardware, che includerebbe solo l'autorizzazione del firmware a un dispositivo PCI (e) o USB se il controller a cui era collegato lo consentiva, e fare in modo che la catena raggiunga il firmware del sistema principale. La password del BIOS proteggerà quindi tutti i dispositivi contro le modifiche del firmware, a meno che non ci sia una vulnerabilità che consenta un bypass.
Penso che sia altrettanto importante che ci sia un modo per verificare che il firmware non sia compromesso, il che significa che un dispositivo può segnalare un checksum crittografico del suo firmware al suo dispositivo di controllo in un modo che non può essere manipolato dal firmware dannoso . La standardizzazione di questo sarebbe un ottimo modo per infondere fiducia quando l'hardware viene utilizzato in situazioni sensibili.