Der Sicherheitsstandard Secure Boot ist kompromittierbar

Forscher des Sicherheitsunternehmens Binarly haben aufgedeckt, dass Secure Boot bei mehr als 200 Gerätemodellen von Acer, Dell, Gigabyte, Intel und Supermicro vollständig kompromittiert ist. Secure Boot ist ein Sicherheitsstandard, der von Herstellern der PC-Industrie entwickelt wurde, um sicherzustellen, dass die PCs nur mit Software starten, die die PC-Hersteller vertrauen.

Im Dezember 2022 veröffentlichte ein Entwickler, der mit mehreren US-amerikanischen Geräteherstellern zusammenarbeitet, auf GitHub einen Plattformschlüssel. Dieser kryptografische Schlüssel liegt Secure Boot zugrunde und bildet die Vertrauensbasis zwischen Hardware und Firmware. Das inzwischen entfernte GitHub-Repository enthielt den privaten Teil des Schlüssels, der mit einem einfachen vierstelligen Passwort verschlüsselt war, so dass er für jeden – auch für Binarly – leicht zu knacken war.

Dieses Schlüsselleck blieb unbemerkt und hat die Sicherheit von Secure Boot erheblich beeinträchtigt. Scans ergaben, dass 215 Geräte den kompromittierten Schlüssel verwenden und die Integrität von Secure Boot bei über 300 weiteren Modellen großer Hersteller gefährdet ist. Darüber hinaus wurden 21 Plattformschlüssel mit der Kennzeichnung „DO NOT SHIP“ oder „DO NOT TRUST“ entdeckt, die von 500 Gerätemodellen verwendet werden. Diese Testschlüssel waren nicht für die Produktion bestimmt und wurden über ein Jahrzehnt lang von mehreren Herstellern gemeinsam genutzt, was sie höchst unglaubwürdig macht.

Maschinen, von IoT-Geräten bis hin zu Servern, und sogar die darauf ausgeführten Arbeitslasten – alle benötigen Identitäten. Diese Identitäten können genau wie menschliche Identitäten ausgenutzt werden, und dieser Vorfall zeigt, wie wichtig Maschinenidentitäten sind.

Es geht nicht nur darum, Secrets auf GitHub zu bewahren, sondern auch darum, Identitäten zu schützen. Solange Unternehmen das nicht tun, werden sie weiterhin Probleme haben. Viele glauben, dass dieses Problem mit Schlüsselverwaltung oder Hardware-Sicherheitsmodulen (HSM) gelöst werden kann, aber das macht das Problem nur noch größer. Developer Teams verstehen nicht, warum sie das tun oder wofür der Schlüssel eigentlich verwendet wird.

Sicherheitsteams müssen diese Verantwortung übernehmen, denn Entwickler sollten keine Identitäten absichern müssen, auch nicht die, die zur Unterscheidung von gutem und schlechtem Bootcode verwendet werden. Indem Unternehmen sie als Maschinenidentitäten behandeln, konzentrieren sie sich darauf, den Lebenszyklus zu sichern, Governance durchzusetzen und sicherzustellen, dass sie geschützt sind. Dies ist eine Frage der Identität – in diesem Fall der Identität des Boot-Codes.

In diesem Bericht wurden die Ergebnisse zusammengefasst.