UEFI, il sostituto del BIOS, già aggredito con un bootkit

Prima c’era il BIOS che, una volta caricato, passava il controllo al Master Boot Record (MBR). D’ora in poi, sui personal computer di nuova generazione, non esisteranno più né BIOS né MBR perché entrambi saranno sostituiti dall’UEFI (Unified Extensible Firmware Interface), una piattaforma studiata per fornire un “framework” per lo sviluppo dei meccanismi di boot dei vari sistemi operativi. Con l’accoppiata BIOS e MBR era necessario programmare il boot loader utilizzando il linguaggio assembly mentre con UEFI tutto diventa può semplice.

Sino ad oggi, per chi scrive malware, non è stato difficoltosissimo allestire dei componenti nocivi che riuscissero ad entrare in funzione prima del caricamento del sistema operativo. Piuttosto frequente è infatti l’infezione del MBR, il settore di avvio presente sul disco fisso che contiene informazioni di importanza cruciale per il corretto caricamento del sistema operativo (vedere l’articolo Riparare il Master Boot Record e risolvere gli altri problemi che impediscono l’avvio di Windows). Il MBR occupa i primi 512 byte dell’hard disk e conserva la tabella delle partizioni, utilizzata dal sistema per stabilire quale partizione è impostata come “attiva”. Meno spesso viene bersagliato il BIOS del personal computer ma si tratta pur sempre di un’infezione tutt’altro che impossibile.

“Con l’avvento di UEFI non cambierebbe assolutamente nulla senza l’impiego di SecureBoot“, spiega Marco Giuliani, direttore della società di sicurezza italiana ITSEC, presentando uno studio elaborato dal collega Andrea Allievi e disponibile in lingua inglese a questo indirizzo.
“Noi abbiamo scritto il nostro boot loader UEFI che sovrascrive il boot loader di Windows, dopo di che intercettiamo il caricamento del kernel di Windows 8 e disattiviamo il controllo della firma dei driver e patchguard“, aggiunge Giuliani. “Non è niente di “nuovo” dal funzionamento di un comune “MBR rootkit”; l’unica differenza è che l’attacco è stato sferrato verso UEFI ed è anche molto piu semplice da mettere in pratica grazie all’ampio set di istruzioni C che sono disponibili“.

Allievi spiega nel dettaglio il funzionamento di UEFI e di come Windows 8 supporta le nuove specifiche evidenziando più volte come il processo che porta alla realizzazione di un bootkit (con questo termine ci si riferisce a quei malware ibridi che osservano un comportamento comune con le minacce che infettano il settore di boot e con quello dei rootkit) sia addirittura più semplice in ambito UEFI che sui BIOS di tipo tradizionale.

Nel video elaborato da Allievi, si vede come – dopo l’attivazione del bootkit sviluppato nei laboratori di ITSEC – risulti possibile, in ambiente Windows 8, caricare qualunque driver non firmato digitalmente ed applicare modifiche a qualunque routine di Windows a livello kernel.
Il ricercatore italiano osserva come, in futuro, si assisterà probabilmente ad una notevole diffusione di malware studiati per aggredire UEFI e per caricare codice nocivo prima del boot di Windows 8. “Una delle tecnologie che inibisce i bootkit EFI è Intel SecureBoot“, riconosce Allievi, “la domanda, però, è se sia giusto limitare la libertà individuale per motivi di sicurezza. Ritengo che sia un quesito di grande importanza“.

Secure Boot è la funzione che i produttori di personal computer dovranno attivare per ottenere il logo di certificazione Microsoft Windows 8: l’abilitazione di questa caratteristica obbligherà gli sviluppatori di software ad inserire una firma digitale nei propri prodotti. I detrattori, tra i quali vi sono i membri della Free Software Foundation (FSF), fondazione per lo sviluppo del software libero creata da Richard Stallman nel 1985, fanno notare però come Secure Boot complichi notevolmente le cose se l’utente desideri ad esempio affiancare a Windows 8 una qualunque distribuzione Linux od altri software liberi.
Canonical, società che cura lo sviluppo di Ubuntu, ha comunicato che impiegherà una propria firma digitale mentre Red Hat ha optato per l’acquisto di una firma Microsoft. Da FSF si sono levate critiche nei confronti di entrambe le decisioni: secondo la fondazione per la promozione del software libero si tratterebbe di “compromessi” che non risolvono la questione e che aggiungono complessità (vedere anche questi nostri articoli su SecureBoot).