Microsoft hat Windows mit dem BitLocker eine Laufwerksverschlüsselung verpasst, die auch physischen Angriffen standhalten soll, also auch die Fälle abfangen soll, bei denen etwa Geräte geklaut werden. Immer wieder werden jedoch Schwachstellen bekannt, etwa durch Auslesen der Secrets im TPM des Rechners. Eine weitere aktuell weitreichend funktionierende Variante setzt auf die Windows Recovery Environment (WinRE).

Microsoft selbst hat zuletzt im Mai 2025 mit „BitUnlocker“ derartige Attacken über WinRE dokumentiert – und Updates veröffentlicht, die davor eigentlich schützen sollen. IT-Forscher von Intrinsec haben nun einen Weg entdeckt, mit dem sich der Schutz abermals aushebeln lässt, wieder mittels WinRE. Für die Praxisrelevanz der Angriffe ist wichtig zu wissen: Zum Aushebeln der BitLocker-Verschlüsselung ist physischer Zugriff nötig.

BitUnlocker-Angriffe

Die von Microsoft vorgestellte Angriffskette startet laut der IT-Forscher damit, dass der Boot-Manager das System Deployment Image (SDI) und die darin referenzierte WIM-Datei (Windows Image Format) lädt und die Integrität der WIM prüft. Durch das Hinzufügen einer weiteren WIM im Blob-Table prüft der Boot-Manager die erste WIM-Datei, lädt aber ungeprüft die zweite, die von Angreifern kontrolliert wird. Die zweite WIM enthält ein WinRE-Image, das eine cmd.exe-Datei starten kann, die bei Ausführung Zugriff auf das entschlüsselte BitLocker-Laufwerk ermöglicht. BitLocker wurde im weitreichend eingesetzten Auto-Unlock-Mode beim Start durch die bestandene Prüfung entsperrt (CVE-2025-48804, CVSS 6.8, Risiko „mittel“).

Im Juli 2025 hat Microsoft aktualisierte Boot-Manager verteilt, die das Problem lösen sollen. Der ist mit den PCA-2011- oder CA-2023-Secure-Boot-Zertifikaten signiert. Das nun gefundene Sicherheitsleck besteht darin, dass Secure Boot lediglich das Zertifikat einer Binärdatei prüft, jedoch nicht ihre Version. So lässt sich eine anfällige „bootmgfw.efi“-Datei vor dem Sicherheitsupdate starten, die mit dem PCA-2011-Zertifikat signiert ist – die ist aus Secure-Boot-Sicht genauso gültig wie die gepatchte Fassung.

Die Secure-Boot-Zertifikate lassen sich nicht einfach so zurückziehen, das wird auch gerade bei dem Auslaufen der alten 2011er-Zertifikate sichtbar. Microsoft müht sich redlich, die Zertifikate zu aktualisieren und liefert insbesondere für Admins in Unternehmensnetzen auch reichlich Hilfestellung, damit das Upgrade zügig erfolgen kann. Solange diese aktualisierten Zertifikate nicht verteilt und die veralteten Zertifikate zurückgezogen wurden, ist ein Angriff mit einem veralteten Boot-Manager (Downgrade-Attacke) möglich. Die IT-Forscher stellen auf GitHub auch einen Proof-of-Concept (PoC) bereit, der die Schwachstelle demonstriert. Der Angriff benötigt nur Minuten und kein komplexes Equipment, sondern etwa lediglich einen USB-Stick und physischen Zugriff.

Um den Schutz vor derartigen Angriffen zu verbessern, empfehlen die IT-Sicherheitsforscher, die Funktion der PIN-Abfrage beim Start zu aktivieren – das verhindert die meisten BitLocker-Angriffe. Das sei die einzige Maßnahme, die verlässlich vor diesen Angriffen schütze. Microsoft empfiehlt zudem, den Boot-Manager auf das CA-2023-Zertifikat zu migrieren und das alte PCA-2011-Zertifikat zurückzuziehen. Eine Anleitung von Microsoft aus dem Jahr 2023 erklärt den Vorgang. Das aktiviert demnach auch das Versionstracking mittels Secure Version Number (SVN). Da diese Gegenmaßnahmen etwas umständlich seien, sind sie nicht sehr weit verbreitet.

Dieser Angriff dürfte sich jedoch mit dem Ablaufen der alten PCA-2011-Zertifikate im Oktober 2026 erledigen. Der vorgestellte Angriff zeigt jedoch einmal mehr, dass der Umzug auf die neuen Secure-Boot-Zertifikate rasch erfolgen sollte.

(dmk)

Von Microsoft als „kritisch“ eingestufte Sicherheitslücken bedrohen unter anderem Azure, M365, Office, SharePoint, Windows und Word. In vielen Fällen können Angreifer Schadcode auf Computer schieben und so Systeme vollständig kompromittieren.

Admins sollten sicherstellen, dass die Windows-Update-Funktion aktiv ist und Systeme auf dem aktuellen Stand sind. Andernfalls sind PCs verwundbar. Bislang gibt es keine Berichte, dass Angreifer bereits Schwachstellen ausnutzen.

Kritische Lücken

Am bedrohlichsten gilt eine „kritische“ Lücke (CVE-2026-42826) mit dem höchstmöglichen CVSS Score 10 von 10 in Azure DevOps. An dieser Stelle können Angreifer auf einem nicht näher ausgeführten Weg auf eigentlich geschützte Informationen zugreifen. Microsoft gibt an, die Schwachstelle serverseitig gepatcht zu haben. Admins müssen an dieser Stelle also nichts tun.

Weitere „kritische“ Schwachstellen betreffen unter anderem Azure Managed Instance for Apache Cassandra (CVE-2026-33109), Microsoft Dynamics 365 On-Premises (CVE-2026-42898) und den DNS-Client in Windows (CVE-2026-41096). Im letztgenannten Fall können entfernte Angreifer ohne Authentifizierung über eine präparierte DNS-Anfrage Speicherfehler auslösen, sodass Schadcode auf Computer gelangt. Davon sind verschiedene Windows-11- und Server-Ausgaben betroffen.

Sicherheitslücken aufspüren

An diesem Patchday hat Microsoft insgesamt knapp 140 Sicherheitsprobleme gelöst. In einem Beitrag gibt das Unternehmen an, dass ein Großteil der Schwachstellen mithilfe mehrerer KI-Agenten entdeckt wurde.

Weiterführende Informationen zu den Schwachstellen und bedrohter Software findet man in Microsofts Security Update Guide.

(des)

Google verbaut in seinem Browser ein lokales KI-Modell, das Funktionen wie Betrugserkennung datenschutzfreundlicher ausführen soll. Eine eigene Javascript-API (Application Programming Interface) wird zudem Webseiten erlauben, mit dem Modell zu interagieren. Nun wirft eine Änderung in den KI-Einstellungen bei Chrome 148 Fragen auf: Funkt die lokale KI nach Hause und verrät dem Suchmaschinenriesen private Daten?

Vor wenigen Tagen berichteten verschiedene Medien über das Tohuwabohu um ungefragt heruntergeladene Daten, nun verglichen Redditoren die Konfigurationseinstellungen der lokalen KI zwischen Chrome 147 und dem kürzlich erschienenen Chrome 148. Sie fanden heraus, dass ein kurzer, aber wichtiger Halbsatz fehlt.

Deine Daten an Google-Server?

Hieß es in Chrome 147 noch: „[..] KI-Modelle verwenden, die direkt auf deinem Gerät ausgeführt werden, ohne deine Daten an Google-Server zu senden“, fehlt der letzte Halbsatz in der aktuellen Chrome-Version. Wir konnten das auf einem Redaktionsgerät mit macOS nachvollziehen, die Option findet sich in den Systemeinstellungen des Browsers (chrome://settings/system).

Der Zweck der Änderung ist unklar. Womöglich möchte sich Google tatsächlich das Recht einräumen, die lokale KI durch Ergebnisse der cloudbasierten LLM anzureichern, womöglich handelt es sich auch um die Vorbereitung auf das „Prompt API“, das man in Mountain View offenbar derzeit im Eiltempo in den Browser einbaut.

Skeptiker können das lokale KI-Modell abschalten, Google merkt jedoch in der Chrome-Hilfe an: Das spare zwar Speicherplatz, schränke aber KI-basierte Leistungsmerkmale ein. Das könnten etwa Hilfen beim Schreiben oder Umschreiben sein, Betrugswarnungen, Ordnung in Browsertabs oder Zusammenfassung von Webseiten.

(cku)