Kürzlich hat Microsoft endlich die seit 2013 im System lauernde Secure Boot (Secure Boot)-Bypass-Schwachstelle behoben. Sicherheitsforscher wiesen darauf hin, dass das durch diesen Vorfall aufgedeckte Kernproblem nicht die Schwachstelle selbst, sondern die alten Komponenten mit digitalen Signaturen, aber das Fehlen eines effektiven Tracking-Managements seien.
Diese seit langem bestehende Sicherheitslücke ist auf ein einfaches Verwaltungsversehen zurückzuführen: Veraltete Komponenten wurden nie offiziell widerrufen. Forscher des bekannten Sicherheitsanbieters ESET haben herausgefunden, dass eine Reihe anfälliger UEFI-„Shim“-Bootloader, von denen einige aus dem Jahr 2013 stammen, von Microsoft-Systemen auch Jahre nach Bekanntwerden der Schwachstellen immer noch als vertrauenswürdige Komponenten angesehen werden. Dies bedeutet, dass Angreifer den sicheren Startmechanismus auf Windows- und Linux-Geräten mühelos umgehen können. Es wird berichtet, dass das Problem insgesamt 11 Shim-Binärdateien betrifft, die noch gültige Signaturen enthalten und von Systemen akzeptiert werden, die einen sicheren Start durchführen. Da es sich bei der Signatur um die Schlüsselanmeldeinformationen handelt, die die Ausführung von Code während des Startvorgangs ermöglichen, sind alle nachfolgenden Startschritte betroffen, sobald die vertrauenswürdige Komponente gefährdet ist.
ESET-Forscher Martin Smolár betonte: „Die Gefahr dieser älteren Versionen von Shims besteht nicht darin, dass sie neue Schwachstellen nutzen, sondern darin, dass keine neuen Schwachstellen erforderlich sind, um UEFI Secure Boot zu umgehen. Angreifer benötigen keine ausgefeilten Exploits, solange sie über eine alte, aber immer noch vertrauenswürdige und nicht widerrufene Kopie der Shim-Binärdatei verfügen und über grundlegende Kenntnisse über die Funktionsweise des UEFI-Shims verfügen, reicht es aus, diese wichtige Sicherheitslinie zu umgehen.“ In tatsächlichen Angriffsszenarien können Hacker diese Shims nutzen, um schädliche Firmware zu laden, bevor das Betriebssystem startet. Diese Art von Malware ist extrem versteckt und hartnäckig und es ist schwierig, sie vollständig zu entfernen, selbst wenn Sie das Betriebssystem neu installieren oder sogar Hardwaregeräte wie Festplatten austauschen.
Der Secure-Boot-Mechanismus wurde erstmals im Jahr 2012 eingeführt und hatte ursprünglich die Absicht, solche Low-Level-Angriffe zu verhindern. Dieser Mechanismus erfordert, dass jeder Code in der Startkette von einer vertrauenswürdigen Autorität digital signiert werden muss. Microsoft fungiert als Vertrauensbasis für das System und ist für die Signatur seines eigenen Bootloaders und der Shims verantwortlich, die von anderer Software wie Linux verwendet werden. Tatsächlich handelt es sich bei Shim um einen Kompromiss, der die normale Ausführung von Nicht-Microsoft-Software in einer sicheren Startumgebung ermöglicht. Sobald Microsoft eine Signatur für einen Shim bereitstellt, kann der Shim sein eingebettetes Zertifikat verwenden, um nachfolgende Komponenten zu genehmigen.
Voraussetzung dafür, dass dieser Mechanismus effektiv funktioniert, ist jedoch, dass, sobald festgestellt wird, dass ein Shim eine Schwachstelle aufweist, dieser sofort widerrufen werden muss. Doch bei diesem Vorfall versagte dieser Blockiermechanismus völlig. Betroffene Shims stammen aus einer Vielzahl von Quellen, darunter Linux-Distributoren wie Red Hat, openSUSE und Oracle sowie einige Tools von Drittanbietern. Einige dieser Komponenten existierten bereits vor der Einführung neuer Schutzmechanismen wie SBAT- und MOK-Verweigerungslisten. andere enthielten selbst Codefehler oder ermöglichten das Laden von Komponenten mit bekannten Schwachstellen. ESET hat ausdrücklich auf einen Oracle-Shim hingewiesen, der die Ausführung von Binärdateien mit der Schwachstelle CVE-2015-5381 ermöglicht, und die technische Schwelle für die Ausnutzung der Schwachstelle ist recht niedrig.
Ein weiterer Teil des Problems ist die zunehmende Komplexität sicherer Boot-Mechanismen. Das System stützt sich derzeit auf mehrere Ebenen, um zu bestimmen, welcher Code ausgeführt werden kann, einschließlich einer Datenbank mit vertrauenswürdigen Signaturen, Sperrlisten und neuen versionbasierten Mechanismen wie SBAT. Jeder Link erfordert präzise Updates und Wartung. Wie Smolár erklärt, ist dbx für das Widerrufen bestimmter Binärdateien verantwortlich, während SBAT und Microsofts Secure Boot SVN für das Widerrufen bestimmter Versionen verantwortlich sind. Jede Startkomponente enthält Metadaten mit einer Versionsnummer, und das System soll jede Komponente abfangen, die unter einen festgelegten Schwellenwert fällt. Dies hängt jedoch vollständig von der rechtzeitigen Aktualisierung der Schwellenwertdaten ab. Es ist erwähnenswert, dass das zum Signieren dieser Shims verwendete Microsoft-Zertifikat selbst dann nicht automatisch an deren Ausführung gehindert wird, wenn es abläuft, was die Abhängigkeit des gesamten Systems vom aktiven Widerruf und nicht von integrierten Ablauffehlermechanismen deutlich macht.
Derzeit sind Windows-Systeme, auf denen die neuesten Updates installiert sind, nicht mehr von dieser Schwachstelle bedroht; Für Linux-Benutzer empfehlen Experten, sich beim entsprechenden Vertriebsmitarbeiter zu erkundigen oder Tools wie fwupd zu verwenden, um zu bestätigen, ob das System geschützt wurde.
Was jedoch in der Branche tiefere Bedenken hervorruft, ist der fragile Status dieses Vertrauenssystems. Die Verwaltung von Vertrauensbeziehungen über zahlreiche Komponenten, Anbieter und häufige Updates hinweg hat sich als äußerst schwierige Aufgabe erwiesen. HD Moore, CEO und Gründer von runZero, sagte in einem Interview unverblümt: „Das ist eine heftige Kritik am gesamten Secure-Boot-Modell.“ Er wies darauf hin, dass es zu viele signierte Komponenten gebe, denen es an effektiver Nachverfolgung fehle und die dennoch für unbeabsichtigte und gefährliche Zwecke verwendet werden könnten. Moore kam zu dem Schluss: „Das Endergebnis ist, dass es eine große Anzahl signierter Komponenten gibt (die niemand außer Microsoft kennt), die Secure Boot umgehen können – einige davon werden zum Booten anderer Programme verwendet, und sie weisen auch allgemeine Sicherheitslücken und andere Fehler auf, was bedeutet, dass sie zum Booten fast aller Dinge verwendet werden können. Das gesamte Ökosystem ist in gewissem Maße kaputt und bedarf eines kompletten Neustarts.“