Ein kürzlich durchgesickerter „Golden Key“ von Microsoft in Verbindung mit dem Vorhandensein eines Debug-Modus hat es ermöglicht, den sicheren Start auf Windows-Geräten zu deaktivieren. Weiter lesen!
Windows-basierte Betriebssysteme sind in der mobilen Szene nicht mehr die Standard- und erste Wahl. Der Open-Source-Charakter von Android hat bei OEMs viele Fans gefunden, weshalb heutzutage immer weniger Telefone Windows verwenden.
Aber wenn Sie zu denen gehören, die in Ihrem täglichen Leben immer noch ein Windows-Gerät verwenden, gibt es eine Neuigkeit für Sie. Ob gut oder schlecht, das hängt von Ihrer Haltung und Interpretation der Anwendungsfälle dieser Nachrichten ab.
Wie berichtet von Ars Technica Und Das Register mit den Nachrichten, die von a stammen Website, die Ihnen wahrscheinlich Kopfschmerzen bereiten wird (kein Scherz), ein paar Entwickler (@never_released Und @TheWack0lian) haben herausgefunden, dass eine von Microsoft zu Debugzwecken eingebaute Hintertür Möglichkeiten eröffnet hat, den sicheren Start auf Windows-Geräten zu deaktivieren.
Secure Boot und was ist das?
Wenn Sie ein Windows-Gerät zum ersten Mal starten, läuft der Startvorgang in dieser allgemeinen Reihenfolge ab: UEFI (Unified Extensible Firmware Interface, das das BIOS ersetzt) -> Boot Manager -> Boot Loader -> Windows. In UEFI ist die Secure Boot-Funktionalität vorhanden. Wie der Name schon sagt, mit Sicherer Startvorgang, Ziel ist es, die Sicherheit durch die Anforderung digitaler Signaturen zu verbessern über die nächsten Schritte. Wenn der Bootloader nicht mit den von UEFI erwarteten Schlüsseln signiert ist, wird der Bootvorgang Ihres Geräts im Wesentlichen nicht abgeschlossen.
Secure Boot ist eine optionale Funktion, aber Microsoft hat die Aktivierung zur Pflicht gemacht, um die Windows-Zertifizierung ab Windows 8 zu erhalten. Der Grund dafür war, dass Secure Boot es Malware-Autoren erschweren würde, Code in den Boot-Vorgang einzufügen. Ein Nebeneffekt von Secure Boot war jedoch, dass es den Dual-Boot auf Windows-Rechnern etwas komplizierter machte Entweder müssen das zweite Betriebssystem und alle seine Voraussetzungen ebenfalls digital signiert sein, oder Secure Boot müsste es sein deaktiviert. Es gibt noch viele andere Probleme, über die erfahrene Dual-Boot-Fans mehr wissen, als ich in einem Absatz erklären könnte.
Nun gibt es einige Geräte, bei denen Secure Boot vom Benutzer nicht deaktiviert werden kann, selbst wenn er dies wollte. Dies ist der Bereich, in dem unser Thema drastisch auf alle Windows-Geräte (einschließlich) eingegrenzt wird Desktops) auf bestimmte Windows-Geräte wie Windows Phone-Geräte, Windows RT-Geräte, einige Surface-Geräte und sogar HoloLens. Diese Endbenutzergeräte verfügen über Secure Boot ist aktiviert, was bedeutet, dass ein Der Endbenutzer kann Aspekte im Zusammenhang mit Secure Boot nicht ändern oder deaktivieren, und im weiteren Sinne dürfen sie das Betriebssystem nicht auf eine Weise berühren, die nicht von Microsoft für den Endbenutzer autorisiert wurde.
Für die weitere offizielle Weiterentwicklung muss Secure Boot jedoch etwas gelockert werden. Auf Geräten, auf denen Secure Boot gesperrt ist, gibt es Secure Boot-Richtlinien, die bei der autorisierten Entwicklung helfen können, ohne dass Secure Boot deaktiviert werden muss. Wie die recherchierenden Benutzer erwähnen, wird diese Secure Boot Policy-Datei vom Boot Manager zu Beginn des Bootvorgangs für Windows geladen. Die Richtliniendateien können auch Registrierungsregeln enthalten, die wiederum unter anderem Konfigurationen für die Richtlinie selbst enthalten können. Auch hier muss die Richtliniendatei signiert werden und es gibt weitere Bestimmungen, die sicherstellen, dass nur Microsoft diese Änderungen bereitstellen kann.
Das Signaturelement basiert auch auf der sogenannten DeviceID, die bei der Bewerbung verwendet wird. Ich überlasse die Erklärung hier dem Blog-Beitrag, da es einige Teile gibt, die mir nicht so klar sind:
Es gibt auch so etwas namens DeviceID. Es handelt sich um die ersten 64 Bits eines gesalzenen SHA-256-Hashs einer UEFI-PRNG-Ausgabe. Es wird beim Anwenden von Richtlinien auf Windows Phone und Windows RT verwendet (mobilestartup legt es auf Phone fest und SecureBootDebug.efi, wenn es zum ersten Mal auf RT gestartet wird). Auf dem Telefon muss sich die Richtlinie an einer bestimmten Stelle auf der EFIESP-Partition befinden, wobei der Dateiname die Hexadezimalform der Geräte-ID enthalten muss. (Bei Redstone wurde dies in UnlockID geändert, das von bootmgr festgelegt wird und nur die rohe UEFI-PRNG-Ausgabe ist.)
Grundsätzlich überprüft bootmgr die Richtlinie beim Laden. Wenn sie eine Geräte-ID enthält, die nicht mit der Geräte-ID des Geräts übereinstimmt, auf dem bootmgr ausgeführt wird, kann das Laden der Richtlinie fehlschlagen. Jede Richtlinie, die die Aktivierung von Testsignaturen ermöglicht (MS nennt diese Retail Device Unlock/RDU-Richtlinien und to Sie zu installieren bedeutet, ein Gerät zu entsperren), soll an eine DeviceID (UnlockID auf Redstone und über). Tatsächlich habe ich mehrere Richtlinien (signiert durch das Windows Phone-Produktionszertifikat) wie diese, bei denen die einzigen Unterschiede die enthaltene Geräte-ID und die Signatur sind. Wenn keine gültige Richtlinie installiert ist, greift bootmgr auf die Verwendung einer Standardrichtlinie zurück, die sich in seinen Ressourcen befindet. Diese Richtlinie blockiert die Aktivierung von Testsignaturen usw. mithilfe von BCD-Regeln.
Das ist der Teil, an dem es interessant wird. Während der Entwicklung von Windows 10 v1607 hat Microsoft eine neue Art von Secure Boot Policy (der Kürze halber im Folgenden als SBP bezeichnet) für interne Test- und Debugging-Zwecke erstellt. Die Richtlinie ist von Natur aus „ergänzend“, da keine Geräte-ID vorhanden ist, und führt dazu, dass ihre Einstellungen in eine vorhandene Startrichtlinie eingefügt werden. Der Boot-Manager lädt die älteren SBP-Typen, überprüft dann deren Signatur und Authentizität und lädt dann diese zusätzlichen Boot-Richtlinien. Das Problem hierbei ist, dass es keine weitere Überprüfung der Zusatzpolice selbst gibt. Außerdem wissen Bootmanager vor Windows 10 v1511 nichts von der Existenz des ergänzenden Charakters dieser Richtlinien und daher reagieren, als ob sie eine vollkommen gültige und unterzeichnete Richtlinie geladen hätten. Auch dieses Verhalten war wahrscheinlich auf die interne Entwicklung zurückzuführen, sodass die Entwickler nicht jede einzelne Betriebssystemversion und kleinere Änderung, die sie am Gerät vornehmen mussten, hätten signieren müssen.
Dieser SBP wird als „Goldener Schlüssel“ bezeichnet, da er den Zweck von Signaturprüfungen im Grunde zunichte macht. Dieses SBP wurde unbeabsichtigt auf Einzelhandelsgeräten ausgeliefert, wenn auch in deaktiviertem Zustand. Die Entwickler fanden dieses SBP und gaben ihre Erkenntnisse bekannt. Jetzt kann das SBP sein im Internet gefunden, wobei diese spezielle Zip-Datei zur Installation des SBP auf Windows RT-Geräten verwendet wird.
Was bedeutet das?
Wenn Sie ein zusätzliches SBP geladen haben, können Sie die Testsignierung für Windows aktivieren, um das Laden nicht signierter Treiber zu ermöglichen. Da diese Richtlinien außerdem vor der Boot-Manager-Phase des Boot-Vorgangs ins Spiel kommen, können Sie die Sicherheit des gesamten Auftrags gefährden und nicht autorisierten (selbstsignierten) Code ausführen. Dies eröffnet zahlreiche Möglichkeiten, sowohl für Benutzer, die Teile von Windows unbefugt ändern möchten, als auch für Malware-Ersteller.
Die Autoren dieser Feststellung konzentrieren sich auf die Ironie des gesamten Fiasko. Microsoft hat Secure Boot auf bestimmten Geräten aktiviert, um unbefugte Änderungen fernzuhalten, hat dann aber eine Hintertür eingebaut, um die Entwicklung und das Debuggen fortzusetzen. Aber genau diese Hintertür ebnet den Weg, Secure Boot auf allen Geräten mit Windows zu deaktivieren, was die ganze Tortur sinnlos macht.
Nicht nur, dass willige Benutzer jetzt Linux-Distributionen (und möglicherweise Android) auf reinen Windows-Tablets installieren können Auf Telefonen können unwillige Benutzer auch bösartige Bootkits installieren, wenn sie den physischen Zugriff darauf gefährden Gerät. Während Ersteres etwas ist, worüber wir uns freuen können, weckt Letzteres nicht wirklich viel Selbstvertrauen. Es geht in beide Richtungen und zeigt uns, warum Sicherheit ein zweischneidiges Schwert ist. Darüber hinaus ist das SBP universeller Natur und ermöglicht die Verwendung auf jedem Gerät unabhängig von der Architektur. Es ist nicht besonders nützlich für Desktop-PCs, bei denen Secure Boot einfach ausgeschaltet werden kann, aber es ist von großem Nutzen für Geräte, bei denen Sie mit Secure Boot nicht herumspielen können.
Also, was ist die Lösung?
Microsoft hat zwar einige Patches veröffentlicht, aber die Entwickler bestehen darauf, dass das Problem nicht vollständig behoben ist. Sie können sich diese Patches ansehen (MS16-094 Und MS16-100) und dann weiterlesen Blogeintrag selbst darüber, warum sie das Problem nicht lösen. Wenn sie korrekt sind, ist für dieses Problem weder eine Lösung noch ein Patch in Sicht, was Microsoft jedoch nicht davon abhalten wird, weitere Hindernisse auf dem Weg dorthin zu errichten.
Was als nächstes?
Es gibt eine Welt voller Möglichkeiten, und einige davon tauchen in unseren Windows-Foren auf. Sie können unsere Foren unter besuchen Entwicklung und Hacking von Windows Phone 8 und unsere Foren für Entwicklung und Hacking von Windows 8, Windows RT und Surface. Sie können auch finden Anleitungsthreads für einige Geräte, wo andere Benutzer das Gleiche diskutieren.
Das Vorhandensein dieser Debug-Hintertür und das Leck des SBP sind nicht nur für Dritte wichtig Entwicklung gesperrter Windows-Geräte, sie zeigen uns auch eine düstere Erinnerung daran, was passieren kann, wenn es absichtlich geschieht Es bleiben Hintertüren übrig. Der Fokus auf Sicherheit richtete sich in jüngster Zeit auf die Ermittlungsbehörden, die darauf drängten, dass solche Hintertüren zur Unterstützung ihrer rechtlichen Ermittlungszwecke genutzt werden könnten. Aber früher oder später werden diese Methoden funktionieren Wille in die falschen Hände geraten. Was als Werkzeug zur Kriminalitätsbekämpfung und zur Unterstützung der Justiz dienen soll, würde eines Tages zum Werkzeug für das Verbrechen selbst werden.
Was denken Sie über das Leck des Debug SBP? Glauben Sie, dass es solche „Goldenen Schlüssel“ geben sollte? Lass es uns unten in den Kommentaren wissen!