Sicherheitsforscher von Binarly haben die Möglichkeit entdeckt, den UEFI Secure Boot-Modus auf über 800 Produkten zu umgehen, die von Unternehmen wie Acer, Dell, Fujitsu, Gigabyte, HP, Intel, Lenovo und Supermicro hergestellt wurden. Das Problem trägt den Code-Namen PKfail und hängt mit der Verwendung eines nicht vertrauenswürdigen Plattformschlüssels (PK, Platform Key) in der Firmware zusammen, der von AMI (American Megatrends International) generiert und als Testbeispiel geliefert wurde. Die ältesten Firmware-Versionen, die diesen Testschlüssel verwendeten, stammen aus dem Jahr 2012, während die neueste von Juni 2024 datiert ist. Laut den Forschern sind über 10 % aller überprüften Firmware-Versionen betroffen.
In den Schlüsselparametern war vermerkt, dass er nicht vertrauenswürdig ist und nicht in Produkten verwendet werden sollte. Es wurde angenommen, dass dieser Testschlüssel durch einen eigenen ersetzt werden sollte, jedoch ignorierten die Hersteller die Warnung und verwendeten in den finalen Firmwares einen generischen Schlüssel, der an alle Partner und Kunden von AMI gesendet wurde.
Ein geheimer Teil des AMI-Testschlüssels, der für die Erstellung digitaler Signaturen erforderlich ist, wurde nach einem Informationsleck bei einem der Hardwarehersteller öffentlich zugänglich. Ein Mitarbeiter hatte versehentlich den Code, der diesen Schlüssel enthielt, in einem öffentlichen Repository auf GitHub veröffentlicht. Der geheime Schlüssel war in einer verschlüsselten Datei gespeichert, wobei ein einfacher 4-stelliger Passwort verwendet wurde, der leicht durch Brute-Force-Methoden erraten werden konnte.
Der Plattform-Schlüssel dient als Wurzel des Vertrauens zur Verifizierung von Datenbanken mit Schlüsseln für den Secure Boot. Das Erlangen des geheimen Teils des Plattform-Schlüssels führt zur Kompromittierung der gesamten Vertrauenskette, die bei der Validierung von Komponenten des Betriebssystems eine Rolle spielt. Wenn der Plattform-Schlüssel bekannt ist, kann der Schutz von Secure Boot umgangen werden, was es ermöglicht, beim Booten eigene Komponenten durch Manipulation des KEK (Key Exchange Key) und der Datenbanken "db" (Signature Database) sowie "dbx" (Forbidden Signature Database) einzuschleusen. Der KEK sorgt für die Erstellung einer Vertrauenskette zwischen der Firmware und dem Betriebssystem, während "db" die Zertifikate und Signaturen für den Bootloader und Drittanbieter-UEFI-Komponenten enthält. "dbx" hingegen umfasst zurückgezogene Signaturen bekannter schadhafter Komponenten.
Um einen Angriff durchzuführen, genügt es, neue Schlüssel und Zertifikate für KEK und db zu generieren. Danach kann der öffentlich zugängliche Testschlüssel der Plattform verwendet werden, um das KEK-Zertifikat in die UEFI-Firmware zu laden. Nachdem das KEK-Zertifikat in die Firmware geladen wurde, kann der zugehörige private Schlüssel verwendet werden, um das neue Zertifikat in die db zu laden. Nach dem Hochladen des db-Zertifikats kann der zugehörige private Schlüssel verwendet werden, um die geladenen EFI-Komponenten zu signieren.openssl req -newkey rsa:4096 -nodes -keyout KEK.key -new -x509 -sha256 -days 3650 -subj "/CN=BRLY KEK/" -out KEK.crtopenssl req -newkey rsa:4096 -nodes -keyout db.key -new -x509 -sha256 -days 3650 -subj "/CN=BRLY db/" -out db.crtefi-updatevar -a -c KEK.crt -k PK.key KEK efi-updatevar -a -c db.crt -k KEK.key db sbsign —key db.key —cert db.crt —output rogue.efi.signed rogue.efi
Um die Korrektheit des Plattform-Schlüssels zu überprüfen, reicht es, das Tool „efi-readvar -v PK“ aus dem efitools-Paket auszuführen und sicherzustellen, dass der Plattform-Schlüssel kein Testschlüssel ist:efi-readvar -v PKVariable PK, Länge 862 PK: Liste 0, Typ X509Signatur 0, Größe 834, Eigentümer 26dc4851-195f-4ae1-9a19-fbf883bbb35eBetreff: CN=DO NOT TRUST — AMI Test PKAussteller: CN=DO NOT TRUST — AMI Test PK
Quelle: opennet.ru
