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.


Werbung

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.


Werbung

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?


Werbung

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


Werbung



Dieser Beitrag wurde unter Windows 10 abgelegt und mit , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

13 Kommentare zu Secure Boot durch Windows 10 Anniversary Update-Backdoor ausgehebelt

  1. Andreas64 sagt:

    Das sehe ich genauso.

    Ich habe win7, win8.1 sowie LMDE2 am Laufen.
    Wenn der support für diese Windows-Versionen ausläuft, gehe ich mit diesen Büchsen nicht mehr ans Netz, oder Windows fliegt ganz von der Platte.

  2. Remo sagt:

    Das sehe ich ebenso. Das ganze Gefrickel ist irgendwie an Abartigkeit kaum mehr zu übertreffen.
    Dass Fehler passieren gehört dazu. Dazu sind wir – die allermeisten wenigsten – ja zum Glück noch Menschen. Aber ein funktionierendes QM (haben die überhaupt noch sowas .. hüsteln) wäre dazu gedacht, solche Pannen zu vermeiden bzw. auf ein Minimum zu beschränken.
    Ich sehe da auch in zunehmendem Masse die Schwierigkeit für den normalen Nutzer, einfach mit seinem Kistchen in Ruhe und sicher arbeiten zu können.

  3. Tim sagt:

    „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.“

    Dazu müsste Microsoft heute wohl anfangen, ein ganz neues Betriebsystem zu entwerfen, das nicht mehr auf der Vista Familie basiert, oder aber in dem Dreh vor Windows 8 neu anfangen und SecureBoot und Co gleich mit beerdigen…
    Im Grunde ist durch die Verknüpfung von Hard- und Software experimenteller Elektroschrott entstanden, der eben nicht sicher ist.

    UEFI, Secure Boot und TPM waren schon von Anfang an heiße Eisen die heftig diskutiert wurden. Witzig fand ich das vor einigen Jahren große Kritik von Seiten der Finanzbranche öffentlich wurde und wenn die schon Probleme sehen…

  4. Werbung

  5. Ich lache mich grade Schlapp, so ein kleines Missgeschick mit weitreichenden Folgen, hab mich schon nach dem Anniversary Upgrade gewundert, da du ja geschrieben hattest dass Cortana nur mit deaktiviertem Secure Boot die Websuche deaktiviert werden kann.

    Momentan besitze ich nur ein Mainboard mit Secure Boot und da ist Windows 7 installiert und Secure Boot von Anbeginn an deaktiviert.
    Es ist aber schön nach dieser Panne zu hören das ich mich nun frei entscheiden kann ob ich mit eingeschaltetem Secure Boot trotzdem mich dagegen entscheiden könnte.

    • Tim sagt:

      Muss Secure Boot bei Windows 7 nicht sogar deaktiviert sein? Oder wurde da nachgereicht?

      Ich deaktiviere es von Anfang an überall, weil es sogar mit Spielen schon Probleme gegeben hat, wenn Secure Boot aktiv war und nur durch abschalten die Probleme zu lösen waren.
      Die vermeindliche Sicherheit blockiert hier in der Praxis mehr, als sie letztlich nutzt.

      • Muss nicht, aber man sollte es nach Möglichkeit Deaktivieren http://www.borncity.com/blog/2016/04/14/windows-7-patchday-nachwehen-secure-boot-violation/

        Installation eines „nackten“ PCs mit Windows 7 oder Windows 8
        Neue PCs, die ohne Betriebssystem ausgeliefert werden, befinden sich im Platform Setup Mode mit aktivem Secure Boot. Bei PCs, die mit einem vorinstallierten FreeDOS ausgeliefert werden, ist meist das CSM aktiv. Deaktivieren Sie in diesem Fall im UEFI-Setup-Screen das CSM. Wählen Sie die jeweilige 64-Bit-Version von Windows. Achten Sie bei der Installation von Windows 8 auf die Aktivierung von Secure Boot. Soll Windows 7 installiert werden, ist Secure Boot zu deaktivieren.

        Installation von Windows 7 auf einem PC, der mit Windows 8 ausgeliefert wurde

        Um Windows 7 nutzen zu können, muss Secure Boot deaktiviert werden. Vergewissern Sie sich vor der Windows 7 Installation, dass Sie 64-Bit-Bootmedien verwenden! Idealerweise löschen Sie Windows 8 zunächst, und installieren Sie es nach der Windows 7 Installation erneut, das sorgt für reibungslose Integration in den Bootloader.

      • Ich deaktiviere Secure Boot in der Regel auch falls es geht, zumindest bei mir Privat, ich mag mir auch nicht von Microschrott vorschreiben lassen mit welchem Medium ich boote darf oder nicht.
        Bekanntlich gabs mit Linux und Secure Boot eine Zeitlang massive Probleme und ich nutze gerne auch mal eine Linux Live CD.

        Zumal die Technical Preview 5 von Windows Server 2016 nur bei deaktiviertem Secure Boot in einer virtuellen Maschine betrieben werden kann.

        Momentan bin ich wieder am PC zusammenstellen und wenn ich da bei der Mainboard Auswahl schon UEFI, Secure Boot und TPM lese wird mir in der Magengegend Übel, gut nun scheint Secure Boot ausgehebelt zu sein, ob das ein Dummes Versehen oder vielleicht auch beabsichtigt war wird Microsoft sicher nicht bestätigen. Wobei die Gescheiterten versuche das Loch zu stopfen wohl eher darauf hinweisen das es nicht beabsichtigt war.

        Da wird in Redmond wohl der ein oder andere Kopf rollen 😉

        • Tim sagt:

          „Da wird in Redmond wohl der ein oder andere Kopf rollen“

          Dürfte schwierig werden, so Kopflos wie man bei Microsoft zur Zeit zu sein scheint.
          Wirkt doch vieles, als würde Microsoft für eine ganz andere Realität planen, die außerhalb von Microsofts Mauern allerdings ganz anders gesehen werden.

  6. Na dann besteht ja auch noch die Möglichkeit auf meinen HP Stream Windows 10 Tablett Linux zu installieren.
    Der „Windows ist Service“ Spruch ins nämlich ab diesem gerät gescheitert, da es nur ein 7″ Display und 1GB Arbeitsspeicher besitzt und somit vom Anniversary Upgrade nicht mehr unterstützt wird, aber ich werde mich die Tage mal wider dran setzen um mal zu schauen ob da noch was mit Win10 geht, schwierig war nämlich das sich Secure Boot nicht im BIOS deaktivieren lies.
    Zugegebenermaßen das Display ist echt klein und für Kurzsichtige Brillenträger ist das BIOS echt nicht zu gebrauchen, der Upgrade Vorgang konnte nur mit Hilfe des TeamViewer gestartet werden weil der OK Button außerhalb des Bildschirms Lag, möglicherweise auch die Ursache wieso Anniversary Upgrade für dieses gerät nicht mehr verfügbar ist.

  7. deo sagt:

    Secure Boot ist kompromittiert. Damit ist es eine Nullfunktion, die auch noch erhöhten Aufwand verursacht. Zudem erzeugt es trügerische Sicherheit.

  8. Werbung

  9. Nachträge zum Thema

    Ich habe ja in obigem Artikel versucht, etwas herauszuarbeiten, warum das ganze Secure Boot-Thema mit dem jetzt erfolgten Incident ein Problem für Microsoft ist (egal, was da sonst gesund gebetet wird).

    Gerade bin ich bei Google+ noch über eine Erklärung von Kristian Köhntopp gestolpert, der es mal aus einem anderen Blickwinkel betrachtet. Die Microsoft-Entwickler sind durch Secure Boot ziemlich mir „einem Fuß festgenagelt“, wodurch man überhaupt erst auf die Idee mit den Policies gekommen ist.

    Fazit: Secure Boot kaputt …

    Das Hyper-V Secure Boot-Problem bei Win Server 2016 TP5

    Und es wird dort in den Kommentaren darauf hingewiesen, dass Microsoft selbst mit Secure Boot bei Windows Server 2016 TP5 Probleme hat und den Bootlader blacklisten musste. Das bezieht sich wohl auf KB3172729 und die Hyper-V-Problematik. Man muss Secure Boot ausschalten, um das Betriebssystem unter Hyper-V booten zu können, was ich mehrfach im Blog in anderem Zusammenhang (mit Windows 10 Insider Builds) erwähnt hatte. So schließt sich der Kreis.

    Und jetzt bin ich am überlegen, ob es eine Steigerung von „kaputt“ gibt …

  10. „Und jetzt bin ich am überlegen, ob es eine Steigerung von “kaputt” gibt …“

    Jo gibt es, *Zensiert* *Zensiert* *Zensiert*

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.