Cosa insegna l'hack della Xbox sulla sicurezza hardware

Microsoft ha progettato l'architettura di sicurezza della Xbox One per essere impenetrabile. Un hardware root of trust. Un hypervisor personalizzato. Storage cifrato con chiavi per singola console. Catene di boot firmate, dove ogni stadio verifica il successivo. Non era teatro della sicurezza: era una difesa multistrato davvero sofisticata, progettata da uno dei migliori team di ingegneria della sicurezza del settore. La definivano inviolabile.

È stata violata. Un gruppo che si fa chiamare 'Bliss' ha ottenuto esecuzione di codice completa sulla Xbox One, aggirando l'hypervisor, la verifica della catena di boot e il processore di sicurezza hardware. I dettagli dell'exploit sono affascinanti, ma ancora più interessante è ciò che rivela sui limiti fondamentali della sicurezza hardware e sul perché 'inviolabile' sia sempre una parola pericolosa.

L'architettura di sicurezza della Xbox

Per capire perché questo hack conta, bisogna capire che cosa ha superato. Il modello di sicurezza della Xbox One è una delle implementazioni più complete di sicurezza hardware per consumatori mai distribuite.

Il processo di boot parte da un hardware root of trust, codice impresso nel SoC che non può essere modificato. Questo codice verifica e carica il bootloader della fase successiva, che verifica e carica l'hypervisor, che a sua volta verifica e carica il sistema operativo. Ogni stadio è firmato con le chiavi di Microsoft. Se una verifica fallisce, la console non si avvia. Si tratta di una classica catena di secure boot, simile a quella offerta da ARM TrustZone e dal Boot Guard di Intel.

L'hypervisor, un software personalizzato che gira a un livello di privilegio superiore a quello del sistema operativo, impone l'isolamento della memoria, controlla l'accesso all'hardware e impedisce al SO di modificare lo stato critico del sistema. Giochi e app girano in macchine virtuali che non possono vedere né modificare la memoria l'una dell'altra. Anche trovando un exploit nel kernel della Xbox, si resta comunque intrappolati nella sandbox dell'hypervisor.

In aggiunta, lo storage della console è cifrato con chiavi derivate dal processore di sicurezza hardware. Non si può estrarre il disco rigido, leggerlo su un'altra macchina e ricavarne qualcosa di utile. Le chiavi di cifratura sono legate allo specifico hardware, un design chiamato device-specific sealing, usato anche nei TPM e nel Secure Enclave di Apple.

Dove l'armatura si è crepata

Ogni sistema di sicurezza si basa su delle assunzioni. Quelle della Xbox erano ragionevoli: il root of trust hardware è immutabile, la catena di boot è inviolabile perché la crittografia è solida, l'hypervisor non ha bug sfruttabili perché è una base di codice piccola e verificata. Ogni assunzione, presa singolarmente, è difendibile. Il problema è che le catene di sicurezza cedono dal loro anello più debole, e trovarlo richiede creatività, non solo forza bruta.

L'exploit di Bliss non ha attaccato la crittografia (AES e RSA vanno bene), non ha trovato bug nella ROM del root of trust (è minuscola e ben verificata) e non ha forzato nessuna chiave. Ha invece sfruttato l'interfaccia tra i domini di sicurezza, il canale stretto attraverso cui comunicano il mondo fidato e quello non fidato.

I modelli di sicurezza hardware sono più solidi quando la superficie di attacco tra i livelli di fiducia è minima. Ma 'minima' non vuol dire zero. L'hypervisor deve esporre qualche interfaccia al sistema operativo guest: chiamate di sistema per la gestione della memoria, accesso ai dispositivi e comunicazione tra VM. Ciascuna di queste interfacce è un potenziale vettore d'attacco. Il team Bliss ha trovato una sequenza di chiamate all'hypervisor che, invocate con parametri specifici e in un ordine preciso, hanno corrotto lo stato interno dell'hypervisor abbastanza da dirottare l'esecuzione del codice.

Lo schema più ampio

L'hack della Xbox segue uno schema che si ripete in tutta la sicurezza hardware: il progetto iniziale è solido, l'implementazione è accurata, ma l'interfaccia tra i domini di sicurezza contiene bug sottili che emergono solo con un uso ostile.

• L'hack della PS3 (2010) ha sfruttato un errore implementativo catastrofico nella generazione delle firme ECDSA di Sony: usavano un numero casuale fisso invece di uno nuovo per ogni firma, il che esponeva la chiave privata. La matematica era corretta. L'implementazione no.
• L'hack della Nintendo Switch (2018) ha sfruttato un bug nella boot ROM Tegra di NVIDIA: la modalità di recupero USB accettava payload che sovrascrivevano un buffer, consentendo l'esecuzione di codice prima che girasse qualsiasi controllo di sicurezza software. La catena di boot era ben progettata. La modalità di recupero non rientrava nel modello delle minacce.
• Gli attacchi a Intel SGX hanno più volte dimostrato che i side channel (Spectre, Meltdown e le loro numerose varianti) possono far trapelare dati dagli enclave sicuri, pur con un modello di isolamento architetturalmente corretto. La logica è corretta. La microarchitettura perde informazioni.

Lo schema è questo: i progettisti ragionano sul modello di sicurezza a un certo livello di astrazione (protocolli crittografici, confini di isolamento, gerarchie di fiducia), mentre gli attaccanti operano a un altro livello (peculiarità implementative, effetti collaterali microarchitetturali, casi limite delle interfacce). Il modello è corretto. L'implementazione presenta lacune che il modello non aveva previsto.

Perché 'inviolabile' è sempre sbagliato

Definire qualcosa inviolabile è un campanello d'allarme, non un segnale di affidabilità. Significa che i progettisti credono di aver elencato tutti gli attacchi possibili e di essersi difesi da ciascuno. Ma la storia della sicurezza è una storia di categorie di attacco che non esistevano quando la difesa è stata progettata.

Quando la Xbox One è uscita nel 2013, Spectre e Meltdown non erano ancora stati scoperti. Rowhammer era teorico. Gli attacchi di voltage glitching sui SoC moderni non erano ben compresi. I progettisti non potevano difendersi da attacchi che non erano ancora stati inventati. E alcuni attacchi che avevano previsto potevano essere poco pratici all'epoca, ma sono diventati fattibili man mano che strumenti e tecniche sono migliorati.

Una buona ingegneria della sicurezza non pretende l'impermeabilità. Riconosce che le violazioni accadranno e progetta per il rilevamento, il contenimento e il ripristino. La differenza tra un pensiero di sicurezza maturo e uno immaturo è quella tra 'come rendiamo questo inviolabile?' e 'cosa succede quando questo si rompe?'

Implicazioni per gli sviluppatori software

La maggior parte degli sviluppatori non progetta architetture di sicurezza per console, ma le lezioni valgono in generale.

Le interfacce tra i confini di fiducia sono il codice a rischio più alto. Il confine tra il tuo backend e internet pubblico, tra la tua applicazione e i plugin di terze parti, tra il database e le query fornite dagli utenti. È lì che vivono i bug che contano. Una SQL injection non è un bug in SQL o nel tuo database: è un bug all'interfaccia tra il dominio fidato (la logica delle tue query) e quello non fidato (l'input utente). Concentra l'attenzione sulla sicurezza proprio su questi confini.

La difesa in profondità non è facoltativa. La Xbox aveva più livelli: root of trust hardware, secure boot, isolamento dell'hypervisor, cifratura dello storage. Superarne uno non bastava. Gli attaccanti hanno dovuto concatenare più exploit per ottenere il controllo completo. Se il sistema si fosse affidato a un solo confine di sicurezza, il primo exploit sarebbe stato la fine.

Il tuo modello delle minacce sarà sbagliato. Non perché sia costruito male, ma perché il panorama delle minacce cambia. La storia dell'escalation dei privilegi è piena di attacchi impensabili al momento della progettazione delle difese. Costruisci sistemi che possano essere aggiornati, patchati e irrobustiti senza essere riprogettati. Dai per scontato che l'attacco 'impossibile' di oggi sarà la CVE di domani.

Il paradosso della sicurezza aperta

La sicurezza delle console si basa sulla segretezza: hardware proprietario, hypervisor closed-source, firmware cifrato. È la cosiddetta security through obscurity, che la comunità della sicurezza in genere considera un approccio debole. Ma l'alternativa, cioè hardware di sicurezza open source, ha i suoi problemi: gli attaccanti possono studiare l'implementazione esatta e cercare vulnerabilità con tutto il tempo che vogliono.

La risposta pratica è che entrambi gli approcci prima o poi falliscono. I sistemi chiusi vengono sottoposti a reverse engineering (l'hack della Xbox lo dimostra). I sistemi aperti vengono studiati e attaccati (il flusso costante di CVE del kernel Linux lo dimostra). La differenza è che i sistemi aperti vengono corretti più in fretta, perché chi difende ha la stessa visibilità di chi attacca. La vulnerabilità della Xbox, qualunque siano i dettagli esatti, sarà più difficile da patchare perché il modello di sicurezza è incorporato nell'hardware, che non può essere cambiato sul campo.

Per i sistemi software, dove gli aggiornamenti sono possibili, questo spinge con forza verso implementazioni di sicurezza aperte e ben verificate, anziché proprietarie. Non perché i sistemi aperti siano più difficili da attaccare, ma perché sono più facili da correggere quando l'inevitabile attacco riesce.

Cosa succede dopo

L'hack della Xbox non metterà fine alla sicurezza delle console. Microsoft studierà l'exploit, correggerà via software ciò che può e progetterà l'hardware della prossima generazione per chiudere questa classe di vulnerabilità. Gli attaccanti troveranno qualcos'altro. È il ciclo: difesa e attacco che evolvono insieme, con la sicurezza di ogni generazione che incorpora le lezioni dai fallimenti della precedente.

La conclusione utile non è che la sicurezza hardware sia inutile. È che la sicurezza hardware è uno spettro, non un binario. La sicurezza della Xbox ha reso l'hacking drasticamente più difficile: ci sono voluti più di dieci anni. È un successo enorme, anche se non è la perfezione. L'obiettivo non è un sistema inviolabile, ma un sistema in cui il costo dell'attacco supera il valore del bersaglio per tutto il tempo in cui il sistema deve essere protetto. Con questo metro, la sicurezza della Xbox One è stata sorprendentemente efficace. Non era infinita, tutto qui.