Sicherheitsforscher von Binarly haben eine Möglichkeit entdeckt, den UEFI Secure Boot-Verifizierungsmodus bei über 800 Produkten von Unternehmen wie Acer, Dell, Fujitsu, Gigabyte, HP, Intel, Lenovo und Supermicro zu umgehen. Das Problem trägt den Codenamen PKfail und hängt mit der Verwendung eines nicht vertrauenswürdigen Plattformschlüssels (PK, Platform Key) zusammen, der von AMI (American Megatrends International) generiert und als Testbeispiel bereitgestellt wurde. Die ältesten Firmware-Versionen, die den Testschlüssel verwendeten, stammen aus dem Jahr 2012, während die neuesten von Juni 2024 datiert sind. Laut den Forschern sind über 10% aller geprüften Firmware-Versionen betroffen.
In den Schlüsselkriterien wurde angegeben, dass der Schlüssel nicht vertrauenswürdig ist und nicht in deren Produkten verwendet werden sollte. Es wurde angenommen, dass dieser Testschlüssel durch einen eigenen ersetzt werden sollte, aber die Hersteller ignorierten die Warnung und verwendeten in den endgültigen Firmware-Versionen einen generischen Schlüssel, der an alle Partner und Kunden von AMI verteilt wurde.
Der geheime Teil des Testschlüssels von AMI, der zur Erstellung digitaler Signaturen erforderlich ist, wurde öffentlich zugänglich, nachdem Informationen von einem der Hardware-Hersteller geleakt wurden, dessen Mitarbeiter versehentlich Code, der diesen Schlüssel enthielt, in einem öffentlichen Repository auf GitHub veröffentlicht hatte. Der geheime Schlüssel war in einer verschlüsselten Datei gespeichert, bei deren Verschlüsselung ein einfacher 4-stelliger Passwort verwendet wurde, der durch Brute-Force leicht geknackt werden konnte.
Der Plattformsschlüssel wird als Vertrauensanfang für die Signierung von Datenbanken mit Schlüsseln für Secure Boot verwendet. Der Zugriff auf den geheimen Teil des Plattformschlüssels führt zur Kompromittierung der gesamten Vertrauenskette, die bei der Überprüfung der Gültigkeit der Komponenten des Startsystems verwendet wird – mit dem Plattformsschlüssel kann der Secure Boot-Schutz umgangen und die Bereitstellung eigener Komponenten beim Booten durch Manipulation des KEK (Key Exchange Key) und der Datenbanken "db" (Signature Database) und "dbx" (Forbidden Signature Database) organisiert werden. Der KEK ist verantwortlich für die Erstellung einer Vertrauenskette zwischen Firmware und Betriebssystem, "db" enthält Zertifikate und Signaturen für Bootloader und Drittanbieter-UEFI-Komponenten, während "dbx" die widerrufenen Signaturen bekannter bösartiger Komponenten enthält.
Um einen Angriff auszuführen, genügt es, neue Schlüssel und Zertifikate für KEK und db zu generieren und anschließend den in den öffentlichen Zugang gelangten Testschlüssel der Plattform zu verwenden, um das erstellte KEK-Zertifikat in die UEFI-Firmware zu laden. Nach dem Laden des KEK-Zertifikats in die Firmware kann der damit verbundene private Schlüssel verwendet werden, um das neue Zertifikat in der Datenbank db zu laden. Nach dem Laden des db-Zertifikats kann der dazugehö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.crt openssl req -newkey rsa:4096 -nodes -keyout db.key -new -x509 -sha256 -days 3650 -subj "\/CN=BRLY db\/" -out db.crt efi-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 Richtigkeit des Schlüssel der Plattform zu überprüfen, genügt es, das Dienstprogramm „efi-readvar -v PK“ aus dem Paket efitools zu starten und sicherzustellen, dass der Schlüssel der Plattform kein Testschlüssel ist: efi-readvar -v PK Variable PK, length 862 PK: List 0, type X509 Signature 0, size 834, owner 26dc4851-195f-4ae1-9a19-fbf883bbb35e Subject: CN=DO NOT TRUST — AMI Test PK Issuer: CN=DO NOT TRUST — AMI Test PK
Quelle: opennet.ru
