Ich greife nochmals ein Thema auf, welches uns im Mai 2023 bereits beschäftigte. Mit den Mai 2023 Sicherheitsupdates hat Microsoft ja versucht, die Schwachstelle im Secure Boot, die durch die Hackergruppe BlackLotus und deren UEFI-Bootkit ausgenutzt wird, zu schließen. Das Ganze muss aber durch Administratoren manuell implementiert werden. Mich interessiert, wie der Status bei euch Administratoren im Unternehmensumfeld diesbezüglich ist.
Anzeige
Seit die Hackergruppe BlackLotus einen Weg gefunden hat, den von Microsoft für Windows propagierten Secure Boot zu umgehen, bemüht sich Microsoft darum, diese Schwachstelle zu schließen. Es werden Updates für Windows veröffentlicht, die die Schwachstelle adressieren. Das Problem: Administratoren müssten die Sicherheitsupdates manuell einspielen und laufen in Gefahr, dass Systeme mit nicht angepassten Boot-Medien im Secure Boot-Modus nicht mehr starten können. Ich hatte das Ganze schon mal im Mai 2203 aufgegriffen. Aber man könnte schließen, dass Secure Boot damit mehr oder weniger unbrauchbar geworden ist. Wie drückt es ein Leser aus, der mich auf einen Bericht von Arstechnica hinwies: "Eventuell was Interessantes für Sie: Leider nicht gut: Bye bye Secure Boot… ". Hier nochmals ein Nachgang zum Thema.
Windows 11: BlackLotus UEFI-Bootkit versus Secure Boot
Sicherheitsforscher von ESET haben 2022 eine BlackLotus getaufte Malware in freier Wildbahn entdeckt, die sich des UEFI bemächtigt und von der Cyber-Gruppe Black Lotus für Angriffe verwendet wurde. Das UEFI-Bootkit wird seit Oktober 2022 in Hackerforen für 5.000 US-Dollar verkauft. Im März 2023 haben die Sicherheitsforscher dann ihre Erkenntnisse öffentlich gemacht.
Die Schwachstelle CVE-2023-24932 bezieht sich auf eine Sicherheitslücke in dem in Windows-Betriebssystemen verwendeten Secure Boot, die das Ausführen nicht vertrauenswürdiger Software während des Startvorgangs ermöglicht (genau das soll Secure Boot ja eigentlich verhindern).
Ich hatte im Blog-Beitrag BlackLotus UEFI-Bootkit überwindet Secure Boot in Windows 11 berichtet und schrieb: BlackLotus dürfte die erste UEFI-Bootkit-Malware in freier Wildbahn sein, die Secure Boot unter Windows 11 (und wohl auch Windows 10) aushebeln kann. Damit kann Malware dann auch den Defender oder Bitlocker und HVCI in Windows deaktivieren. Einziger Lichtblick: Die Angreifer benötigen physischen oder administrativen Zugriff auf das Gerät, um den BlackLotus UEFI-Bootkit auf das System zu bringen.
Anzeige
Versuche zu patchen
Bereits im Mai 2023 hatte Microsoft dieses Secure Boot-Problem aufgegriffen und für die unterstützten Windows-Systeme Sicherheitsupdates zum Schließen der Schwachstelle CVE-2023-24932 veröffentlicht. Zeitgleich gab es dann den Support-Beitrag KB5025885: How to manage the Windows Boot Manager revocations for Secure Boot changes associated with CVE-2023-24932 legt Microsoft allen Kunden nahe, die Windows-Sicherheitsupdates vom 9. Mai 2023 zu installieren.
Allerdings reicht es nicht, das betreffende Update zu installieren, Nutzer müssen zusätzliche Schritte unternehmen, um die Schwachstelle zur Umgehung des Secure Boot zu implementieren. Ich hatte das Thema dann im Beitrag KB5025885: Secure Boot-Absicherung gegen Schwachstelle CVE-2023-24932 (Black Lotus) aufgegriffen, und gewarnt. Denn nach Ausführung der Abhilfemaßnahmen lässt sich dies nicht mehr rückgängig machen. Alte Boot-Medien können auf den betreffenden Geräten nicht mehr im Secure Boot gestartet werden, da die benötigten Anpassungen fehlen.
Wird das ein Alptraum?
Die Warnung kommt nicht von ungefähr. Administratoren, die in Unternehmen schnell mal Maschinen auf die Änderungen umstellen, laufen Gefahr, dass ältere Bootmedien mit Windows Installationsabbildungen auf diesen Maschinen nicht mehr verwendet werden können. Nur Windows 10/11-Boot-Medien, die die Änderungen in der .dbx-Datenbank berücksichtigen, werden von Secure Boot als gültig erkannt und können dann noch starten.
Microsoft hat den Support-Beitrag zum Thema Secure Boot inzwischen mehrfach ergänzt – und es gibt einen zweiten Beitrag KB5027455: Guidance for blocking vulnerable Windows boot managers, der sich mit dem Blockieren der Einträgen in der dbx befasst. Hier im Blog hatten Administratoren dieses Problem bereits angerissen.
Die Woche hat mich Blog-Leser Andy Wendel diesbezüglich erneut kontaktiert (danke dafür) und meinte:
Hallo Herr Born,
evt. was Interessantes für Sie: Leider nicht gut: Bye bye Secure Boot…
Gleichzeitig verlinkte er auf den Beitrag Microsoft will take nearly a year to finish patching new 0-day Secure Boot bug von Arstechnica, der bereits zum 12. Mai 2023 erschienen ist. Die Kollegen von Arstechnica sprechen meine obigen Ausführungen ebenfalls an und stufen das Ganze so ein, dass Microsoft wohl fast ein Jahr benötigt, bis der Secure Boot-Bug in der Praxis ausgeräumt sei. Als Problem sehen sie, dass die Abhilfemaßnahmen alle Arten von älteren Windows-Bootmedien unbrauchbar (da nicht mehr bootfähig) mache.
Da die Auswirkungen der Schwachstelle CVE-2023-24932 begrenzt sind (es wird ja physischer Zugang zum System benötigt, und es sind administrative Berechtigungen erforderlich), hält sich das Risiko in Grenzen, wenn man diesen Fix nicht sofort anwendet. Meine Frage an die Administratoren unter der Leserschaft: Habt ihr diesen Fix bei euch in der Unternehmensumgebung umgesetzt? Und falls ja, wie sind die Erfahrungen in der Praxis? Kein Problem, oder seid ihr mit nicht mehr bootenden Systemen konfrontiert worden?
NSA-Tipps zum BlackLotus UEFI-Bootkit
Die National Security Agency (NSA) der USA hat die Woche wohl Hinweise zum Aufspüren des BlackLotus UEFI-Bootkits gegeben.
Obiger Tweet weist beispielsweise auf das Thema hin. The Hacker News hat es in diesem Artikel aufgegriffen.
Anzeige
Bisher sitzen wir es aus.
Ich ärgere mich massiv, das es nicht mal ein angepasstes ADK gibt und ich auch unsere pxe Bootmedien patchen müsste.
Nachtrag: zusammen mit der nicht näher erläutern Lücke mit Bitlocker/WinRE messen ich den Microsoft Maßnahmen eh nur geringen Wert bei.
Für den Bereich Clientbetreuung ist doch gar kein Personal da, was das leisten könnte. Also nichts passiert.
Das BYOD-Geblubber hat eine Mentalität im Management geformt, die davon ausgeht, dass die Endgeräte keine wichtige Größe mehr sind. Die dafür zur Verfügung stehenden Personalanteile sind in der Folge (auch bei uns) quasi auf Null geschrumpft.
Gleichzeitig wird erwartet, dass das iPad vom Chef oder das Android-Handy vom Hausmeister mal schnell nativ in ein Windows-Netz integriert wird, mit Null Interesse daran, was das bedeutet. Alles angeblich nur ein Klick.
Also Null Personal, aber hochfliegende Ansprüche.
Da im Bestand jetzt hauruck loszulegen, ohne ein personelles Fangnetz, halte ich persönlich für noch gefährlicher, als einfach auf den nächsten Austausch zu warten.
Natürlich soll die IT sich darum kümmern. Und natürlich soll man sich dann einfach "die Zeit nehmen". Aber faktisch können wir in dem Bereich gar nichts mehr machen.
Alle "Reserven" sind in übergeordneten Projekten höchster Wichtigkeit (Digitalisierung, bla) gebunden und eigentlich schon massiv überbucht.
Mit Tendenz zur steigenden Überbuchung (doppelt und mehr), quasi ohne Rücksicht auf Verluste.
Kurz: für solche Basistätigkeiten haben wir keine Zeit, weil alle im digitalen Kartenhaus ganz oben neue Karten aufstellen müssen.
An Firmen abgeben funktioniert auch nicht mehr. Unglaublich viele unserer Dienstleister sind selbst total überbucht. Wollte letzte Woche wieder kurzfristige Termine machen und außer einem Anfang Juli liegt alles in den Sternen, die Terminvereinbarungen in einigen Bereichen scheitern sich durch die Monate Richtung 2024.
Ergänzung:
Die kurz- bis mittelfristige Strategie ist bei uns tatsächlich von Clientabgängigkeiten komplett wegzukommen. Windows als Client hat sich für uns zunehmend als nicht mehr wirtschaftlich betreibbar dargestellt.
So lange er irgendwie geht, wird der Windows-Client also ignoriert, auch in seinen Sicherheitsprpblemen. Wir kommen ja nicht mal mehr hinterher mit den ständigen GPO-Anpassungen, um den Werbekram zu bremsen. Halt kein Personal. Jedenfalls nicht genug für den Pflegegrad bei uns als Endkunden, den Microsoft-Produkte mittlerweile einfordern.
Eigentlich ein Offenbarungseid, den man so nicht leisten sollte. Aber so ist es halt.
Die Gegenstrategie läuft aber schon eine Weile: der bunte Zoo der Windowsanwendungen wird von vielen Herstellern auf Webanwendung umgestellt. Da ist im Sektor in letzter Zeit richtig viel passiert. Die haben wohl ähnliche Erfahrungen gemacht.
Mir scheint es zumindest, dass der Druck weg von Windows auch die meisten Hersteller erreicht hat. Fast alle stellen da gerade Programmteile oder ganze Programme um.
Ein ganzer Bereich arbeitet demnächst zu 100% mit einem speziellen Webclient und mit 0% Nutzung von nativen Windows-Komponenten.
Theoretisch könnte es also klappen, den überwiegenden Teil der Clients früher aus der Abhängigkeit vom Windows zu lösen, als Microsoft hier für die vollständige Problembeseitigung sorgen kann.
Praktisch könnten morgen schon diverse Clients auf irgendwas plus Authenticator wechseln und die Leute könnten normal arbeiten. Ist nur gerade zu wenig Zeit.
Und mit nicht mehr abhängigen Clients kann man dann jeweils neu auswählen, was man sicheres und nicht nervendes für die nächste Beschaffungsperiode einplant.
Und dann kann man sich wieder intensiv und effizient mit der Clientsicherheit auseinandersetzen.
Ich glaube, vorher wird das auch nichts mehr.
Aktuell aussitzen, da Personal fehlt (4 Admins auf 60 Kunden und interne IT) und es wichtigere Dinge gibt (aktuell z.B. immer noch Exchange 2013 ablösen, weil Kunden nicht in die Pötte gekommen sind, Ablöse von Sophos UTM durch XG, Ablöse von Debian 9 und 10 und und und) als eine Lücke für die man physischen Zugang benötigt.
Ich habe es bisher nur mit einem Testrechner gemacht und da hat es gut funktioniert. Dank Autopilot gibts hier aber auch keine Schwierigkeiten mit Bootmedien.
Unsere Kunden haben entweder Clients (bzw. den Großteil der Clients) komplett ohne Adminrechte oder halt (leider) so wenig Security, dass SecureBoot nicht das wichtigste Problem wäre.
Das das Bsi noch nicht am Kabel dreht wundert mich. Als 27001 zertifiziertes Unternehmen hat man ja immer die Arsch Karte. Da musst ja auf alles reagierten, analysieren und dann eine Begründung schreiben, wieso, weshalb und warum. Am kürzesten sind die Berichte bei Lücken die man patchen kann 😋
Bei uns ist es nicht gepatcht worden und wird auch nicht gepatcht werden. Aufwand zu groß.
Wird ausgesessen, da die User auf ihren Clients eh keine Adminrechte haben und zudem muß man ja lokalen Zugriff haben.
Daher ist die reale Angriffswahrscheinlichkeit extrem gering.
Adminrechte + lokalen Zugang… also da gibt es andere Sachen die einem den Schlaf rauben.
Schön das meine Mainboards alle über einen echten Schreibschutz "Jumper" verfügen, so kann weder Windows noch ein UEFI-Bootkit in die Hardware-Chips schreiben, auch nicht ins UEFI -nur lesen ist dort erlaubt. Das war mit ein Hauptgrund für den Kauf.
(Win11 Installation im "Reinraum" Offline erfolgt, dann Jumper gezogen!)
@Finn
Private Befindlichkeiten interessieren hier vermutlich nicht, angefragt ist das unternehmerische Umfeld.
Aussitzen, Umsetzung ist nicht praktikabel bzw. von der Priorität ganz unten (was auch für den unpraktikablen WinRE Patch gilt) und die Clients werden eh auch mit Win11 nächstes Jahr erneuert.
Bei uns heißt es auch: Aussitzen! Wir sind zu viert für fast 2000 Accounts sowie die notwendigen Clients und Server zuständig, machen den Einkauf für unseren Bereich (Hardware, Software, Verbrauchtmaterialien), machen Support für ca. 20 Anwendungen (bzw. sollen wir machen), …. Dabei sind wir nicht mal gelernte ITler sondern Elektro- bzw. Maschinenbauingenieure.
Solche Probleme kommen in der Prio gaaaanz weit hinten.
Windows 11 haben wir noch nicht und werde es auch nicht erleben. Microsoft nervt nur noch. Aber mit Windows 10 gehe ich in Rente und dann heißt es: tschüss M$ und lmaA.
Der Admin "Manuel(l)" hat bei uns leider einen Burn-Out und ist dauerhaft ausgefallen ^^
Habe das schon ausführlich getestet und hier berichtet:
https://www.borncity.com/blog/2023/05/13/kb5025885-secure-boot-absicherung-gegen-schwachstelle-cve-2023-24932-black-lotus/#comment-148843
Fazit: ich habe dabei einen sehr alten PC (Baujahr 2012, ohnehin nicht offiziell Windows-11-kompatibel) mit vermutlich fehlerhafter Firmware gefunden, der über USB "unerlaubterweise" trotz Fix ein altes Image bootet. Ansonsten hat alles wie erwartet funktioniert.
Da wirklicher Aufwand ja nur bei externen Bootmedien entsteht, finde ich das ganze nicht so dramatisch, zumindest verglichen mit dem WinRE-Fix.
Wir haben das jetzt endlich umgesetzt bekommen. Echter Horror.
Nach einem Monat mit zahlreichen Tickets und (nicht-) Hilfe eines IT-Dienstleisters haben wir es endlich.
Herausfoderung war, dass wir mit Ivanti DSM noch arbeiten und es bei denen wohl nicht vorgesehen ist, die PXE Umgebung zu aktualisieren.
Weitere "Hürde" war, dass im neusten ADK die x86 Sourcen fehlen (ohne Kommentar) obwohl es in der Install GUI noch angezeigt, dass es installiert wird.
Das Problem tritt wohl auch bei SCCM auf wenn man die PXE Umgebung aktualisieren will.
VG
Hallo Leidensgenossen,
irgendwie blicke ich da nicht mehr durch.
Sind die Dynamic SafeOS Updatse welche das WinRE fixen sollen (KB5028311, KB5028312, KB5028314 richtig?) zusammen mit dem letzten monatlichen Rollup gekommen oder müssen die wieder wie bei der Bitlocker Geschichte manuell integriert werden?
Danke und Grüße,
Martin