![](\"https:\/\/borncity.com\/blog\/wp-content\/uploads\/2015\/01\/win102.jpg\")
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.<\/p>\n
<\/p>\n
(Quelle: YouTube<\/a>)<\/p>\n 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\u00fcr Linux zerschossen und die Privateinstellungen der Nutzer ruiniert wurden. Weis spricht von handwerklichen Katastrophen \u2026<\/p>\n Konnte man die Ausf\u00fchrungen von Weis noch als Aluhut-Tr\u00e4gertum abtun, hat Microsoft nun die n\u00e4chste Kostprobe, quasi das Gesellenst\u00fcck, 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 \u2013 und aus Versehen wohl an Insider ausgerollt. Dies Policy erm\u00f6glicht beliebige eigene (aber signierte) Betriebssystem-Komponenten zu booten. Es reicht, den Code mit einer selbst erstellten Signatur zu versehen, um im Bootlader ausgef\u00fchrt zu werden. Ist f\u00fcr Frickler und Entwickler gut, aber Microsofts Idee von Secure Boot war ja eigentlich, dass nur von Microsoft signierte Codeteile geladen werden k\u00f6nnen (die Kritik aus der Linux-Community war ja, dass Microsoft alternative Betriebssysteme aussperrt).<\/p>\n Dar\u00fcber m\u00fcssen 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 \u00fcber das Netz abschalten k\u00f6nnen (also nicht mehr in die UEFI-Funktionen des Ger\u00e4ts hinein m\u00fcssen). Bei Surfaces und Smartphones k\u00f6nnte Microsoft die Abschaltung des Secure Boot blockieren (ich habe keines dieser Ger\u00e4te, um das zu testen).<\/p>\n In einem Blog-Beitrag<\/a> (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\u00e4ten ins Netz gestellt.<\/p>\n 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\u00f6nnen Dritte ihren Code beliebig signieren und dann auf den Ger\u00e4ten mit UEFI ausf\u00fchren. Der Secure Boot wird ja ausgehebelt. Der Ansatz er\u00f6ffnet die M\u00f6glichkeit, auch alternative Betriebssysteme auf Microsoft-Hardware zu frickeln.<\/p>\n Diese Policy sollte nur intern bei Microsoft Verwendung zum Testen des Codes finden, wurde aber irrt\u00fcmlich mit einer Insider Preview ausgerollt.<\/p><\/blockquote>\n F\u00fcr Nutzer, die aus Sicherheitsgr\u00fcnden auf UEFI\/Secure Boot setzen, erweist sich das Ganze ein St\u00fcck wirkungslos und wirft ein Schlaglicht auf den gesamten Ansatz. Denn nat\u00fcrlich k\u00f6nnten auch Hacker und Cyber-Kriminelle sowie die Geheimdienste diese Technik verwenden. Ist zwar nicht mehr so ganz einfach, weil Microsoft versucht, diese Policy zur\u00fcckzuziehen, Aber die Geschichte geht noch weiter bzw. hat einen g\u00e4nzlich anderen Aspekt \u2026<\/p>\n Von den Hackern Slip und MY123 (im Netz als 'Sicherheitsforscher' betitelt), die den Flop entdeckten, wurde Microsofts Sicherheitsteam bereits im M\u00e4rz 2016 informiert. Der Code zum Entsperren des Secure Boot fand sich in der Redstone 1 Build 14381:<\/p>\n I saw some additional code in the load-legacy-policy function in Der lapidare Kommentar von Microsoft war (laut heise.de<\/a>), dass man das Problem nicht beheben wolle. Klingt logisch, denn es war ja eine \"Insider Build\" und die Funktion eigentlich nur f\u00fcr Microsofts Entwickler gedacht. [Nachtrag: Martin Geu\u00df schreibt hier<\/a> und WinFuture hier<\/a>, dass die Leute im Rahmen eines Bug Bounty Programms sp\u00e4ter sogar eine Belohnung bekommen h\u00e4tte.]\u00a0 Aber die Info zum Signieren war da schon \u00f6ffentlich. Also versuchte Microsoft das wieder zu fixen, indem die Policy als \"zur\u00fcckgezogen\" gekennzeichnet wurde. Der erste Patch kam im Juli in Form des Update MS16-094 (siehe Microsoft Patchday: Updates Juli 2016<\/a>, Sicherheitsupdate f\u00fcr den sicheren Start (3177404) hier im Blog). Die Hacker schreiben:<\/p>\n 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. However, this is done AFTER a secure boot policy gets loaded. Redstone's So, an attacker can just replace a later bootmgr with an earlier one.<\/p><\/blockquote>\n Es gibt zwar Code im aktuellen Windows 10 Version 1607 Bootlader, der zur\u00fcckgezogene Policies pr\u00fcft. Ersetzt man den neuen Bootlader aus dem Anniversary Update mit einem alten Bootlader aus der erw\u00e4hnten Insider Build, klappt die Backdoor wieder.<\/p>\n Beim August 2016 Patchday gab es dann MS16-100 (siehe Microsoft Patchday: Updates August 2016<\/a>), in dem ein weiterer Versuch zum Beheben des Flops unternommen wurde. Dieser erschwert das Ausnutzen der L\u00fccke, verhindert das Ganze aber wohl nicht wirklich. Hier der Text:<\/p>\n 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)<\/p>\n \u2026.<\/p>\n I checked the hash in the signature of several bootmgrs of several Either way, it'd be impossible in practise for MS to revoke every bootmgr Und damit ist die B\u00fcchse der Pandora ge\u00f6ffnet \u2013 mit der Materie befasste Insider bezweifeln, dass sich das Problem jemals ganz fixen l\u00e4sst. Zwischenzeitlich geht die Story im Internet herum. Bei The Register als Bungling Microsoft singlehandedly proves that golden backdoor keys are a terrible idea<\/a>, bei ZDnet.com als Microsoft Secure Boot key debacle causes security panic<\/a> und bei heise.de gibt es den deutschsprachigen Beitrag Kardinalfehler: Microsoft setzt aus Versehen Secure Boot schachmatt<\/a>.<\/p>\n Im Netz finden sich diverse Artikel, die das Thema als \"Sicherheitsproblem\" verharmlosen. Daher noch eine kleine Erg\u00e4nzung, um zu verstehen, was da schief gegangen ist.<\/p>\n Secure Boot wurde ja im Rahmen der UEFI-Initiative eingef\u00fchrt, um nur noch das Laden von signiertem Code zuzulassen. Die betreffende Maschine l\u00e4dt also nur Betriebssysteme oder Code, der mit von Microsoft ausgestellten Schl\u00fcsseln signiert wurde. Neben Windows 8, 8.1 und Windows 10 hat Microsoft auch Signaturschl\u00fcssel f\u00fcr Drittanbieter aus dem Linux-Umfeld freigegeben. Aber die Kontrolle, was bootbar ist, lag\/liegt bei Microsoft.<\/p>\n Hintergrund f\u00fcr diese Ans\u00e4tze waren die vor Jahren aufgetauchten Root-Kits, die sich parallel zum Betriebssystem einnisteten. Das sollte sich mit Secure Boot verhindern lassen. Zus\u00e4tzlich gibt es noch TPM 2.0 (Trusted Platform Module<\/a>) zur Speicherung und Absicherung diverser, an die Maschine gebundener, Schl\u00fcssel. Microsoft macht aus diesem Grunde die Unterst\u00fctzung 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<\/a>).<\/p>\n Zur\u00fcck zum Kern: Secure Boot l\u00e4sst 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\u00e4llen zuverl\u00e4ssig 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\u00dfnahme der Start beliebigen Codes m\u00f6glich ist.<\/p>\n Beide F\u00e4lle sind in der Vergangenheit passiert, denn Microsoft kann die zul\u00e4ssigen Schl\u00fcssel f\u00fcr Secure Boot im UEFI aktualisieren und hat nun auch den Bootlader so manipuliert, dass ein Secure Boot umgangen werden konnte. Das mag f\u00fcr Entwicklungszwecke sinnvoll sein \u2013 aber dann h\u00e4tte man ein Microsoft Entwickler-Zertifikat verwenden sollen. Der Fehler war, dass man auf selbst ausgestellte Zertifikate zum Signieren des Codes gesetzt hat.<\/p>\n Mit der oben aufgef\u00fchrten Redstone 1 Insider Preview Build redstone 14381.rs1_release<\/em> 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\u00e4ren, deren Code mit Secure Boot ausf\u00fchrbar ist. Da hilft es nicht, sich auf den Punkt \"kann nur mit Administratorrechten ausgef\u00fchrt werden\" zur\u00fcckzuziehen. Bei fast jedem Microsoft Patchday werden \"privilege escalation\"-L\u00fccken geschlossen \u2013 also Sicherheitsl\u00fccken, die eine Rechteausweitung erm\u00f6glichen. Wer die L\u00fccken 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\u00fcgend 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.<\/p>\n Genau diese Mechanismen k\u00f6nnen nat\u00fcrlich genutzt werden, um den betreffenden Redstone 1-Bootlader auf das System zu bringen. Der Versuch, die urspr\u00fcngliche Policy, die das Laden von selbst signierendem Code zul\u00e4sst, f\u00fcr ung\u00fcltig zu erkl\u00e4ren und zur\u00fcckzuziehen, ist m\u00fchsam und wohl auch fehleranf\u00e4llig. Kern und Angelpunkt ist die Erkenntnis, dass Secure Boot nicht wirklich die Sicherheit bringt, die man sich versprochen hat (quasi eine \"Sch\u00f6nwetter-L\u00f6sung\").<\/p>\n Tja, mir wirft man hier in Kommentaren schon mal eine \"Vendetta\" gegen Microsoft und Windows 10 vor und ich w\u00fcrde das alles nur schlecht schreiben. Mal abgesehen von der Tatsache, dass ich nix gegen Microsoft habe, aber als Blogger dieses und jenes halt aufspie\u00dfe: Mein Blog ist eine Nische (was kratzt es den Berg, wenn eine Ameise an diesen pisst). Da geht Microsoft auch sehr souver\u00e4n mit um \u2013 die lesen es und lassen es unkommentiert. Die 'Sargn\u00e4gel' schl\u00e4gt Microsoft schon selbst ein \u2013 und das (gef\u00fchlt) fast t\u00e4glich. Apple Insider hat dies sch\u00f6n aufgespie\u00dft<\/a>.<\/p>\n 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\u00e4sst sich Secure Boot ja im UEFI abschalten. Viel L\u00e4rm um nichts und alles gut?<\/p>\n Imho nein, denn es geht ums Prinzip: Microsoft will die IT-Sicherheit in seine H\u00e4nde gelegt wissen. Das reicht von Clients \u00fcber 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 \u00fcber Comodo berichtet, die als Zertifikats-Authority agieren wollen, sich aber einen Flop nach dem anderen leisten. Ein Notar, der st\u00e4ndig patzt ist obsolet. Und das ist der springende Punkt.<\/p>\n Ist nicht wirklich Schadenfreude, mir w\u00e4re es lieber, hier berichten zu k\u00f6nnen, dass Microsoft wieder \"in der Spur l\u00e4uft\" und ein brauchbares Windows f\u00fcr Privatanwender und kleine Firmen anbietet. Leider hat man wohl im letzten Jahr ein paar Leute zu viel entlassen. Aber m\u00f6glicherweise k\u00f6nnen sich Firmen wie Microsoft, Google, Facebook zwischenzeitlich alles erlauben. Hauptsache sch\u00f6n bunt und gratis, denn folgen die Lemminge mit Begeisterung. Oder wie seht ihr das?<\/p>\n \u00c4hnliche Artikel:<\/strong> Microsoft Patchday: Updates Juli 2016<\/a> 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.<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3694],"tags":[1463,1108,4378],"class_list":["post-180345","post","type-post","status-publish","format-standard","hentry","category-windows-10","tag-secure-boot","tag-uefi","tag-windows-10"],"_links":{"self":[{"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/posts\/180345","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/comments?post=180345"}],"version-history":[{"count":0,"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/posts\/180345\/revisions"}],"wp:attachment":[{"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/media?parent=180345"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/categories?post=180345"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/borncity.com\/blog\/wp-json\/wp\/v2\/tags?post=180345"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}Sie k\u00f6nnen es nicht, die Leute bei Microsoft \u2013 n\u00e4mlich Secure Boot und TPM 2.0 f\u00fcr \"ihre Anwender\" zuverl\u00e4ssig verwalten. Das ist nicht meine Aussage, sondern der Standpunkt von R\u00fcdiger Weis<\/a>.\u00a0 Dieser ist Mathematiker, Kryptograph und promovierter Informatiker und h\u00e4lt einen Lehrstuhl f\u00fcr Informatik an der Beuth-Hochschule f\u00fcr Technik in Berlin. Wenn Weis etwas sagt, ist das kein Gelaber eines Scriptkiddies, sondern durch Wissen und langj\u00e4hrige Erfahrungen abgedeckt.<\/p>\n
Secure Boot-Backdoor in Windows 10 Anniversary Update<\/h3>\n
'Backdoor'\u00a0 \u2013 Secure Boot ausgehebelt<\/h3>\n
![](\"https:\/\/i.imgur.com\/kjHbkJp.jpg\")
<\/p>\nDie Box der Pandora \u2013 vergebliche Versuche zum Fixen<\/h3>\n
\nredstone 14381.rs1_release<\/p><\/blockquote>\n
\nNow, about boot.stl. It's a file that gets cloned to a UEFI variable only boot
\nservices can touch, and only when the boot.stl signing time is later than the
\ntime this UEFI variable was set.<\/p>\n
\nbootmgr has extra code to use the boot.stl in the UEFI variable to check
\npolicy revocation, but the bootmgrs of TH2 and earlier does NOT have such code.<\/p>\n
\narchitectures against this list, and found no matches. So either this
\nrevokes many \"obscure\" bootmgrs and bootmgfws, or I'm checking the wrong hash.<\/p>\n
\nearlier than a certain point, as they'd break install media, recovery partitions, backups, etc.<\/p><\/blockquote>\nErg\u00e4nzung: Das Problem verstehen<\/h3>\n
Abschlie\u00dfende Gedanken<\/h3>\n
\nWarnung vor \"Botnetz\" Windows 10 \u2026<\/a>
\nWindows 7: Patchday-Nachwehen \"Secure Boot Violation\"<\/a>
\nWindows 10 Version 1607 erfordert TPM 2.0 bei neuer HW<\/a>
\nAufzeichnung \"Technical Summit 2015\" abrufbar<\/p>\n
\nMicrosoft Patchday: Updates August 2016<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"