themalwareguardian/cve-2026-79298Repository di ricerca che documenta CVE-2026-79298, una remediation incompleta del bypass di UEFI Secure Boot nel percorso di avvio IA-32 di Howyar SysReturn, con materiali di reverse engineering e PoC.
Una vulnerabilità è stata corretta. Un binario è stato revocato. Ma solo metà dell'architettura è stata sistemata. Diciotto mesi dopo, il percorso di avvio IA-32 portava ancora lo stesso loader PE personalizzato, la stessa verifica di Secure Boot aggirata e lo stesso hash Authenticode revocato - distribuito commercialmente in ogni copia di SysReturn NetCopy fino a luglio 2026. Questa è CVE-2026-79298.
Sono un ricercatore di sicurezza offensiva specializzato nello sfruttamento del firmware UEFI, nello sviluppo di bootkit/rootkit e nella ricerca sulle vulnerabilità. Questo è il campo a cui ho scelto di dedicare la mia carriera, e plasma tutto ciò che pubblico.
Sono coautore di UEFI Bootkits and Kernel-Mode Rootkits Development - un libro pionieristico sullo sviluppo di impianti offensivi a livello di firmware. Ho creato e rilasciato Abyss, un bootkit UEFI completo per Windows, e Antarctic, il primo framework bootkit UEFI disponibile pubblicamente per Linux. Entrambi sono strumenti open-source progettati per operatori di red team e ricercatori di sicurezza per comprendere, simulare e difendersi da minacce firmware del mondo reale. Accanto a questi, ho sviluppato Benthic, un rootkit kernel-mode per Windows, e Behemoth, uno strumento per l'analisi automatizzata di binari UEFI.
Costruire strumenti offensivi a questo livello significa comprendere non solo come funzionano i bootkit, ma anche come vengono installati. È qui che entrano in gioco le vulnerabilità UEFI. Ogni bypass di Secure Boot, ogni bootloader firmato in modo improprio, ogni loader PE personalizzato che salta la verifica - queste sono le porte attraverso cui passa il malware a livello di firmware. Ricercare e sfruttare tali vulnerabilità è un'estensione naturale del lavoro. Non si possono costruire strumenti offensivi realistici senza comprendere la reale superficie di attacco.
Quel percorso di ricerca - sviluppare malware UEFI, poi studiare le vulnerabilità che ne consentono il deployment - è ciò che mi ha portato a CVE-2024-7344 e infine ai risultati documentati qui.
A gennaio 2025, Martin Smolár e l'ESET Research Team hanno pubblicato la divulgazione di CVE-2024-7344 (Under the cloak of UEFI Secure Boot), un bypass di Secure Boot che colpiva molteplici prodotti software di ripristino, incluso Howyar SysReturn. La vulnerabilità era causata da un'applicazione UEFI firmata da Microsoft che implementava il proprio loader PE personalizzato (RxPE), aggirando completamente i servizi standard LoadImage e StartImage. Invece di affidarsi alla verifica Secure Boot integrata nel firmware, l'applicazione analizzava ed eseguiva manualmente un payload non firmato da un file chiamato cloak.dat, cifrato con XOR a chiave singolo byte, nessun controllo di firma, piena fiducia a livello di firmware.
Microsoft ha revocato i binari interessati nell'aggiornamento Patch Tuesday di gennaio 2025. L'advisory è stato pubblicato. La comunità di sicurezza è andata avanti. Ma io no.
Ho passato anni a studiare le vulnerabilità UEFI - non solo CVE-2024-7344, ma l'intero panorama dei bypass di Secure Boot, dei loader PE personalizzati e dei difetti a livello di progettazione nei componenti UEFI firmati. E c'è uno schema che ho visto ripetersi più e più volte: le stesse categorie di decisioni di progettazione errate riemergono tra vendor e tra anni. Una vulnerabilità viene divulgata, un binario viene revocato, e mesi o anni dopo appare un difetto simile - a volte nello stesso prodotto, a volte in un prodotto diverso dello stesso vendor, a volte nel codebase di un vendor completamente diverso che condivide le stesse assunzioni architetturali.
Quello schema mi ha spinto a pormi una domanda che credo l'industria della sicurezza non ponga abbastanza spesso:
Come appare un prodotto dopo una CVE? Non durante la corsa alla patch - diciotto mesi dopo, quando più nessuno guarda.
Ho deciso di scoprirlo. E il prodotto che ho scelto è stato Howyar SysReturn.
Ho contattato direttamente Howyar Technologies e ho ottenuto una copia di valutazione di SysReturn per una valutazione professionale di procurement - un contesto legittimo che è nato da lavoro reale di valutazione di software di ripristino per deployment educativi su larga scala.
Ciò che ho trovato in SysReturn v11.2.031, rilasciato in aprile 2026 - più di quindici mesi dopo la revoca di Microsoft - ha confermato esattamente ciò che lo schema aveva suggerito.
Il percorso di avvio x64 era stato sistemato. Ma il percorso di avvio IA-32 non era mai stato remediato. Il binario BOOTia32.efi, distribuito come parte della funzionalità SysReturn NetCopy, conteneva ancora lo stesso loader PE personalizzato (RxPE), caricava ancora payload non firmati da un file chiamato cloak32.dat usando lo stesso formato ALRM e la stessa cifratura XOR a chiave singolo byte, e portava ancora lo stesso identico hash Authenticode che Microsoft aveva revocato a gennaio 2025.
La causa principale non è mai stata corretta nell'architettura IA-32. Ciò che era cambiato era operativo - il percorso x64 era stato aggiornato, e la pressione immediata derivante dalla divulgazione era stata affrontata - ma l'architettura sottostante persisteva intatta nel componente a 32 bit, distribuito commercialmente in ogni copia del prodotto.
