DefCon 30: Unsicherheiten durch Microsoft in UEFI Secure Boot
Microsofts ausschweifende Signier-Praxis produziert Schwachstellen der Secure-Boot-Umgebung. Das kritisierten Sicherheitsforscher auf der DefCon 30.
(Bild: Dmitry Demidovich/Shutterstock.com)
- Lukas Grunwald
Auf der DefCon 30 haben Jesse Michael und Mickey Shkatov die aktuelle Secure-Boot-Umgebung und Microsofts Praxis, andere Bootloader mit dem eigenen Zertifikat zu signieren, stark kritisiert. Bei ihrem Vortrag zeigten die beiden Sicherheitsforscher, wie einfach man UEFI Secure Boot austricksen kann. Mit einem sogenannten Shim signiert Microsoft Bootloader mit dem Microsoft-Schlüssel, die dann auch für Red Hat Linux sicher einen Grub (Grand Unified Bootloader) nachladen können. Der Shim prüft dann die Signaturen vom Grub-Loader gegen eine RedHat-Signatur. So muss Microsoft den Loader nicht bei jedem RedHat-Update neu signieren.
Zu viele unsichere Bootloader
Microsoft hat jedoch zu viele dieser unsicheren Bootloader mit Schlüsseln signiert, die die Redmonder fest im BIOS einbrennen, sodass diese im Secure-Boot-Modus unsichere Komponenten nachladen können. Beispielsweise kann man mit Kasperskys Antivirus CD Grub einfach weitere Module ohne zusätzliche Prüfung unterjubeln.
Gefährlich wird es etwa dann, wenn eine UEFI-Shell mit Secure Boot signiert ist. Die UEFI-Shell stellt mit DOS-Befehlen vergleichbare Kommandos auf Firmware-Ebene bereit. Sie liefert einen Editor mit und die Funktion, Software zu laden und auf Hardware und Treiber zuzugreifen – alles noch, bevor überhaupt ein Betriebssystem bootet. Normalerweise sind diese Komponenten nicht signiert und für Service-Zwecke wie BIOS-Updates oder Patches gedacht.
Kennen Sie schon den kostenlosen iX-Newsletter? Jetzt anmelden und monatlich zum Erscheinungsdatum nichts verpassen: heise.de/s/NY1E In der nächsten Ausgabe geht's ums Titelthema der September-iX: Schnelle Energiesparmaßnahmen in der IT.
Signiert und doch nicht Vertrauenswürdig
Michael und Shkatov zeigten einen von ihnen als LOL Installer bezeichneten Installer, der von Microsoft signiert ist und beliebige Software installieren kann. Unter Windows 10 demonstrierten sie damit eine von ihnen eingeschleuste Anzeige eines Totenschädels im Bootprozess. Außerdem installierten sie eine Backdoor in Windows 10, die die volle Remote-Kontrolle ermöglicht. Secure Boot und TPM sowie Bitlocker waren dabei permanent aktiv, Windows Defender stufte das System als vertrauenswürdig ein.
Microsofts primäre Intention, nur vertrauenswürdigen Code zu laden, lässt sich, wie die Forscher bewiesen, ohne Weiteres umgehen. Zudem ist es möglich, dem Windows-System mit einem Patch vorzugaukeln, dass es sich im Secure-Boot-Modus befindet und es trotzdem im sicheren Modus bootet. Die verwendeten Tools und die freie UEFI-BIOS-Implementierung TianoCore haben die beiden Hacker im Rahmen der DefCon auf GitHub als Container für QEMU veröffentlicht.
Fazit des Vortrags: Solange Microsoft zu viele Third-Party-Loader signiert, ist Secure Boot für Angreifer keine wirkliche Hürde, macht aber den Linux-Usern das Leben unnötig schwer. Gestern verkündete Microsoft, drei unsichere Bootloader per Windows-Update zu blockieren, weshalb sie bei aktiviertem Secure Boot nicht mehr geladen werden können. Ein Zusammenhang zum DefCon-Vortrag besteht aber wohl nicht.
(jvo)
