
Post-CVE-2024-7344-Analyse von Howyar SysReturn NetCopy - Reverse-Engineering-Notizen, verwundbare Binärdateien, Herstellerkorrespondenz und Proof-of-Concept-Tooling für CVE-2026-79298 (IA-32 Secure-Boot-Bypass über den benutzerdefinierten RxPE-PE-Loader in BOOTia32.efi).
Unter dem Mantel von Secure Boot sinken manche Architekturen tiefer als die Schwachstellen, die sie offengelegt haben. Manche Binärdateien werden widerrufen. Manche Patches werden ausgeliefert. Doch tief unter der Oberfläche hinterlassen alte Gewohnheiten Spuren. Das ist es, was zurückbleibt, wenn eine Schwachstelle offengelegt, gepatcht und vergessen wurde.
Die in diesem Repository dokumentierten Erkenntnisse wurden als CVE-2026-79298 zugewiesen.
Während des koordinierten Offenlegungsprozesses bestätigte der Hersteller, dass die mit CVE-2024-7344 verbundene Behebung nur den x64-Boot-Pfad adressierte. Der IA-32-Boot-Pfad - einschließlich BOOTia32.efi, das als Teil der SysReturn NetCopy-Funktion ausgeliefert wird - war nie in die ursprüngliche Behebung einbezogen. Infolgedessen wurde die anfällige IA-32-Komponente bis Version 11.3.034 (Juli 2026) weiterhin kommerziell vertrieben.
Das dedizierte CVE-Repository verlinkt hierher für die vollständige technische Tiefe: Reverse Engineering, Binäranalyse, Herstellerkorrespondenz, Reproduktionsartefakte und Proof-of-Concept-Tooling.
Das ganze Jahr 2026 über habe ich mich intensiv mit UEFI-Sicherheit beschäftigt - Bootkit-Entwicklung, Secure-Boot-Bypässe, Firmware-Exploitation, CVE-Analyse, Entwicklung offensiver Tooling, Veröffentlichung von Forschung. Es ist der Bereich, auf den ich mich spezialisiert habe, und jede Woche bringt etwas Neues. Ein Teil dieser Arbeit besteht darin, bekannte CVEs in UEFI-Komponenten auszunutzen. Ein Teil besteht darin, Software zu untersuchen, die UEFI-Bootloader ausliefert, aber wenig öffentliche Prüfung erfahren hat. Und ein Teil - der Teil, den dieses Repository dokumentiert - besteht darin, eine Frage zu stellen, die meiner Meinung nach zu oft übersehen wird:
Wie sieht ein Produkt nach einem CVE aus?
Nicht während des Patch-Ansturms. Nicht in der Woche, in der die Advisory erscheint. Achtzehn Monate später, wenn der Druck weg ist, wenn die Forscher weitergezogen sind, wenn niemand mehr hinschaut.
Dieses Repository ist mein Versuch, diese Frage für ein bestimmtes Produkt zu beantworten: Howyar SysReturn NetCopy.
Und ich denke, was ich gefunden habe, wird die Leute überraschen.
Alles in der Sicherheitsforschung hängt mit etwas anderem zusammen, wenn man den Fäden weit genug folgt. Dieser spezielle Faden begann bei der Arbeit. Wir wurden beauftragt, das reale Risiko von UEFI- und Bootkit-Angriffen gegen eine bestimmte Kategorie von Umgebungen zu analysieren: Bildungszentren. Es klingt nischig. Ist es nicht.
Hier ist die Realität, die die meisten Menschen außerhalb dieses Bereichs nicht vollständig würdigen. In einer mittelgroßen Stadt können leicht 70.000 oder mehr gemeinsam genutzte Geräte an Schulen im Einsatz sein - Laptops und Workstations, die von Schülern zwischen acht und fünfzehn Jahren genutzt werden und Linux-Distributionen ausführen, weil Windows-Lizenzierung in diesem Maßstab oft prohibitiv ist.
Fragen Sie sich nun: Wie viele dieser Maschinen haben Secure Boot ordnungsgemäß aktiviert? Die ehrliche Antwort ist an den meisten Orten: sehr wenige. Und der Grund ist nicht Nachlässigkeit. Es ist operative Realität.
Secure Boot in einer Linux-Umgebung ordnungsgemäß zu aktivieren bedeutet, jeden Kernel zu signieren. Jedes Kernel-Update - und Linux-Kernel-Schwachstellen kamen in den letzten Jahren schnell - erfordert ein neues signiertes Image, das auf jeder einzelnen Maschine bereitgestellt werden muss. Das bedeutet koordinierte Update-Pipelines, Schlüsselverwaltungsinfrastruktur, geschultes Personal und laufende Wartung über Tausende von Endpunkten, die über Dutzende von Standorten verteilt sind.
Für Organisationen mit diesen Ressourcen ist es machbar. Für die meisten Schulbezirke ist es das nicht. Es gibt einfach nicht genug Leute, nicht genug Budget und nicht genug Tooling, um es in diesem Maßstab richtig zu machen. Also bleibt Secure Boot deaktiviert.
BIOS-Passwörter werden nicht gesetzt - weil deren Rotation über 70.000 Maschinen mit begrenztem Personal unpraktisch ist. Und diese Maschinen stehen dort, vollständig exponiert auf Firmware-Ebene, und werden täglich von Hunderten von Schülern genutzt.
Was das aus Sicherheitsperspektive tatsächlich bedeutet, ist, dass ein Angreifer, der UEFI-Exploitation versteht, eine dieser Maschinen auf der Firmware-Ebene kompromittieren kann - bevor das Betriebssystem lädt, bevor irgendeine Sicherheitssoftware startet, bevor irgendein Schutzmechanismus eingreifen kann. Ein Bootkit kann über Neustarts hinweg, über Neuinstallationen des Betriebssystems hinweg, über alles hinweg persistent bleiben. Ich weiß das, weil ich solche Tooling selbst entwickle. Die Techniken existieren. Sie sind nicht theoretisch.
Das ist ein bekanntes Problem. Es ist weithin anerkannt. Und es wird nicht so schnell verschwinden.
Die operative Antwort auf dieses Problem - das, was Schulen tatsächlich anstelle von ordnungsgemäßem Secure Boot einsetzen - ist Wiederherstellungssoftware.
Die Idee ist unkompliziert: Was auch immer ein Schüler während einer Sitzung tut, alles kehrt nach dem nächsten Neustart in einen bekanntermaßen sauberen Zustand zurück. Malware, Konfigurationsänderungen, beschädigte Systemdateien, versehentlich oder absichtlich gelöschte Daten - weg. Das reduziert Wartungskosten drastisch und gibt Administratoren eine Möglichkeit, gemeinsam genutzte Maschinen zu verwalten, ohne perfekte Sicherheitskontrollen auf Firmware-Ebene auf jedem Gerät zu benötigen.
Als wir begannen zu evaluieren, welche Produkte in diesen Umgebungen verwendet wurden, kamen mehrere Namen auf. Einer davon war Howyar SysReturn - ein taiwanesisches Produkt, das speziell für Bildungseinsätze entwickelt wurde, mit expliziter Unterstützung für Schulcomputerlabore, gemeinsam genutzte Workstations und großflächig verwaltete Umgebungen.
In dem Moment, als ich diesen Namen sah, wusste ich genau, was ich tun wollte.