Im Juli 2025 hat Microsoft Sicherheitsupdates für Windows freigegeben, um eine Bitlocker-Schwachstelle zu schließen, die eine Bitlocker-Downgrade-Attacke ermöglicht. Jetzt haben Sicherheitsforscher gezeigt, dass ein Bitlocker-Downgrade-Angriff auf Windows 11 möglich ist. Hängt mit den PCA 2011-Zertifikaten zusammen. Das Ganze erfordert aber Zugriff auf das lokale System.
Bitlocker-Sicherheitsupdates von 2025
Im August 2025 hat Microsoft im Artikel BitUnlocker: Leveraging Windows Recovery to Extract BitLocker Secrets einen BitUnlocker-Angriff beschrieben. Der verwendet die Windows-Wiederherstellung (Win RE-Umgebung) zum Extrahieren von BitLocker-Schlüsseln und damit zum Zugriff auf Bitlocker-Laufwerke. Und zum 8. Juli 2025 gab es einen Patch zum Schließen der Windows Security Feature Bypass-Schwachstelle CVE-2025-48804 in BitLocker.
Der Patch reicht nicht aus
Es hat sich nun herausgestellt, dass die oben erwähnten Sicherheitsupdates vom Juli 2025 nicht ausreichen, um diesen Bitlocker Downgrade-Angriff zu verhindern. Ich bin über nachfolgenden Tweet auf diesen Sachverhalt gestoßen, den Cyber Security News hier aufbereitet.
Die Details eines Bitlocker-Downgrade-Angriffs haben die Sicherheitsspezialisten von Intrinsec bereits am 5. Mai 2026 im Artikel BitLocker bypass: the reality of downgrade attacks beschrieben. Die Spezialisten verweisen auf den oben erwähnten Microsoft-Beitrag und den Patch vom Sommer 2025, der eine Bitlocker-Schwachstellen schließen soll.
- Die Angriffskette gegen BitLocker nutzt die WinRE-Umgebung aus. Der Boot-Manager lädt die System Deployment Image (SDI)-Datei und die darin referenzierte WIM-Datei und überprüft die Integrität der legitimen WIM-Datei.
- Das Problem: Wird jedoch eine zweite WIM-Datei mit einer modifizierten Blob-Tabelle zur SDI-Datei hinzugefügt, überprüft der Boot-Manager die erste (legitime) WIM-Datei, während gleichzeitig von der zweiten (vom Angreifer kontrollierten) WIM-Datei gebootet wird.
Diese zweite WIM-Datei könnte nun ein mit `cmd.exe` infiziertes WinRE-Image enthalten, das auf dem entschlüsselten BitLocker-Volume ausgeführt wird und somit an die Geheimnisse und Daten herankommt.
Der Patch vom Juli 2025 ersetzt einen gepatchten Bootmanager über Windows Update, unabhängig davon, ob dieser mit PCA 2011 oder CA 2023 signiert war. Das Problem liegt woanders: Secure Boot überprüft nur das Signaturzertifikat einer Binärdatei, nicht deren Version. Eine anfällige `bootmgfw.efi` aus der Zeit vor Juli 2025, die mit dem PCA 2011-Zertifikat signiert ist, ist aus Sicht von Secure Boot genauso gültig wie die gepatchte Version.
Soweit ich es verstanden habe, besteht aber das Problem, dass das alte PCA-2011-Zertifikat jedoch nicht pauschal widerrufen wurde ( da dies für Microsoft eine echte operative Herausforderung darstelle). Das alte Zertifikat nach wie vor in der Secure-Boot-Datenbank fast aller im Einsatz befindlichen Rechner vorhanden (mit Ausnahme neuer Windows-Installationen). Und solange das Zertifikat nicht widerrufen wird, kann sogar ein alter, anfälliger Boot-Manager geladen werden, ohne dass eine Warnung ausgelöst wird.
Genau in diesem Bereich setzt der BitUnlocker-Angriff an. Der Angreifer benötigt zwar Zugriff auf den Rechner, um die WinRE-Umgebung zu manipulieren. Aber ein Angriff auf Bitlocker wäre möglich. Nur wenn das neue PCA 2023-Zertifikat auf dem Rechner vorhanden und das alte PCA-2011-Zertifikat gelöscht wurde, ist der Rechner gegen diesen Angriff geschützt. Insgesamt stufe ich das obige Szenario für den praktischen Betrieb als eher unkritisch ein, da einige Randbedingungen wie Zugriff auf den Rechner erforderlich sind. Details sind den verlinkten Beiträgen zu entnehmen.
MVP: 2013 – 2016
Unkritisch.
Wie jeder Angriff gegen Bitlocker: Das ist nur bei TPM ONLY erfolgreich.
TPM+PIN hat bis jetzt jedem Angriff standgehalten.
https://cybersecuritynews.com/bitunlocker-downgrade-attack-on-windows-11/
[…] Machines configured with TPM + PIN are protected, as the TPM will not unseal the VMK without user interaction during pre-boot authentication.
Wer verwendet in der Realität TPM+PIN?
Menschen die verstehen warum ein TPM ohne PIN keinen Sinn ergeben kann. Wenn das TPM pinlos die Keys ausspuckt, dann kann man sich TPM ja gleich schenken. (SPI/I2C readout, logic analyzer für den geneigten Leser)
jeder, der Bitlocker einsetzt, damit das System sicher ist.
die Angriffe gg TPM sind schon 10(?) Jahre alt und erfolgreich. mit anderen Worten, deiner Cyberversicherung ist klar, das TPM only, fahrlässig ist und sie werden nicht zahlen.
Wir in der IT für die PAWs, sonst aber nicht. Das Problem am PIN ist auch, dass bestimmte Dinge wie ein remote Reboot (Updates) oder WOL nicht mehr funktionieren. Wenn ich alle PCs für die Updates geplant remote einschalten kann, dann hilft das schon deutlich weiter den Patchday zügig umzusetzen. Ist am Ende einen Sache der Abwägung wie kritisch die lokalen Daten sind.
Für WOL und remote reboot bei Servern/Desktops gibt es Network Unlock. (Bei Laptops etc. sollte ja eh irgendwo ein User in der Nähe sein.)
TPM mit zusätzlicher PIN schützt nicht, schreibt "Chaotic Eclipse", der Entdecker von YellowKey:
"No, TPM+PIN does not help, the issue is still exploitable regardless, I asked myself this question, can it still work in a TPM+PIN environment ? Yes it does, I'm just not publishing the PoC, I think what's out there is already bad enough."
*ttps://deadeclipse666.blogspot.com/2026/05/were-doing-silent-patches-now-huh-also.html?m=1
Er hat also einen Weg gefunden, um Bitlocker trotz zusätzlichem PIN-Schutz auszuschalten, aber er wird diesen Prove-of-Concept nicht veröffentlichen, weil YellowKey bereits jetzt schon gefährlich genug ist.
Diese Info könnte man im Artikel ergänzen.
Wenn ich wieder fit bin, trage ich es nach.
Das Thema ist auch schon auf dem letzten CCC demonstriert worden.
BitUnlocker: Leveraging Windows Recovery to Extract BitLocker Secrets
—
GB: Hab mir jetzt die Videos nicht angesehen – vom Gefühl her war dort die Ausnutzung der Sicherheitslücken für Bitlocker-Downgrade der Hebel. Oben wird dann bei gepatchten Systemen das alte PCA-2011-Zertifikate-Problem als weiterer Angriffsvektor missbraucht. Aber vielleicht war es auf dem 39C3 auch schon in der Diskussion. Danke für den Hinweis.
Anal plug & cheating & chess contest….
Rubbel dich glücklich! (kein adult entertainment / nur werbung fiur Rubbelllose… aka Lotterie am Kiosk ohne …).
Jeder weiss wem er vielleicht im analogen Leben oder im "digital trusted" dem Gefaengnisgeneralschluesel Maintainer-persona in Euskirchen) aka pentester from 636 cocain…).
Im Hotel weiss jeder dass generalschluessel, das Zimmermaedchin und den ganzen anderen Kram gibt. Im digitaen room Erst den serioesen Pentester (Banken etc. dann wechsel der Rolle; ich sag jetzt nur "Hacking Team". Manche altern mit ihren Idolen und ergrauen (grey hats) manche erliegen dem Buntem (german ex BW-Pilots migrate to China).
digital first, Bedenken second, wie es Herr Ustinov süffisant sagte: die erogenen Zonen wandern nach oben: Foodporn & Co.; und um diese abtruennige Zielpersona in China zu tracken: Wie bei der RAF, manche geistigen Nahrungsmittel (bestimmte Auslandspublikationen gibts nur abroad bei bestimmten Print resellern; bestimmtes german Food nur bei bestimmten …).
Bitlocker ohne PIN war schon immer Mist.
Wir nutzen BitLocker ausschließlich NUR mit TPM und bewusst OHNE PIN.
Und wir bewusst NUR mit PIN
Dazu muss man aber erstmal das Recht haben, eine zweite WIM Datei in die Recovery-Partition rein zu tun. Und sie muss dafür groß genug sein, meistens sind die ja schon jetzt schon etwas knapp bemessen. Aber wenn man dafür schon Rechte hat, braucht dieser Angriffsvektor schon garnicht mehr verwendet zu werden, an der Stelle hat man schon ganz andere Möglichkeiten.
Frage eines Laien:
Ich lese immer UEFI-Zertifikate und TPM, also denke ich an das System-Laufwerk C:.
Wie ist das mit Nicht-System-Datenträgern, die Bitlocker-(to-go)-verschlüsselt sind, aber per separatem Kennwort entsperrt werden (keine automatische Entsperrung durch Bitlocker-geschütztes Windows)?
Besteht hier Gefahr? Es ist ja unabhängig von einem bestimmten Rechner, kann es ja per Kennwort "überall" öffnen, sogar mit Linux.
Wenn du keine automatische Entsperrung aktivierst, wird das Kennwort (aus dem der Schlüssel abgeleitet wird) auch nirgends gespeichert. Hier sehe ich keine Gefahr.
Near the end of this blog post it states, "The computer is only protected against this attack if the new PCA 2023 certificate is present and the old PCA 2011 certificate has been deleted."
Wouldn't the computer also be protected if the Recovery Environment were to be disabled? I almost never use the RE, and if I need to I can boot from a Win11 USB drive and punch in the bitlocker key manually if I needed to, so I'd think this would be a good way to proceed. I seem to recall this was the mitigation for the problem when Microsoft brought out the initial fix for this last year and had all sorts of problems applying it to Win10 machines.
Maybe I'm missing I'm off-track or something…?
@Rich:
Yes, disable WinRE and you're protected. No real need for WinRE, anyway.
Das 'Microsoft Windows Production PCA 2011' wird weder widerufen noch gelöscht.
Es kann schon seit 2023 zusätzlich in die UEFI Variable dbx gespeichert werden. Damit ist dann lediglich der UEFI Bootvorgang damit unterbunden.
Weil mit diesem Zertifikat aber auch fast alles andere in Windows signiert ist und nicht alle BIOS/UEFI sich auf 'Windows UEFI CA 2023' umstellen lassen werden wird es uns trotzdem noch viele Jahre begleiten.
Viel zusätzliche Sicherheit dürfte das alles auch nicht bringen…
Was macht ein nicht nur durch Falcon sondern auch immer wieder Microsoftbugs gut konditionierter User wenn er mangels Bitlocker-TPM-Key stattdessen im WINRE nach dem Bitlocker-Recoverykey gefragt wird? Er sucht ihn brav heraus und gibt ihn dann – wie auch Julia Klöckner – halt ein und der Angreifer sagt Danke, weil der auch ganz ohne TPM alleine funktioniert.
Eigentlich braucht er ihn in aller Regel aber garnicht mehr. Wer die WINRE manipulieren kann hat bereits erweiterte Administatorrechte und kann den Recoverykey mit bde-manager problemlos jederzeit auslesen und anzeigen lassen.
Das ganz "tolle" an dem neuartigen Quick Machine Recovery Mode ist, dass ein Angreifer damit auch in WinRE die Netzzugangsdaten hat. Ob das mal wirklich zu Ende gedacht ist und am Ende mit dem Nachhausetelefonieren zu Microsoft für den Recoverykey nicht noch viel größere Löcher aufgerissen werden wie derzeit mit dem nicht wirklich sinnvollem TPM ohne PIN statt nur einem vernünftig langem Passwort alleine.
Non sequitur.
Geschützter Bootvorgang ist in etwa wie elektronische Wegfahrsperre/Zündung.
Das es noch Angriffe *nach* dem Bootvorgang gibt ist in etwa so wie zu sagen "elektronische Wegfahrsperren sind sinnlos", weil jemand könnte einen ja aus dem laufendem, entsperrten Auto zerren und damit wegfahren.
Ein reines Passwort für eine TPM-lose Festplattenverschlüsselung erreicht auch niemals die Entropie des sealed keys im inneren eines TPM. TPM garantiert über internes RTC, timeouts (10 min, wenn erforderlich) und sperre nach zu viel falscheingaben, dass der sealed key unbrauchbar wird.
Auch frage ich mich was dual signing von binaries im laufenden OS mit dem Bootvorgang zu tun hat. Faktisch ist alles was nur mit dem alten cert signiert ist dank der dbx wertlos *für den bootvorgang*.
"Was nicht vorwärts gehen kann, schreitet zurück" (j.w. von goethe) Begleiten tut mich das alte cert gar nicht. Ebenso muss ich mich fragen warum das alles (sogar) auf meinem DELL Inspiron mit 2019er UEFI trotzdem ging (wenn man will).
Das sind allerdings nur rhetorische Fragen als Stilmittel.