Secure Boot durch Windows 10 Anniversary Update-Backdoor ausgehebelt

Microsoft hat durch ein Versehen den Secure Boot-Mechanismus von UEFI-Systemen mit einer Backdoor (Debug-Funktionen) in einer der Redstone 1 Builds (Vorbereitung zum Anniversary Update) abschaltbar gemacht. Und Versuche, das zu beheben, sind zwischenzeitlich zwei Mal gescheitert.

Sie können es nicht, die Leute bei Microsoft – nämlich Secure Boot und TPM 2.0 für "ihre Anwender" zuverlässig verwalten. Das ist nicht meine Aussage, sondern der Standpunkt von Rüdiger Weis.  Dieser ist Mathematiker, Kryptograph und promovierter Informatiker und hält einen Lehrstuhl für Informatik an der Beuth-Hochschule für Technik in Berlin. Wenn Weis etwas sagt, ist das kein Gelaber eines Scriptkiddies, sondern durch Wissen und langjährige Erfahrungen abgedeckt.

(Quelle: YouTube)

Das obige Video stammt von einem Vortrag, den Weis zum Thema gehalten hat (siehe auch die Artikel in der Link-Liste am Beitragsende). Die Kritik von Weis an Windows 10 richtet sich gegen die "verpflichtenden Updates", das Thema "Trusted Computing" und den Umstand, dass Microsoft das Ganze nicht im Griff habe. Weis kann einige Flops, wie den Versuch das veraltete SHA-1-Absicherungsverfahren rauszuwerfen, vorweisen, bei dem mal eben der Dual-Boot für Linux zerschossen und die Privateinstellungen der Nutzer ruiniert wurden. Weis spricht von handwerklichen Katastrophen …

Secure Boot-Backdoor in Windows 10 Anniversary Update

Konnte man die Ausführungen von Weis noch als Aluhut-Trägertum abtun, hat Microsoft nun die nächste Kostprobe, quasi das Gesellenstück, abgeliefert. Bei der Entwicklung von Windows 10 Version 1607 (Anniversary Update) wurde eine sogenannte Secure Boot Policy in den Microsoft Windows-Bootloader eingebaut, die es einem Administrator auf einem System erlaubt, den Secure-Boot-Schutz (remote) zu umgehen – und aus Versehen wohl an Insider ausgerollt. Dies Policy ermöglicht beliebige eigene (aber signierte) Betriebssystem-Komponenten zu booten. Es reicht, den Code mit einer selbst erstellten Signatur zu versehen, um im Bootlader ausgeführt zu werden. Ist für Frickler und Entwickler gut, aber Microsofts Idee von Secure Boot war ja eigentlich, dass nur von Microsoft signierte Codeteile geladen werden können (die Kritik aus der Linux-Community war ja, dass Microsoft alternative Betriebssysteme aussperrt).

Darüber müssen wir uns nicht mehr wirklich Sorgen machen, seit der neueste Flop bekannt wurde. Sicherheitscracks haben herausgefunden, dass die Security Policy wohl eine Art Debug-Funktion ist, mit der Administratoren den Secure Boot Remote über das Netz abschalten können (also nicht mehr in die UEFI-Funktionen des Geräts hinein müssen). Bei Surfaces und Smartphones könnte Microsoft die Abschaltung des Secure Boot blockieren (ich habe keines dieser Geräte, um das zu testen).

'Backdoor'  – Secure Boot ausgehebelt

In einem Blog-Beitrag (Vorsicht, ziemlich eigenwillig in der Darstellung) beschreiben die Leute das Ganze und haben die Details zum Entsperren des Bootloaders in Phones, Tablets und anderen UEFI-Geräten ins Netz gestellt.

Einige Medien schreiben zwar von "golden Keys", was aber wohl nicht stimmt. Mit der Security Policy (die Microsofts Entwickler in den Insider Preview Builds benutzten) können Dritte ihren Code beliebig signieren und dann auf den Geräten mit UEFI ausführen. Der Secure Boot wird ja ausgehebelt. Der Ansatz eröffnet die Möglichkeit, auch alternative Betriebssysteme auf Microsoft-Hardware zu frickeln.

Diese Policy sollte nur intern bei Microsoft Verwendung zum Testen des Codes finden, wurde aber irrtümlich mit einer Insider Preview ausgerollt.

Für Nutzer, die aus Sicherheitsgründen auf UEFI/Secure Boot setzen, erweist sich das Ganze ein Stück wirkungslos und wirft ein Schlaglicht auf den gesamten Ansatz. Denn natürlich könnten auch Hacker und Cyber-Kriminelle sowie die Geheimdienste diese Technik verwenden. Ist zwar nicht mehr so ganz einfach, weil Microsoft versucht, diese Policy zurückzuziehen, Aber die Geschichte geht noch weiter bzw. hat einen gänzlich anderen Aspekt …

Die Box der Pandora – vergebliche Versuche zum Fixen

Von den Hackern Slip und MY123 (im Netz als 'Sicherheitsforscher' betitelt), die den Flop entdeckten, wurde Microsofts Sicherheitsteam bereits im März 2016 informiert. Der Code zum Entsperren des Secure Boot fand sich in der Redstone 1 Build 14381:

I saw some additional code in the load-legacy-policy function in
redstone 14381.rs1_release

Der lapidare Kommentar von Microsoft war (laut heise.de), dass man das Problem nicht beheben wolle. Klingt logisch, denn es war ja eine "Insider Build" und die Funktion eigentlich nur für Microsofts Entwickler gedacht. [Nachtrag: Martin Geuß schreibt hier und WinFuture hier, dass die Leute im Rahmen eines Bug Bounty Programms später sogar eine Belohnung bekommen hätte.]  Aber die Info zum Signieren war da schon öffentlich. Also versuchte Microsoft das wieder zu fixen, indem die Policy als "zurückgezogen" gekennzeichnet wurde. Der erste Patch kam im Juli in Form des Update MS16-094 (siehe Microsoft Patchday: Updates Juli 2016, Sicherheitsupdate für den sicheren Start (3177404) hier im Blog). Die Hacker schreiben:

Anyway, MS's first patch attempt. I say "attempt" because it surely doesn't do anything useful. It blacklists (in boot.stl), most (not all!) of the policies.
Now, about boot.stl. It's a file that gets cloned to a UEFI variable only boot
services can touch, and only when the boot.stl signing time is later than the
time this UEFI variable was set.

However, this is done AFTER a secure boot policy gets loaded. Redstone's
bootmgr has extra code to use the boot.stl in the UEFI variable to check
policy revocation, but the bootmgrs of TH2 and earlier does NOT have such code.

So, an attacker can just replace a later bootmgr with an earlier one.

Es gibt zwar Code im aktuellen Windows 10 Version 1607 Bootlader, der zurückgezogene Policies prüft. Ersetzt man den neuen Bootlader aus dem Anniversary Update mit einem alten Bootlader aus der erwähnten Insider Build, klappt die Backdoor wieder.

Beim August 2016 Patchday gab es dann MS16-100 (siehe Microsoft Patchday: Updates August 2016), in dem ein weiterer Versuch zum Beheben des Flops unternommen wurde. Dieser erschwert das Ausnutzen der Lücke, verhindert das Ganze aber wohl nicht wirklich. Hier der Text:

On August 9th, 2016, another patch came about, this one was given the designation MS16-100 and CVE-2016-3320. This one updates dbx. The advisory says it revokes bootmgrs. The dbx update seems to add these SHA256 hashes (unless I screwed up my parsing)

….

I checked the hash in the signature of several bootmgrs of several
architectures against this list, and found no matches. So either this
revokes many "obscure" bootmgrs and bootmgfws, or I'm checking the wrong hash.

Either way, it'd be impossible in practise for MS to revoke every bootmgr
earlier than a certain point, as they'd break install media, recovery partitions, backups, etc.

Und damit ist die Büchse der Pandora geöffnet – mit der Materie befasste Insider bezweifeln, dass sich das Problem jemals ganz fixen lässt. Zwischenzeitlich geht die Story im Internet herum. Bei The Register als Bungling Microsoft singlehandedly proves that golden backdoor keys are a terrible idea, bei ZDnet.com als Microsoft Secure Boot key debacle causes security panic und bei heise.de gibt es den deutschsprachigen Beitrag Kardinalfehler: Microsoft setzt aus Versehen Secure Boot schachmatt.

Ergänzung: Das Problem verstehen

Im Netz finden sich diverse Artikel, die das Thema als "Sicherheitsproblem" verharmlosen. Daher noch eine kleine Ergänzung, um zu verstehen, was da schief gegangen ist.

Secure Boot wurde ja im Rahmen der UEFI-Initiative eingeführt, um nur noch das Laden von signiertem Code zuzulassen. Die betreffende Maschine lädt also nur Betriebssysteme oder Code, der mit von Microsoft ausgestellten Schlüsseln signiert wurde. Neben Windows 8, 8.1 und Windows 10 hat Microsoft auch Signaturschlüssel für Drittanbieter aus dem Linux-Umfeld freigegeben. Aber die Kontrolle, was bootbar ist, lag/liegt bei Microsoft.

Hintergrund für diese Ansätze waren die vor Jahren aufgetauchten Root-Kits, die sich parallel zum Betriebssystem einnisteten. Das sollte sich mit Secure Boot verhindern lassen. Zusätzlich gibt es noch TPM 2.0 (Trusted Platform Module) zur Speicherung und Absicherung diverser, an die Maschine gebundener, Schlüssel. Microsoft macht aus diesem Grunde die Unterstützung von TPM 2.0 bei neuer Hardware (und damit UEFI samt Secure Boot) verpflichtend (siehe mein Blog-Beitrag Windows 10 Version 1607 erfordert TPM 2.0 bei neuer HW).

Zurück zum Kern: Secure Boot lässt sich zwar nach wie vor im UEFI abschalten, wenn ich Zugang zur Maschine habe. Setzen aber Firmen oder Anwender zur Sicherung ihrer Systeme auf Secure Boot, muss sichergestellt sein, dass dieser Mechanismus in allen Fällen zuverlässig funktioniert. Es darf nicht sein, dass ein falscher Key den Start eines legalen Windows (oder Betriebssystems) verhindert. Und es darf erst Recht nicht sein, dass durch irgend eine Maßnahme der Start beliebigen Codes möglich ist.

Beide Fälle sind in der Vergangenheit passiert, denn Microsoft kann die zulässigen Schlüssel für Secure Boot im UEFI aktualisieren und hat nun auch den Bootlader so manipuliert, dass ein Secure Boot umgangen werden konnte. Das mag für Entwicklungszwecke sinnvoll sein – aber dann hätte man ein Microsoft Entwickler-Zertifikat verwenden sollen. Der Fehler war, dass man auf selbst ausgestellte Zertifikate zum Signieren des Codes gesetzt hat.

Mit der oben aufgeführten Redstone 1 Insider Preview Build redstone 14381.rs1_release liegt nun ein (von Microsoft signierter) Bootlader vor, der den Secure Boot umgehen kann. Damit kann/konnte sich also quasi jeder Entwickler zur vertrauenswerten Institution erklären, deren Code mit Secure Boot ausführbar ist. Da hilft es nicht, sich auf den Punkt "kann nur mit Administratorrechten ausgeführt werden" zurückzuziehen. Bei fast jedem Microsoft Patchday werden "privilege escalation"-Lücken geschlossen – also Sicherheitslücken, die eine Rechteausweitung ermöglichen. Wer die Lücken kennt, kann sich u.U. Administratorrechte verschaffen. Und die in der letzten Zeit kreisenden Erpressungstrojaner versuchten durch Aufruf der Benutzerkontensteuerung Administratorrechte anzufordern. Offenbar gibt es genügend Anwender, die bei der Installation einer Software genau das zulassen. Und so kommt es, dass auch Erpressungstrojaner, die den Master Boot Record austauschen, aufgefallen sind.

Genau diese Mechanismen können natürlich genutzt werden, um den betreffenden Redstone 1-Bootlader auf das System zu bringen. Der Versuch, die ursprüngliche Policy, die das Laden von selbst signierendem Code zulässt, für ungültig zu erklären und zurückzuziehen, ist mühsam und wohl auch fehleranfällig. Kern und Angelpunkt ist die Erkenntnis, dass Secure Boot nicht wirklich die Sicherheit bringt, die man sich versprochen hat (quasi eine "Schönwetter-Lösung").

Abschließende Gedanken

Tja, mir wirft man hier in Kommentaren schon mal eine "Vendetta" gegen Microsoft und Windows 10 vor und ich würde das alles nur schlecht schreiben. Mal abgesehen von der Tatsache, dass ich nix gegen Microsoft habe, aber als Blogger dieses und jenes halt aufspieße: Mein Blog ist eine Nische (was kratzt es den Berg, wenn eine Ameise an diesen pisst). Da geht Microsoft auch sehr souverän mit um – die lesen es und lassen es unkommentiert. Die 'Sargnägel' schlägt Microsoft schon selbst ein – und das (gefühlt) fast täglich. Apple Insider hat dies schön aufgespießt.

Man kann jetzt argumentieren, dass der Fehler selbst nicht so schlimm sei, weil man ja Administrator sein muss. Und es ist schon ein "sehr spezielles Szenario", um das auszunutzen. Und auf den meisten Maschinen lässt sich Secure Boot ja im UEFI abschalten. Viel Lärm um nichts und alles gut?

Imho nein, denn es geht ums Prinzip: Microsoft will die IT-Sicherheit in seine Hände gelegt wissen. Das reicht von Clients über Server bis zu Azure. Und dann diese Fehler, mit der mal eben die "Chain of Trust" geschlachtet wird. Ich hatte hier im Blog diverse Male über Comodo berichtet, die als Zertifikats-Authority agieren wollen, sich aber einen Flop nach dem anderen leisten. Ein Notar, der ständig patzt ist obsolet. Und das ist der springende Punkt.

Ist nicht wirklich Schadenfreude, mir wäre es lieber, hier berichten zu können, dass Microsoft wieder "in der Spur läuft" und ein brauchbares Windows für Privatanwender und kleine Firmen anbietet. Leider hat man wohl im letzten Jahr ein paar Leute zu viel entlassen. Aber möglicherweise können sich Firmen wie Microsoft, Google, Facebook zwischenzeitlich alles erlauben. Hauptsache schön bunt und gratis, denn folgen die Lemminge mit Begeisterung. Oder wie seht ihr das?

Ähnliche Artikel:
Warnung vor "Botnetz" Windows 10 …
Windows 7: Patchday-Nachwehen "Secure Boot Violation"
Windows 10 Version 1607 erfordert TPM 2.0 bei neuer HW
Aufzeichnung "Technical Summit 2015" abrufbar

Microsoft Patchday: Updates Juli 2016
Microsoft Patchday: Updates August 2016