Trotz eines Rückgangs der Gesamtverkäufe von Computern ist dies ein erstaunlicher Im Jahr 2022 wurden 286,2 Millionen Windows-basierte PCs verkauft. Jeder dieser Computer wurde mit einer darauf basierenden Firmware veröffentlicht Einheitliche erweiterbare Firmware-Schnittstelle (UEFI), eine Alternative zum Erbe Grundlegendes Eingabe-/Ausgabesystem (BIOS), das eine erweiterbare Schnittstelle zwischen Hardware und dem Betriebssystem selbst bietet. Der UEFI-Standard identifiziert auch zuverlässige Möglichkeiten, diese Firmware über das Betriebssystem zu aktualisieren. Trotz ihrer allgegenwärtigen und unverzichtbaren Rolle bleibt diese Software für die meisten Benutzer unsichtbar. Die Angreifer haben es jedoch nicht vergessen.
Der Angriff synchronisiert Schwarzer Lotus zuerst ausgesetzt a Bootkit (fortgeschrittene Form bösartiger Software), die nicht einfach erkannt oder entfernt werden kann. Viele Anbieter, darunter auch Microsoft, stecken mit diesem Bootkit immer noch in einer Sackgasse, da sie nicht in der Lage sind, es zuverlässig zu erkennen oder selbst die heutigen, vollständig gepatchten Maschinen vor dieser Art von Angriff zu schützen. Im Anschluss an diesen Angriff bald noch eins Daraufhin ging es um den Verlust sensibler Informationen, etwa privater Schlüssel mehrerer PC-Hersteller. Diese privaten Schlüssel, die normalerweise zum kryptografischen Signieren von UEFI-basierter Software verwendet werden, könnten möglicherweise zur Erstellung schädlicher Software verwendet werden, die sehr hochprivilegierten Zugriff auf die CPU erhalten kann. Die Bootkits schleusen Schadcode in die Software ein, die für den normalen Betrieb dieser Geräte sowohl unerlässlich als auch äußerst vertrauenswürdig ist.
In diesem Blogbeitrag, den ich aus meinem letzten übernommen habe weißes Papier, werde ich näher auf die durch diese Angriffe ans Licht gebrachten Bedenken eingehen und unsere Empfehlungen zur Sicherung des UEFI-Ökosystems und zur Wiederherstellung des Vertrauens in diese Firmware hervorheben. Diese Empfehlungen werden sowohl das Bewusstsein schärfen als auch dazu beitragen, künftige Bemühungen zur Schaffung einer sichereren Computerumgebung zu steuern.
Doppeltes Problem: Baton Drop und Alder Lake
Im Oktober 2022, Kaspersky und SecurityWeek bekam früh Wind vom BlackLotus-Angriff, der UEFI zur Erstellung von Bootkits nutzte. In diesem frühen Stadium betrachteten viele Kritiker, mich eingeschlossen, diese (Gerüchte) zunächst als unbestätigte Konten ohne ausreichende Beweise, um sie als Bedrohung für UEFI-basierte Firmware einzustufen. Jedoch, ESET Später lieferte er eine ausführliche Erklärung des Angriffs und seiner Auswirkungen. Dann wurde im selben Monat der Quellcode des Intel Alder Lake-Prozessors durchgesickert, der einige Schlüssel der BootGuard-Plattform von Intel enthielt. Diese Angriffe offenbarten einige der Herausforderungen des transitiven Vertrauens, das wir von digital signierter Software haben. Schauen wir uns diese Angriffe genauer an.
Den Staffelstab fallen lassen
Im Januar 2022 veröffentlichte Microsoft eine Sicherheitslücke CVE-2022-21894, das später Baton Drop genannt wurde. Die Sicherheitslücke entstand durch die von Microsoft signierte Bootloader-Software, eine kleine Software, die dem Betriebssystem hilft, Daten während des Startvorgangs zu laden. Der Bootloader erlaubte eine Speicherkürzung, die missbraucht werden konnte, um den sicheren Start der UEFI-Funktion zu umgehen. Dieser Exploit zerstörte eines der wichtigen Glieder in der Vertrauenskette, die von den frühen Startphasen zum Betriebssystem übergeht. Dem anfälligen Bootloader sollte idealerweise nicht mehr vertraut werden. Bei mehreren Implementierungen war dieser Teil des Bootloaders jedoch für den Startvorgang unerlässlich, sodass ein Austausch oder eine Entfernung unpraktisch war.
Um das Problem noch zu verschlimmern, wurde für Baton Drop eine Proof-of-Concept-Angriffssoftware bereitgestellt GitHub-Repository. Microsoft hatte keine Möglichkeit, diese signierte Software zu blockieren, ohne funktionsfähige Maschinen zu gefährden, die vom anfälligen Bootloader abhängig waren. Mit einem öffentlich zugänglichen Exploit musste Microsoft versuchen, die Verwendung dieses anfälligen Bootloaders mithilfe von UEFIs zu blockieren Verbotene Liste. Dieser Ansatz erwies sich als schwierig, da sich die betrieblichen Auswirkungen der Blockierung mehrerer Versionen anfälliger Bootloader auf viele derzeit funktionsfähige Geräte wie Laptops, Desktops und sogar Server der Unternehmensklasse auswirken.
Dieses Ereignis hinterließ eine Lücke, die von Angreifern nicht unbemerkt blieb. Mit dem BlackLotus-Bootkit nutzten sie bald die Schwachstelle aus und nutzten Microsofts eigenes vertrauenswürdiges Repository, um anfällige signierte Software herunterzuladen. Anschließend entwickelten sie eine Reihe von Angriffen, um die vertrauenswürdige Softwarevalidierung zu untergraben. Ein residentes Bootkit könnte dann verwendet werden, um die Sicherheitskette des Vertrauens zu umgehen und beliebige Software auszuführen.
Ein privater Schlüssel wird gestohlen, was nun?
Das Durchsickern des Alder-Lake-CPU-Quellcodes enthüllte einige private Schlüssel, die zum digitalen Signieren von Software als vertrauenswürdig verwendet wurden. Im Repository vorhandene private Schlüssel, die zum Debuggen und für bestimmte Aufgaben verwendet werden können, sind nun verfügbar. Im April 2023 wurde berichtet, dass der PC-Anbieter Micro-Star International (MSI), im Zuge eines Ransomware-AngriffsIhr Quellcode wurde durchgesickert und ihr Netzwerk wurde verletzt, wodurch der wertvollen Sammlung des Angreifers noch mehr private Schlüssel hinzugefügt wurden. Es war nun möglich, einige dieser privaten Schlüssel zu verwenden und signierte Schadsoftware zu erstellen, die Zugriff auf einen sehr hochprivilegierten Modus der CPU hätte.
Die Lösung für einen solchen gestohlenen Schlüssel im UEFI-Standard ähnelte seltsamerweise dem früheren Fall des anfälligen Bootloaders: Fügen Sie ihn dem UEFI hinzu Widerrufsliste, wodurch die gesamte Software des kompromittierten Anbieters blockiert wird. Das Hinzufügen eines privaten Schlüssels zu einer Sperrliste hat jedoch vielfältige Auswirkungen, einschließlich der potenziellen Deaktivierung eines funktionierenden oder kritischen Hardwaremoduls oder -geräts, das von dem verbotenen Anbieter stammt. Diese Blockierung könnte möglicherweise Auswirkungen auf jeden Computer haben, der in der Lieferkette mit dem verbotenen Anbieter in Verbindung steht. In der Praxis ist es nicht einfach, viele der heutigen Computer zu prüfen, denen eine Materialliste fehlt, um solche Anbieter und ihre Komponenten zu identifizieren.
Ein verlockendes Software-Dilemma
Der UEFI-Standard hat Schutzmaßnahmen gegen Bedrohungen durch gestohlene private Schlüssel entwickelt, die das Vertrauen in UEFI-basierte Firmware untergraben können. Allerdings wurden diese Abwehrmaßnahmen nun in realen Herausforderungen getestet, um Windows-PCs vor Angriffen zu schützen. Lassen Sie mich kurz auf zwei Hauptprobleme eingehen, die die Komplexität dieser Abwehrmaßnahmen verdeutlichen.
UEFIs Widerrufsliste kann mehrere Einträge verschiedener Art enthalten, z. B. verbotene Software, verbotener Signaturschlüssel und verbotenes Gerät. Allerdings kann für den Computer essentielle Software, wie z. B. Bootloader, nicht blockiert werden, bis jede Instanz ersetzt wurde. Je weiter verbreitet die Software ist, beispielsweise bei großen Betriebssystem- oder Hardwareanbietern, desto schwieriger ist es, sie zu ersetzen.
Auch bei der Widerrufsliste geht es um alles oder nichts. Es gibt keine Revisionsnummer oder Version der Sperrliste und es gibt keine Möglichkeit, sie anzupassen. In fast allen Implementierungen gibt es keine Möglichkeit, die Sperrliste mithilfe des Netzwerks oder auf andere Weise dynamisch zu überprüfen, um eine Software selektiv zu deaktivieren. Dieser Mangel an Anpassung führt dazu, dass IT-Manager lange Zeit zögern werden, von einem großen Anbieter signierte Software zur Sperrliste hinzuzufügen. Erschwerend kommt hinzu, dass die Sperrliste aufgrund des geringen verfügbaren Speicherplatzes im nichtflüchtigen Firmware-Speicher namens PCI Flash auch in ihrer Größe begrenzt ist. Diese Einschränkung macht es schwierig, diese Liste weiter zu erweitern, da signierte Software als anfällig oder riskant gilt.
Das Hinzufügen der öffentlichen Schlüsselinformationen eines Anbieters zur Sperrliste hat mehrere Konsequenzen. Es ist geschätzt dass jeder Originalgerätehersteller (OEM), der einen Computer verkauft, die direkte Kontrolle über weniger als 10 Prozent der BIOS-Software hat. Computer werden aus Teilen mehrerer Lieferanten zusammengebaut, die in manchen Fällen ihre Teile von mehreren Lieferanten zusammenbauen. Dies gilt auch für den Lieferkettenbaum, der immer komplexer wird, je mehr unsere Weltwirtschaft den niedrigsten Preis für diese Geräte findet. Es ist schwierig, einen Anbieter vollständig zur Sperrliste hinzuzufügen, ohne bestimmte Teile des Computers zu beeinträchtigen, die möglicherweise unbrauchbar oder unzuverlässig werden könnten. Wenn ein solcher Anbieter kritische Komponenten wie Netzwerkkomponenten bereitgestellt hat, kann dies dazu führen, dass das Gerät ohne physischen Zugriff und Wiederzusammenbau unbrauchbar und unbrauchbar wird. Schließlich stehen die Systembesitzer nun vor der Herausforderung, die Sperrliste zu verwalten und auf eine Kompromittierung eines internationalen Lieferanten zu reagieren.
UEFI aufgeben oder neu erstellen?
Was ist also eigentlich bei UEFI schief gelaufen? Haben die Experten, die den UEFI-Standard erstellt und aktualisiert haben, dies nicht erwartet? Offensichtlich sind die Bedrohungen für UEFI in mancher Hinsicht größer, als der UEFI-Standard allein bewältigen kann. Glücklicherweise gibt es verschiedene Bemühungen, das UEFI-Firmware-Ökosystem zu sichern. Die wahrscheinlich aussagekräftigste Quelle für Anleitungen zu UEFI finden Sie im NIST Richtlinien zur Ausfallsicherheit der Plattform-Firmware (SP 800-193). Während es schwierig ist, die nächste Bedrohung und die Ziele des Gegners vorherzusagen, müssen die Partner des UEFI-Ökosystems lediglich die bekannten Unbekannten in der UEFI-Firmware beheben.
5 Empfehlungen zur Sicherung des UEFI-Ökosystems
Im Folgenden beschreibe ich fünf Empfehlungen für das UEFI-Ökosystem zur Risikominderung und Abwehr der in diesem Beitrag beschriebenen Bedrohungen. Ein kürzlich weißes Papier stellt diese Empfehlungen detaillierter vor. Diese Arbeit knüpft auch an unseren früheren Einführungsblog zu UEFI an, in dem wir einige unserer frühen Bedenken zu diesem Thema festgehalten haben.
- Bauen Sie ein robustes Verifizierungs- und Attestierungsökosystem auf. Die aktuelle Firmware-Überprüfung und Bescheinigung sollte mit neueren Technologien wie dynamischer Verifizierung und Fernbescheinigung verbessert werden, um sicherzustellen, dass die Softwarevalidierung weit genug fortgeschritten ist, um neuen Bedrohungen für UEFI standzuhalten.
- Verbessern Sie die Speichersicherheit von kritischem UEFI-Code. Die Speichersicherheit ist bei Low-Level-Softwareteilen, die direkt mit der Hardware interagieren, von entscheidender Bedeutung. Im Gegensatz zur Software auf Anwendungsebene gibt es in der Firmware keine Kompensationskontrollen für Speicherfehler, die ein Risiko für das Gerät darstellen. Es ist von entscheidender Bedeutung, dass der UEFI-Community, an der alle Mitglieder beteiligt sind, sichere Codierungspraktiken und Tools zum Erstellen speichersicherer Firmware-Komponenten jederzeit zur Verfügung stehen UEFI-Forumeinschließlich nicht stimmberechtigter Mitglieder.
- Wenden Sie die geringste Berechtigung und Komponentenisolation für UEFI-Code an. Vieles von dem, was wir in den schmerzhaften Anfangsjahren anfälliger Software aus der Softwareentwicklung gelernt haben, scheint nicht auf die UEFI-Entwicklung übergegangen zu sein. Die Komponentenisolation und das Prinzip der geringsten Rechte sollten angewendet werden, sodass UEFI-Software keinen ungebundenen Zugriff hat und wie jede andere Software behandelt wird.
- Nutzen Sie die Transparenz und Überprüfung von Firmware-Komponenten. A Software-Stückliste (SBOM) ist ein entscheidender Teil der zuverlässigen Identifizierung von Softwarekomponenten und -quellen, sodass die UEFI-Firmware auch in dieser komplexen, vernetzten Lieferkette von Anbietern von der dringend benötigten Klarheit profitiert.
- Entwickeln Sie robustes und nicht aufdringliches Patching. UEFI-Softwareaktualisierungen und -Patches sind umständlich und variieren stark zwischen den Implementierungen der Anbieter. Der Prozess ist für Benutzer und IT-Systemadministratoren aufwändig und schränkt ihre Fähigkeit ein, diese Systeme routinemäßig zu patchen, zu aktualisieren und zu warten. Standardbasierte Updates sollen mit möglichst geringem Eingriff in den Nutzer möglich sein.
Die Sicherung von UEFI geht jeden etwas an
Der UEFI-Standard wird bestehen bleiben und es wird erwartet, dass seine Nutzung und Akzeptanz weiter zunimmt. Daher ist es für die vielen Anbieter und Interessengruppen, die UEFI-basierte Software entwickeln und erstellen, wichtig, diese Herausforderungen aktiv anzunehmen und gemeinsam darauf zu reagieren. Systembesitzer und -betreiber werden ebenfalls aufgefordert, sich über diese Herausforderungen zu informieren und von ihren Lieferanten zu erwarten, dass sie UEFI vor Angriffen schützen. Obwohl wir nicht wissen, wie sich die Bedrohungslandschaft entwickeln wird, wissen wir um die Lücken und Bedrohungsmotive, die hier hervorgehoben wurden. Es ist unbedingt erforderlich, dass sich die größere PC-Community an Bemühungen beteiligt, um die mit der Verwendung von UEFI verbundenen Risiken kontinuierlich zu reduzieren und Unsicherheiten zu beseitigen.
