Ransomware e UEFI: approfondimento

La minaccia ransomware esiste da oltre dieci anni e nel corso di questo tempo si è sviluppata acquisendo logiche applicative sempre più sofisticate e difficili da individuare e contrastare. Di recente un ricercatore del gruppo ESET (Martin Smolar) ha individuato un comportamento particolarmente pericoloso di una variante del malware Petya. Tale comportamento consiste nella capacità di infettare il UEFI (Unified Extensible Firmware Interface).

Che cosa è lo UEFI

Il codice UEFI viene eseguito quasi subito dopo l’accensione del computer, prima dell’avvio del sistema operativo e di qualsiasi soluzione di sicurezza a livello di sistema operativo, garantendo al malware di operare con massimi privilegi ed in un ambiente non protetto. Il firmware UEFI è essenziale per il sistema perché, durante il suo caricamento, attiva tutte quelle operazioni, quei processi e quelle periferiche, necessari al sistema operativo per il corretto funzionamento.

UEFI e origini

Bisogna spiegare che il firmware UEFI è stato introdotto agli inizi degli anni 2000 come evoluzione del predecessore BIOS. Nel 2005 viene fondato lo Unified EFI Forum (UEFI Forum), un consorzio di aziende che ha preso in carico la specifica EFI 1.10 di Intel e ha iniziato a svilupparla nello standard UEFI. L’anno in cui il nome UEFI viene adottato formalmente come consorzio è il 2005. I primi PC dotati di UEFI e distribuiti su larga scala arriveranno solo nel 2010; Microsoft, ad esempio, attenderà Windows 8 (2012) per sfruttare a pieno il firmware UEFI. Il motivo che ha spinto all’abbandono del BIOS a favore del UEFI è da ricercarsi, prevalentemente, dal punto di vista prestazionale.

• Può avviare il sistema in meno tempo grazie alla gestione più efficiente del processo di boot e all’eliminazione della lunga auto-diagnosi del BIOS (POST — Power-On Self-Test).
• Può gestire, a differenza del BIOS, dischi rigidi con capacità superiori a 2.2 TB utilizzando la tabella delle partizioni GPT (GUID Partition Table).
• Essendo eseguito in modalità a 64 bit, ha accesso a una maggiore quantità di memoria (RAM) e può eseguire più rapidamente i processi in fase di pre-avvio.
• Offre un’interfaccia utente grafica più moderna e intuitiva, con supporto per il mouse, superando la vecchia interfaccia del BIOS che era testuale e limitata al comando tramite tastiera.
• Supporta funzionalità di rete e può caricare driver e applicazioni specifiche (moduli EFI) prima del sistema operativo.

UEFI e funzionamento principale

Il funzionamento del firmware UEFI è importante, pertanto è necessario comprenderlo. La prima cosa da sapere è che il firmware UEFI vero e proprio è memorizzato su un chip installato sulla scheda madre del computer. Tuttavia, il firmware UEFI, per avviare il sistema, ha bisogno di leggere alcuni file di avvio che si trovano in una specifica partizione di memoria chiamata EFI System Partition. Questa partizione di memoria (generalmente in formato FAT32) è installata dentro alla memoria di massa del sistema (HDD o SSD). Quindi il firmware UEFI si compone essenzialmente da due parti:

• Il chip installato sulla scheda madre del computer.
• La EFI System Partition creata nella memoria di massa del sistema.

Questa è anche una differenza radicale con il precedente sistema (il BIOS) che non aveva partizioni su disco ma risiedeva interamente all’interno del chip di memoria sulla scheda madre. Questa soluzione lo rendeva meno versatile ma più sicuro rispetto al UEFI.

Durante il caricamento iniziale del firmware UEFI, vengono eseguite procedure essenziali come un reset iniziale del processore di sistema e una inizializzazione preliminare delle memorie (PEI – Pre EFI Initialization). A seguito della PEI vi è quindi l’inizializzazione dei driver (DXE – Driver Execution Enviroment) e solo a questo punto si procede con l’avvio del sistema operativo. Per maggiore comprensione si riportano le fasi con la relativa descrizione

È quindi chiaro che, da quando si preme il pulsante di accensione del computer a quando appare la schermata di caricamento del sistema operativo, il sistema UEFI s’incarica di eseguire procedure essenziali e propedeutiche benché in un ambiente operativo a scarsa sicurezza. Alla fine di questa procedura preliminare il firmware chiama la funzione ExitBootServices() e a quel punto si passa al caricamento del sistema operativo.

UEFI e sicurezza

Per la sua natura strategica, il firmware UEFI dovrebbe essere mantenuto sicuro attraverso aggiornamenti che gli utenti dovrebbero fare regolarmente. Gli aggiornamenti sono realizzati, come prassi, dal produttore e hanno lo scopo di aumentare la stabilità e la sicurezza del sottosistema. Nonostante gli accorgimenti finora presi il firmware UEFI non può essere considerato un ambiente “sicuro”, tanto è vero che in passato c’erano già state minacce che avevano sfruttato il UEFI o effettuato by-pass delle relative funzioni per scopi malevoli, vale la pena ricordare:

• BlackLotus (sfrutta CVE-2022-21894)
• BootKitty
• MosaicRegressor (un framework malevolo che include un bootkit UEFI, scoperto nel 2020)

Esistono delle meccaniche di protezione del UEFI. Una di queste viene denominata UEFI Secure Boot ed è progettata per impedire l’esecuzione di codice non firmato o non autorizzato durante l’avvio. Questa misura di sicurezza, tuttavia, deve essere aggiornata regolarmente proprio per accogliere tutte le modifiche di sicurezza apportate nel tempo.

Nello specifico il UEFI Secure Boot si basa su un database chiamato Forbidden Signature Database (DBX) che memorizza le firme digitali di software di avvio (boot loader) identificati come vulnerabili o compromessi (ad esempio, a causa di exploit noti come “bootkit” o bug di sicurezza nel codice firmato). Microsoft e altri partner rilasciano periodicamente aggiornamenti per il DBX. Di conseguenza, se non si aggiorna il DBX, il sistema potrebbe consentire l’esecuzione di vecchi boot loader dannosi di cui è nota la vulnerabilità, compromettendo la sicurezza all’avvio. Questi aggiornamenti vengono spesso distribuiti tramite Microsoft Windows Update o direttamente dal produttore del PC.

Bisogna anche considerare che i certificati di autorità di firma (come quelli di Microsoft che firmano i boot loader di Windows) hanno una data di scadenza. Ad esempio, alcuni certificati chiave sono in fase di rinnovo e per garantire che il sistema continui a riconoscere e avviare le versioni più recenti del sistema operativo in modo sicuro, è necessario aggiornare i database dei certificati (DB – Allowed Signature Database) e, talvolta, la KEK (Key Enrollment Key)³ prima della loro scadenza.

In conclusione è quindi chiaro che per correggere queste falle, i produttori di schede madri e PC rilasciano aggiornamenti del BIOS/UEFI; l’installazione del firmware più recente è quindi fondamentale per mantenere l’integrità del Secure Boot. È bene ricordare che l’installazione di questi aggiornamenti è anche un obbligo di legge per le P.A. e i soggetti impattati dalla NIS2, oltre che una buona prassi.

Il caso HybridPetya

HybridPetya è una nuova variante ransomware Petya/NotPetya, ma con una significativa aggiunta: la capacità di compromettere i sistemi basati sul firmware UEFI. A differenza dei suoi predecessori, HybridPetya è in grado di installare una applicazione EFI malevola nella Partizione di Sistema EFI (ESP). Questa applicazione viene eseguita durante l’avvio del sistema, permettendo al malware di operare in un livello di privilegio molto elevato, ancora prima che il sistema operativo si carichi. Una volta in esecuzione, l’applicazione UEFI si occupa della crittografia della Master File Table (MFT), un file cruciale che contiene i metadati di tutti i file sulle partizioni NTFS, rendendo il sistema inaccessibile. Alcune varianti analizzate di HybridPetya sfruttano la vulnerabilità CVE-2024-7344 (una falla in un’applicazione UEFI di terze parti) per aggirare l’UEFI Secure Boot sui sistemi non aggiornati.

A quanto pare, sebbene i campioni di HybridPetya siano stati scoperti relativamente di recente (nel 2025 secondo le ricerche), non ci sono ancora segnali di un suo uso attivo in attacchi “in the wild”, ma rappresenta una chiara evoluzione delle tattiche ransomware. A differenza di NotPetya, che era prevalentemente distruttivo, HybridPetya sembra essere stato progettato per il guadagno finanziario, consentendo teoricamente la ricostruzione della chiave di decrittazione dal codice di installazione personale della vittima (più simile a Petya).

La capacità di un ransomware di attaccare il firmware UEFI è una delle minacce più gravi nel panorama della sicurezza informatica, poiché consente al malware di sopravvivere anche a un cambio di disco, alla formattazione completa o alla reinstallazione del sistema operativo. L’unica soluzione in molti casi è l’aggiornamento (o la sostituzione) del firmware della scheda madre. Sfruttando vulnerabilità specifiche o chiavi compromesse, un bootkit UEFI può disattivare o aggirare meccanismi di sicurezza critici come l’UEFI Secure Boot, che altrimenti impedirebbe il caricamento di driver o bootloader non firmati.

Contromisure

Lo scenario più drastico su cui operare è l’infezione del UEFI con conseguente compromissione dell’intero processo di avvio ed è quindi chiaro che la soluzione non può essere la formattazione/sostituzione dei dischi. L’attività di bonifica deve iniziare molto prima con il flashing del chip UEFI. Si tratta di una procedura di sovrascrittura del UEFI con una versione aggiornata e scaricata dal portale internet del produttore oppure ripristinando la versione originaria. In alcuni casi la versione originaria risiede in un chip di sola lettura⁴ (ROM — Read Only Memory) che può essere impiegato per i casi estremi. Nei casi più gravi è possibile pensare, ma non sempre eseguire, ad una sostituzione completa del chip, inserendolo in un programmatore ma certamente questi casi sono riservati a ambiti molto piccoli e specialistici. Nella stragrande maggioranza dei casi, in condizione di grave infezione, è necessario sostituire interamente la scheda madre con un consistente aumento di complessità e costi di bonifica e ripristino.

Talvolta ci si chiede se sia possibile effettuare una sostituzione “facile” del chip, senza ricorrere a complesse attività di debulking (rimozione della saldatura, estrazione del chip e sostituzione con uno nuovo). In teoria si potrebbe fare ma solo a patto di rispettare alcune condizioni specifiche. La prima è che le caratteristiche generali siano identiche: stesso produttore, stesso modello, e preferibilmente la stessa revisione. La seconda è che le caratteristiche di dettaglio siano uguali: stessa capacità di memoria, stessa tensione, identico pinout e tipo di socket/saldatura.

Inoltre bisogna considerare che l’attività di scambio del chip non andrebbe supervisionata da una procedura specifica poichè il firmware UEFI contiene dati unici della piattaforma (come il numero di serie della scheda madre, l’indirizzo MAC della scheda di rete, e in alcuni casi, la licenza digitale OEM del sistema operativo Windows); scambiando il chip, si trasferiscono anche questi dati e quindi questo potrebbe avere impatti sul sistema nella sua complessità.

Infine è bene tenere presente che la sostituzione del chip UEFI potrebbe non essere risolutiva se non si è proceduto anche alla bonifica della partizione nella memoria di massa: infatti, se persistesse un’infezione nella Partizione di Sistema EFI, ci sarebbe il rischio di infettare il nuovo chip appena installato con il malware residente nella Partizione di Sistema EFI. Ciò vanificherebbe l’intera operazione e aumenterebbe i costi.

Inoltre esistono tool di facile accesso che possono verificare (con discreta affidabilità) la condizione d’integrità del firmware UEFI andando ad intercettare, come nel caso presente, le alterazioni compiute da un malware.

EFI_STATUS EFIAPI MaliciousEntryPoint(IN EFI_HANDLE ImageHandle, IN EFI_SYSTEM_TABLE *SystemTable) {
    // Intercetta la funzione ExitBootServices per iniettare un payload
    OriginalExitBootServices = SystemTable->BootServices->ExitBootServices;
    SystemTable->BootServices->ExitBootServices = HookedExitBootServices;

    return EFI_SUCCESS;
}

EFI_STATUS EFIAPI HookedExitBootServices(IN EFI_HANDLE ImageHandle, IN UINTN MapKey) {
    // Payload simulato: registra l'evento di avvio (in un malware reale, qui potrebbe iniziare la cifratura)
    LogToHiddenPartition("Avvio del sistema intercettato");

    // Chiama la funzione originale
    return OriginalExitBootServices(ImageHandle, MapKey);
}

Molti prodotti di sicurezza sono in grado di effettuare questo tipo di controllo in modo automatico e abbastanza efficace, anche ESET ha introdotto questa possibilità nei suoi prodotti.

Conclusioni

È importante sottolineare che, alla data attuale, l’infezione del firmware UEFI è un evento estremamente raro e solitamente associato ad attacchi sofisticati difficilmente riservati a soggetti di bassa caratura. Tuttavia è altrettanto rilevante notare l’evoluzione che tale minaccia sta avendo negli anni, portando un costante aggiornamento delle dinamiche di attacco e delle logiche di contrasto, non sempre all’altezza. Inoltre è possibile notare come, al passaggio da BIOS a UEFI e con il relativo aumento della complessità elaborativa, sia corrisposto un proporzionale aumento delle minacce e dei rischi a cui sono esposti i sistemi.

Note

1. La Key Exchange Key (Chiave di Scambio Chiavi) è un elemento fondamentale nella catena di fiducia del UEFI Secure Boot. La sua funzione cruciale è quella di firmare e autorizzare gli aggiornamenti del database delle chiavi consentite (DB) e di quello delle chiavi revocate (DBX). La KEK (spesso di proprietà di Microsoft o del produttore dell’OS/OEM) verifica gli aggiornamenti per DB e DBX. ↩︎
2. La sola lettura è garantita da componenti elettronici fisici che permettono la trasmissione elettrica in una sola direzione (ad es.: i diodi). ↩︎