Ich trage mal zwei Sicherheitsthemen nach, die sich auf die in aktuellen Systemen zu findenden UEFI-Implementierungen finden. Ende Juli 2024 wurde ein Sicherheitslücke mit dem Namen PKfail bekannt, die eine Umgehung des Secure Boot und die Installation von UEFI-Malware ermöglicht, weil geschlampt wurde. Und es gibt die Erkenntnis, dass fehlerhafte OEM-Firmware diese schöne TPM, auf das Microsoft setzt, schlicht ruiniert.
Anzeige
PKfail gefährdet hunderte Systeme
Secure Boot gilt als der heilige Gral der Plattformsicherheit unter Windows. Viele Sicherheitsfunktionen auf der Betriebssystemebene hängen von seiner Integrität ab. Sicherheitsforscher von Binarly sind auf Schlampereien bei UEFI-Implementierungen gestoßen, die das gesamte Konzept aushebeln und in Frage stellen.
Bereits 2023 entdeckte das Binarly REsearch Team einen gravierenden Sicherheitsvorfall in der Lieferkette. Damals wurden private Schlüssel für den Intel Boot Guard über den Intel Referenzcode verteilt. Das Problem betraf damals mehrere Hersteller, deren Produktiv-Systeme nicht mehr per Intel Boot Guard absicherbar waren (der Schlüssel war ja bekannt). Binarly hatte seinerzeit alle von dieser MSI/Insyde-Datenpanne betroffenen Gerätehersteller dokumentiert und entsprechende Hinweise zur frühzeitige Erkennung von ausgelaufenen Schlüsseln veröffentlicht.
Nun ist man auf die nächste Pleite in diesem Bereich gestoßen, wie man hier dokumentiert. Anfang 2024 haben die Binarly Sicherheitsforscher festgestellt, dass der private Schlüssel (Platform Key, PK) von American Megatrends International (AMI), der sich auf den Secure Boot Master Key bezieht, durch ein Datenleck öffentlich gemacht wurde. Der Vorfall ereignete sich bei einem ODM, der für die Firmware-Entwicklung für mehrere Gerätehersteller verantwortlich ist. Darunter befinden sich auch Hersteller von Unternehmensgeräten in den USA. Geräte mit diesem kompromittierten Platform Key (PK) sind immer noch im Einsatz, und der Schlüssel wird auch in kürzlich veröffentlichten Unternehmensgeräten verwendet.
Anzeige
Man hat diesen Vorfall mit PKfail benannt, weil dieser Vorfall gleich mehrere Sicherheitsprobleme im Zusammenhang mit der Sicherheit der Geräte-Lieferkette aufzeigt:
- Schlechtes Management von kryptografischem Material und Auftauchen der privaten Schlüssel direkt in den Code-Repositories mit dem hartkodierten Pfad aus den Build-Skripten.
- Verwendung von kryptografischen Schlüsseln, die nicht für die Produktion bestimmt sind und für die Plattformsicherheit der Produktionsfirmware und -geräte verantwortlich sind.
- Keine Rotation der kryptografischen Schlüssel für die Plattformsicherheit pro Produktlinie. Zum Beispiel wurden dieselben kryptografischen Schlüssel auf Client- und Server-Produkten bestätigt. Ein ähnliches Verhalten wurde bei Intel Boot Guard Referenzcode-Schlüssellecks festgestellt.
- Derselbe OEM verwendete dieselben plattformsicherheitsbezogenen kryptografischen Schlüssel für Firmware, die für verschiedene Gerätehersteller produziert wurde. Ein ähnliches Verhalten wurde bei Intel Boot Guard-Referenzcode-Schlüssellecks festgestellt.
Die hochgelobten Sicherheitstechnologien sind am Ende des Tages löchrig wie ein Schweizer Käse. Das Binarly-Team hat das ein kostenloses Scanning-Tool für die Hersteller entwickelt, um anfällige Geräte und System-Firmware-Updates sowie bösartige Nutzdaten zu erkennen.
Weitere Schwachstellen im Firmware
Binni Shah hat bereits Anfang Juni 2024 in nachfolgendem Tweet darauf hingewiesen, dass das gesamte TPM-Konzept durch Schwachstellen sehr wackelig ist. Fehlerhafte OEM-Firmware und Schwachstellen gefährden die Sicherheit von TPM.
Im Tweet auf X sind gleich mehrere Vorkommnisse verlinkt, bei denen die TPM-Sicherheit ausgehebelt wird. Ich habe bisher aber keine Informationen, ob diese Schwachstellen in konkreten Angriffen ausgenutzt werden.
Anzeige
Secure Boot dient hauptsächlich zur Absicherung gegen die Einflussnahme der Benutzer, was auf "ihrer" Hardware läuft und was nicht, sorum wird der Schuh draus.
TPM genauso… wer glaubt das das alles zum Schutz der User ist… ist schlicht gesagt naiv. Dazu musst du dir nur die Urspünge ansehen, woher das kommt und welche Firmen involviert sind/waren. Das geht schon weit in die 80iger zurück und musste ein Dutzendmal den Namen ändern weil es verbrannt war. Dann nach der zweiten PISA Blamage und als es klar wurde das die Folgegenerationen keine ausreichende Digitalbildung mehr haben, konnten sie es endlich durchbringen. Etwas Schwafeln von Schutz und so und die Leute bejubeln es… Tja der digitale DAU stellt eben die breite Masse. Hinzu kommt das die Daumenschrauben noch recht offen sind, aber das kommt noch.
Ich habe von Secure Boot noch nie was gehalten, zumindest nicht so wie es im Markt existiert. Es macht in der Regel mehr Ärger als es hilft, speziell auch, wenn man was anderes als Windows installieren will oder mit Multi-Boot arbeiten möchte. Und der Sicherheitsnutzen ist mMn auch zweifelhaft. Daher ist das mit das erste, was ausgeschaltet wird.
Dito.
TPM und "Secure Boot" ist an sich eine gute Idee, allerdings wenn man das wirklich richtig machen will, kommt man da nicht herum, dass alle Hersteller aufgeben ihre eigene Umsetzung zu bauen. Falls die das jemals richtig machen, landen wir hoffentlich bei CoreBoot oder ähnliches, mit angepassten Profilen für unterschiedliche Hardwarekonfigurationen. Im Kern aber ein System, dass sich im Grunde problemlos aktuell halten lässt, wie jedes OS. Dann kann man auch das Auditing zentralisieren.
Aber das bleibt ein Wunschtraum, wann haben alteingesessene, etablierte Hersteller schon mal freiwillig Macht abgegeben, ohne dass der Gesetzgeber vorher um die Ecke kommen musste….
In diesem Fall, müssten sich Nordamerika, EU und zumindest Teile der APAC einig sein….
Gut so.
Secure Boot und TPM ist eine pest… wie war der Spruch "Freiheit stirbt mit Sicherheit".
Secure boot und TPM dienen vorrangig dazu Systeme vor ihren Benutzern abzusichern damit sie zu sicheren DRM Platformed werden.