[ad_1]
Conferma BootHole Secure Boot minaccia per dispositivi Linux e Windows
È stata confermata una vulnerabilità di sicurezza di alto livello nella funzione Secure Boot della maggior parte di laptop, desktop, workstation e server. Ecco cosa devi sapere su BootHole.
I ricercatori di sicurezza di Eclypsium hanno scoperto una vulnerabilità che colpisce il bootloader utilizzato da quasi tutti i sistemi Linux e quasi tutti i dispositivi Windows che utilizzano Avvio sicuro con l’interfaccia unificata del firmware estensibile standard di Microsoft (UEFI) autorità di certificazione.
Che cos’è BootHole?
CVE-2020-10713, soprannominato BootHole, ha un punteggio CVSS elevato di 8,2 e si trova nel GRand Unified Bootloader 2 predefinito (GRUB2) ma influisce sui sistemi che eseguono Secure Boot anche se non utilizzano GRUB2.
Se sfruttato con successo, BootHole apre i dispositivi Windows e Linux all’esecuzione di codice arbitrario durante il processo di avvio, anche quando Secure Boot è abilitato. Significa che un utente malintenzionato potrebbe acquisire persistenza per malware installato di nascosto e fornire loro “un controllo quasi totale” sul dispositivo, secondo Eclypsium.
La risposta del settore a questa minaccia, scoperta nell’aprile 2020, è stata uno sforzo congiunto di più fornitori che condividono informazioni per trovare una soluzione.
Il risultato è oggi una divulgazione coordinata globale. Simili a Canonical, Microsoft, Red Hat, SUSE, Debian, Citrix, Oracle e VMware stanno annunciando tutti gli avvisi e le mitigazioni oggi, con alcuni aggiornamenti disponibili immediatamente, altri ancora in arrivo.
Un miliardo di dispositivi potrebbe essere a rischio, forse di più
Ho chiesto a John Loucaides, vicepresidente della ricerca e sviluppo di Eclypsium, quanti dispositivi sono a rischio a causa della vulnerabilità BootHole. “La configurazione predefinita consente l’avvio sicuro con l’autorità di certificazione Microsoft UEFI che ha firmato molte versioni vulnerabili di GRUB su quasi tutti i dispositivi venduti con la certificazione del logo Windows da Windows 8”, afferma.
Poiché Secure Boot è l’impostazione predefinita per la maggior parte dei sistemi venduti da Windows 8, Eclypsium ha notato che ciò significa che “la maggior parte dei laptop, desktop, server e workstation sono interessati, così come le appliance di rete”. Un numero che potrebbe facilmente superare il miliardo.
Ho anche parlato con Joe McManus, direttore della sicurezza di Canonical, che pubblica Ubuntu. “Questa è una vulnerabilità interessante e grazie a Eclypsium, Canonical, insieme al resto della comunità Open Source, ha aggiornato GRUB2 per difendersi da CVE-2020-10713”, afferma.
Il che è positivo, ma McManus mi ha poi rivelato che “durante questo processo, noi identificato altre sette vulnerabilità in GRUB2 che sarà risolto anche negli aggiornamenti rilasciati oggi. “È un ottimo esempio di cooperazione all’interno della comunità del software open source e oltre, questo è certo.
Quanto dovresti preoccuparti di questa minaccia al dirottamento di Secure Boot per i tuoi dispositivi?
Il processo UEFI Secure Boot e il ruolo svolto da GRUB2 sono altamente tecnici. Se vuoi tutti i dettagli nodosi, ti consiglio vivamente di leggere l’Eclypsium “C’è un buco nel bagagliaio“report o la knowledge base di Ubuntu Bypass GRUB2 Secure Boot articolo.
La versione ridotta è che UEFI Secure Boot utilizza le firme crittografiche per convalidare l’integrità del codice in base alle necessità durante il processo di avvio e, come già accennato, è lo standard predefinito per la maggior parte dei laptop, desktop e server.
Ogni bit di firmware e software viene controllato prima di essere eseguito e quelli non riconosciuti non vengono eseguiti.
Come puoi immaginare, determinare chi è autorizzato a firmare il codice attendibile dal database Secure Boot è piuttosto importante e l’autorità di certificazione UEFI di terze parti (CA) di Microsoft è lo standard del settore.
I progetti open source e altri utilizzano uno shim, una piccola applicazione, per contenere il certificato e il codice del fornitore per verificare ed eseguire il bootloader GRUB2. Tale shim viene verificato utilizzando la CA UEFI di terze parti Microsoft prima che lo shim venga caricato e verifichi il bootloader GRUB2.
BootHole è una vulnerabilità di overflow del buffer che coinvolge il modo in cui GRUB2 analizza il file di configurazione e consente a un utente malintenzionato di eseguire codice arbitrario e ottenere il controllo sull’avvio del sistema operativo.
La minaccia del mondo reale da BootHole
Se riesci a sentire un “ma” in arrivo, è perché ce n’è uno: ma solo se l’attaccante è già sul sistema e ha privilegi elevati. Questa non è una vulnerabilità legata all’esecuzione di codice in modalità remota; se fosse, quindi immagino, piuttosto che essere una vulnerabilità di alto livello, sarebbe una critica.
“Gli attacchi bootkit contro i quali Secure Boot mira a proteggere vengono generalmente impiegati per persistenza, interruzione o per evitare altre misure di sicurezza”, afferma Loucaides, aggiungendo che “le recenti campagne ransomware hanno attaccato bootloader su sistemi UEFI più recenti”. Dato che Secure Boot avrebbe continuato a funzionare normalmente, Loucaides mi disse: “ipoteticamente, questo sarebbe anche un buon modo per nascondere un attacco per lungo tempo, rubare credenziali o in attesa di lanciare un kill switch”.
Tuttavia, un esperto di intelligence sulle minacce e Cyjax CISO, Ian Thornton-Trump, non è eccessivamente preoccupato. “Sono riluttante a premere il pulsante di panico completo su questo problema”, afferma, “l’armonizzazione deve dipendere da una catena di exploit, dal fallimento della sicurezza a più livelli, per lanciare un attacco per ottenere l’accesso all’avvio del sistema operativo loader “.
Quindi, sebbene sia effettivamente una vulnerabilità enormemente diffusa, che colpisce quasi tutte le piattaforme, in teoria Thornton-Trump afferma che “il panorama delle minacce sta sfruttando superfici di attacco molto più facilmente disponibili, come i dirottamenti dei processi e l’iniezione di DLL”. Joe McManus dice anche che “non vede che si tratta di una vulnerabilità popolare usata in natura”.
Ho contattato Microsoft e un portavoce mi ha detto che era “a conoscenza di una vulnerabilità nel Grand Unified Boot Loader (GRUB), comunemente usato da Linux” e che Microsoft sta “lavorando per completare la convalida e il test di compatibilità di un requisito Pacchetto di Windows Update. ”
Comprendo che quando il pertinente Windows Update sarà disponibile, i clienti verranno avvisati tramite una revisione dell’avviso di sicurezza che dovrebbe essere pubblicato come parte della divulgazione coordinata di oggi e includerà un’opzione di mitigazione da installare come aggiornamento non testato.
La risposta del fornitore Linux a BootHole
Peter Allor, direttore della sicurezza dei prodotti di Red Hat, ha dichiarato: “stiamo lavorando a stretto contatto con la comunità Linux e i nostri partner del settore per fornire aggiornamenti ai prodotti Red Hat interessati, incluso Red Hat Enterprise Linux”.
Un portavoce di Debian mi ha detto che “Debian sta lavorando con il resto della comunità Linux per preparare gli aggiornamenti per affrontare questa vulnerabilità. La sicurezza è molto importante per noi, i nostri utenti e la nostra comunità”. Ulteriori informazioni possono essere trovate Qui.
Un portavoce di SUSE afferma che “siamo a conoscenza della vulnerabilità di Linux chiamata BootHole condivisa oggi da Eclypsium, e i nostri clienti e partner possono essere certi che abbiamo rilasciato pacchetti GRUB2 fissi che chiudono la vulnerabilità BootHole per tutti i prodotti SUSE Linux oggi e stanno rilasciando gli aggiornamenti corrispondenti ai pacchetti del kernel Linux, all’immagine cloud e ai supporti di installazione “.
Quindi, per riassumere, saranno rese disponibili patch per GRUB2 per risolvere la vulnerabilità con le distribuzioni Linux e altri fornitori che aggiornano i loro installer, bootloader e shim.
I nuovi shim dovranno essere firmati dalla CA UEFI di terze parti Microsoft e gli amministratori dei dispositivi interessati dovranno aggiornare le versioni installate dei sistemi operativi sul campo, nonché le immagini degli installatori, inclusi i supporti per il ripristino di emergenza. L’elenco di revoche UEFI nel firmware di ciascun sistema interessato dovrà eventualmente essere aggiornato per evitare che BootHole sia sfruttabile durante l’avvio.
[ad_2]
