themalwareguardian/uefi-security-research-howyar-sysreturn-netcopyAnalisi post CVE-2024-7344 di Howyar SysReturn NetCopy - note di reverse engineering, binari vulnerabili, corrispondenza con il fornitore e tooling proof-of-concept per CVE-2026-79298 (bypass di Secure Boot IA-32 tramite il loader PE personalizzato RxPE in BOOTia32.efi).
Sotto il mantello del Secure Boot, alcune architetture affondano più in profondità delle vulnerabilità che le hanno esposte. Alcuni binari vengono revocati. Alcune patch vengono distribuite. Ma in profondità sotto la superficie, le vecchie abitudini lasciano tracce. Questo è ciò che rimane quando una vulnerabilità viene divulgata, corretta e dimenticata.
Le scoperte documentate in questo repository sono state assegnate a CVE-2026-79298.
Durante il processo di divulgazione coordinata, il fornitore ha confermato che la correzione associata a CVE-2024-7344 riguardava solo il percorso di avvio x64. Il percorso di avvio IA-32 - incluso BOOTia32.efi distribuito come parte della funzionalità SysReturn NetCopy - non è mai stato incluso nella correzione originale. Di conseguenza, il componente IA-32 vulnerabile ha continuato a essere distribuito commercialmente fino alla versione 11.3.034 (luglio 2026).
Il repository dedicato alla CVE rimanda qui per la completa profondità tecnica: reverse engineering, analisi binaria, corrispondenza con il fornitore, artefatti di riproduzione e strumenti proof-of-concept.
Nel corso del 2026 mi sono dedicato a fondo alla sicurezza UEFI - sviluppo di bootkit, bypass del Secure Boot, sfruttamento del firmware, analisi di CVE, sviluppo di strumenti offensivi, pubblicazione di ricerche. È l'area in cui ho scelto di specializzarmi e ogni settimana porta qualcosa di nuovo. Parte di questo lavoro consiste nello sfruttare CVE note nei componenti UEFI. Parte consiste nel ricercare software che distribuisce bootloader UEFI ma ha ricevuto scarsa attenzione pubblica. E parte - la parte che questo repository documenta - consiste nel porsi una domanda che ritengo venga troppo spesso trascurata:
Come appare un prodotto dopo una CVE?
Non durante la corsa alle patch. Non nella settimana in cui viene pubblicato l'avviso. Diciotto mesi dopo, quando la pressione è svanita, quando i ricercatori sono passati oltre, quando nessuno sta più guardando.
Questo repository è il mio tentativo di rispondere a quella domanda per uno specifico prodotto: Howyar SysReturn NetCopy.
E credo che ciò che ho trovato sorprenderà le persone.
Tutto nella ricerca sulla sicurezza si collega a qualcos'altro se si seguono i fili abbastanza a lungo. Questo particolare filo è iniziato al lavoro. Ci è stato affidato il compito di analizzare il rischio reale degli attacchi UEFI e bootkit contro una specifica categoria di ambienti: i centri educativi. Sembra di nicchia. Non lo è.
Ecco la realtà che la maggior parte delle persone al di fuori di questo campo non comprende appieno. In una città di medie dimensioni, possono esserci facilmente 70.000 o più dispositivi condivisi distribuiti nelle scuole - laptop e workstation utilizzati da studenti tra gli otto e i quindici anni, che eseguono distribuzioni Linux perché le licenze Windows su quella scala sono spesso proibitive.
Ora chiedetevi: quante di quelle macchine hanno il Secure Boot correttamente abilitato? La risposta onesta, nella maggior parte dei luoghi, è molto poche. E il motivo non è la negligenza. È la realtà operativa.
Abilitare correttamente il Secure Boot in un ambiente Linux significa firmare ogni kernel. Ogni aggiornamento del kernel - e le vulnerabilità del kernel Linux sono arrivate rapidamente negli ultimi anni - richiede una nuova immagine firmata da distribuire su ogni singola macchina. Ciò significa pipeline di aggiornamento coordinate, infrastruttura di gestione delle chiavi, personale formato e manutenzione continua su migliaia di endpoint distribuiti in dozzine di sedi.
Per le organizzazioni con queste risorse, è gestibile. Per la maggior parte dei distretti scolastici, non lo è. Semplicemente non ci sono abbastanza persone, abbastanza budget e abbastanza strumenti per farlo correttamente su quella scala. Quindi il Secure Boot rimane disabilitato.
Le password del BIOS non vengono impostate - perché ruotarle su 70.000 macchine con personale limitato è impraticabile. E quelle macchine restano lì, completamente esposte a livello di firmware, utilizzate da centinaia di studenti ogni giorno.
Ciò che questo significa realmente, da una prospettiva di sicurezza, è che un attaccante che comprende lo sfruttamento UEFI può compromettere una di quelle macchine a livello di firmware - prima che il sistema operativo si carichi, prima che qualsiasi software di sicurezza si avvii, prima che qualsiasi meccanismo di protezione abbia la possibilità di intervenire. Un bootkit può persistere attraverso i riavvii, attraverso le reinstallazioni del sistema operativo, attraverso tutto. Lo so perché sviluppo io stesso quel tipo di strumenti. Le tecniche esistono. Non sono teoriche.
Questo è un problema noto. È ampiamente riconosciuto. E non scomparirà presto.
La risposta operativa a quel problema - ciò che le scuole effettivamente distribuiscono invece di un Secure Boot adeguato - è il software di ripristino.
L'idea è semplice: qualunque cosa faccia uno studente durante una sessione, tutto ritorna a uno stato noto e pulito dopo il riavvio successivo. Malware, modifiche alla configurazione, file di sistema danneggiati, dati eliminati accidentalmente o intenzionalmente - spariti. Questo riduce drasticamente i costi di manutenzione e offre agli amministratori un modo per gestire macchine condivise senza dover avere controlli di sicurezza perfetti a livello di firmware su ogni dispositivo.
Quando abbiamo iniziato a valutare quali prodotti venivano utilizzati in questi ambienti, sono emersi diversi nomi. Uno di questi era Howyar SysReturn - un prodotto taiwanese progettato specificamente per distribuzioni educative, con supporto esplicito per laboratori informatici scolastici, workstation condivise e ambienti gestiti su larga scala.
Nel momento in cui ho visto quel nome, sapevo esattamente cosa volevo fare.
Nel gennaio 2025, ESET Research ha pubblicato la divulgazione di CVE-2024-7344 - un bypass del Secure Boot che interessa SysReturn e diversi altri prodotti di ripristino basati sullo stesso codebase.
La vulnerabilità era elegante in modo profondamente frustrante. Un'applicazione UEFI firmata da Microsoft - considerata attendibile dal firmware, in grado di essere eseguita anche con il Secure Boot abilitato - implementava il proprio loader PE personalizzato interamente da zero. Invece di utilizzare le funzioni standard UEFI LoadImage e StartImage, che applicano la verifica della firma Secure Boot, analizzava ed eseguiva manualmente i binari EFI da un file chiamato cloak.dat. Cifrato con XOR con una chiave a singolo byte. Nessun controllo della firma. Qualunque cosa fosse contenuta in quel file veniva eseguita con piena attendibilità a livello di firmware.
Microsoft ha revocato i binari vulnerabili nell'aggiornamento di Patch Tuesday di gennaio 2025. L'industria della sicurezza è passata alla cosa successiva. Ma io ho continuato a pensarci.
Non perché la vulnerabilità stessa fosse irrisolta - ESET l'ha documentata accuratamente e la revoca era chiara. Ciò che continuava a tormentarmi era una domanda diversa. Il tipo di domanda che diventa possibile rispondere solo con il tempo:
L'hanno effettivamente corretta? O hanno semplicemente aggirato la pressione?
C'è una differenza. Una vera correzione affronta la causa principale - in questo caso, l'uso di un loader PE personalizzato che aggira il Secure Boot. Una soluzione tampone fa sparire il problema immediato lasciando intatta l'architettura sottostante.
Volevo sapere quale delle due avesse fatto Howyar.
Ho contattato direttamente Howyar Technologies e ho richiesto una copia di valutazione di SysReturn per una valutazione professionale di approvvigionamento - il che, dato il contesto professionale che ha originato questa ricerca, era del tutto accurato.
Il fornitore è stato disponibile e reattivo. Hanno fornito una licenza di prova completa, manuali, video tutorial e un pacchetto di valutazione completo. Hanno anche risposto a domande dettagliate sulla compatibilità con il Secure Boot, che si sono rivelate direttamente rilevanti per ciò che ho scoperto in seguito.
Tutta quella corrispondenza è inclusa in questo repository, senza modifiche.
Non ho intenzione di rovinare i dettagli tecnici qui - è a questo che serve la directory Vulnerability Research, e consiglio sinceramente di leggerla per intero. Ma dirò questo.
L'UEFI è un mondo a sé. Gli sviluppatori che ci lavorano sono pochi. I processi di revisione della sicurezza che esistono per il software applicativo o i servizi web non raggiungono abitualmente i componenti del firmware. Le cattive pratiche, una volta stabilite, tendono a persistere - non per malizia, ma perché l'ecosistema è piccolo, lo scrutinio è raro e le conseguenze di sbagliare sono spesso invisibili a tutti tranne che alla manciata di ricercatori che prestano attenzione.
Ciò che ho trovato in SysReturn v11.2.031 - rilasciato in aprile 2026, più di quindici mesi dopo la revoca di Microsoft - è un chiaro esempio esattamente di quella dinamica.
La causa principale non è stata corretta. Il binario vulnerabile non è stato sostituito. Ciò che è cambiato è stato operativo: un percorso di avvio diverso per i sistemi con Secure Boot abilitato, lasciando quasi tutto il resto intatto.
Il loader PE personalizzato - il componente RxPE, nominato nelle stesse stringhe di debug del binario - è presente nella versione di aprile 2026, funzionando in modo identico a come funzionava nella versione analizzata da ESET nel 2024.
L'hash Authenticode del binario distribuito da Howyar nell'aprile 2026 corrisponde, byte per byte, all'hash che Microsoft ha revocato nel gennaio 2025.
Penso che questo sia importante. Penso che le persone dovrebbero saperlo. E penso che la documentazione tecnica in questo repository sia sufficientemente dettagliata affinché chiunque voglia verificare personalmente queste scoperte possa farlo.
| Directory | Descrizione |
|---|---|
📚 00 Manual | Manuali del fornitore, brochure e documentazione ufficiale del prodotto fornita da Howyar |
📦 01 Binaries | Binari chiave estratti dal pacchetto di valutazione per l'analisi |
📬 02 Disclosure | Corrispondenza email completa con Howyar Technologies durante il processo di valutazione |
🔬 03 Vulnerability Research | Reverse engineering, analisi binaria, verifica Authenticode, analisi del formato ALRM, script e scoperte tecniche |
La storia tecnica - il reverse engineering completo di BOOTia32.efi, il formato del payload ALRM, la decifratura XOR, il loader PE personalizzato RxPE, la corrispondenza dell'hash Authenticode con il binario revocato e l'analisi di ciò che Howyar ha effettivamente cambiato rispetto a ciò che ha lasciato intatto - è tutta in:
Se volete un contesto sulla CVE stessa prima di immergervi nell'analisi post-"patch", l'avviso di ESET è un buon riferimento. Mantengo anche un repository che documenta CVE-2024-7344 e le vulnerabilità UEFI correlate in modo più dettagliato.
Iniziate a leggere. Il mantello è ancora lì.
