[English]Noch ein kleiner Nachtrag vom Wochenende – auf dem 38C3-Kongress des Chaos Computer Clubs hat Thomas Lambertz, ein Sicherheitsexperte, gezeigt, wie sich Microsofts Bitlocker-Verschlüsselung über ein "Downgrade" einer gepatchten Schwachstelle aushebeln lässt. Der Weg, über den Geheimdienste oder Strafverfolger an verschlüsselte Daten herankommen.
Anzeige
Microsoft propagiert ja die Verschlüsselung der Datenträge von Windows-Systemen mittels Bitlocker. Das soll vertrauliche Daten vor unbefugten Dritten schützen. Für Nutzer kann Bitlocker aber einige Hürden bieten (siehe Links am Artikelende, sowie folgenden Screenshot aus aus der 38C3-Session).
Probleme mit Bitlocker, Screenshot bei 45:13 aus dem Vortrag auf dem 38C3, u.a. mit Referenz auf meinen Beitrag Windows 10/11 updates (e.g. KB5040442) trigger Bitlocker queries (July 2024)
Zudem fällt auf, dass Bitlocker immer wieder durch Schwachstellen glänzt, die das Aushebeln der Verschlüsselung ermöglicht. Ich hatte beispielsweise im Beitrag Windows Bitlocker-Verschlüsselung trotz TPM ausgehebelt über eine solchen, allerdings aufwändigeren, Ansatz berichtet.
Forensik-Unternehmen wie Cellebrite, die Strafverfolger unterstützen, oder Geheimdienste und Justiz haben aber wohl Wege gefunden, wie sie verschlüsselte Datenträger über verschiedene Ansätze entschlüsseln können. Es war also nur eine Frage der Zeit, bis Sicherheitsforscher einen genauen Blick auf Bitlocker werfen würden.
Anzeige
Bitlocker per Software ausgehebelt
Sicherheitsexperte Thomas Lambertz hat auf dem 38 Chaos Computer Congress (38C3) eine Session mit dem Titel Windows BitLocker: Screwed without a Screwdriver gehalten, in dem er zeigte, wie er über eine Windows-Schwachstelle und ein modifiziertes Linux auf ein verschlüsseltes Bitlocker-Laufwerk unter einem aktuellen und voll gepatchten Windows 11 zugreifen kann, ohne den Wiederherstellungsschlüssel zu kennen.
Hintergrund ist die Microsoft Bitlocker-Implementierung zur vollständigen Verschlüsselung eines Volumens (Datenträger, Partition), die mehrere Betriebsmodi bietet. Am häufigsten wird die Secure Boot-basierte Verschlüsselung von Privat- und Firmenkunden verwendet. Bei neueren Windows 11-Installationen wird standardmäßig die sogenannte Geräteverschlüsselung aktiviert (siehe auch Windows 10/11 Home-Edition und die OEM Bitlocker-Falle).
In diesem Modus ist die Festplatte im Ruhezustand durch Bitlocker verschlüsselt, wird aber automatisch entsiegelt, wenn ein rechtmäßiges Windows hochgefahren wird. Der Benutzer benötigt kein separates Entschlüsselungskennwort, da dieses beim Secure Boot aus dem TPM übernommen wird. Die Anwender müssen sich lediglich an ihrem normalen Windows Benutzerkonto anmelden.
Die spannende Frage ist nun: Ist es möglich, auf die Daten der Bitlocker-verschlüsselten Geräte zuzugreifen, ohne das Passwort zu kennen? Im Vortrag auf dem 38C3 wurde demonstriert, wie die BitLocker-Verschlüsselung auf einem aktuellen Windows 11-System mit Secure Boot umgangen werden kann.
Das ist trotz Absicherung durch Secure Boot möglich, weil sich eine wenig bekannte Software-Schwachstelle – bitpixie (CVE-2023-21563) – ausnutzen lässt. Diese Schwachstelle wurde zwar im November 2022 durch Microsoft gepatcht (bekannt ist das seit 2023). Aber CVE-2023-21563 lässt sich heute noch mit einem Downgrade-Angriff zur Entschlüsselung von BitLocker nutzen.
Konkret wird unter Secure Boot ein veralteter Windows Boot-Loader geladen, um Windows im abgesicherten Modus zu starten. Dadurch gerät der Bitlocker- Wiederherstellungsschlüssel (als Volume Mount Key, VMK, bezeichnet) in den Arbeitsspeicher des Rechners.
Dann wird ein Linux-System auf einem zweiten Rechner, der per LAN mit dem ersten Windows-Rechner verbunden ist, per Secure Boot gestartet. Über das Netzwerk wird ein Memory-Dump des Windows-Arbeitsspeichers angefertigt. Dort lässt sich dann der benötigte Schlüssel zum Mounten des Bitlocker-Laufwerks extrahieren. Schon hat man Zugriff auf die Daten des Bitlocker-Laufwerks, ohne jemals das Anmeldepasswort des Nutzers oder den Wiederherstellungsschlüssel bekommen zu haben.
Die Details lassen sich in der unter Windows BitLocker: Screwed without a Screwdriver abrufbaren Aufzeichnung der Session von der 38C3 nachschauen (einige Informationen aus dem Video sind hier aufbereitet).
Ähnliche Artikel:
Microsoft bestätigt Bitlocker-Abfragen durch Windows Juli 2024-Updates
Windows 10/11 Updates (z.B. KB5040442) triggern Bitlocker-Abfragen (Juli 2024)
Windows-Bitlocker-Abfrage-Bug durch August 2024-Updates korrigiert
Windows 10/11 Home-Edition und die OEM Bitlocker-Falle
Windows-Frage: Wo speichert Bitlocker den Recovery-Key?
Bitlocker über TPM binnen 42 Sekunden mit Raspberry Pi Pico ermittelt
Windows 10/11: Microsoft veröffentlicht Fix für OOBE-Bitlocker-Ausfall-Bug
Windows 10/11: Microsoft veröffentlicht Script für den WinRE BitLocker Bypass-Fix
Windows 10: Neues zum WinRE-Patch (Fix der Bitlocker-Bypass-Schwachstelle CVE-2022-41099)
Anzeige
Sehe ich das richtig:
Das ist nicht möglich, wenn bei Bitlocker ein Kennwort eingerichtet ist, dass schon beim Starten des Computers abgefragt wird?
korrekt, wen Bitlocker mittels Preboot PIN abgesichert ist kann dies nicht ausgehebelt werden
Mit PIN wird das Laufwerk nicht entschlüsselt, bevor der PIN eingegeben wird – dann klappt der Angriff nicht. Aber wie häufig wird das eingesetzt?
Ohne PIN ist Bitlocker nur Spielzeug, das ist aber nicht wirklich neu.
Es ist ja alles schön und gut. Wenn ihr die Benutzer dahin bekommt, dass die mit PIN jedes Mal das System samt Bitlocker entsperren, ok. Wer aber genau den Beitrag anschaut, wird auf meinen verlinkten Beitrag zur automatischen Geräteverschlüsselung bei Windows Home stoßen. Sprich: Viele Nutzer wissen nicht mal, dass da ein Bitlocker werkelt.
denen ist es egal, da sie die Platte nicht verschlüsseln wollten.
da ist es kein Unterschied ob esunverschlüsselt oder verschlüsselt offen ist
Unsere über 500 Desktop/Laptopnutzer tippen den Bitlocker-Key bei jedem Start ein. Ausnahme: Reboot bei Windows-Updates, zumindestens wenn das Updates mit nur 1 Reboot durch ist. Das wurde auch von niemandem in Frage gestellt. Bei meiner Frau im Konzern, bei dem jeder Leser hier sicher schon eingekauft hat, also Tausende Mitarbeiter, ist es eine vergleichbare Verschlüsselung von Trellix, aber ich glaube, diese Lösung setzt tatsächlich sogar auf das AD-Passwort.
Hier eben falls. 200 User tippen die BL-PIN selbst ein.
Bei uns im Betrieb wird das flächendeckend auf allen mobilen Geräten so eingesetzt.
Wie muss ich mir diese PIN vorstellen? Wenn diese sehr kurz ist, ist dann Bruteforce ein mögliches Scenario? Bei beispielsweise vier Stellen wäre die Anzahl der Möglichkeiten doch arg eingeschränkt. Was passiert bei vielen Fehleingaben?
Von Veracrypt kenne ich es so, dass man ein komplexes Passwort eingeben muss, welches mindestens 20 Zeichen haben sollte. Dazu kommt dann noch ein Parameter PIM (Personal Iterations Mutator), welcher die Anzahl der Hashrunden für das Passwort steuert. Das erschwert Bruteforce zusätzlich, da:
a) Jedes Passwort mit jeder denkbaren PIM getestet werden müsste
b) Die Zeit für die Hashberechnung bei hohen PIM-Werten immer weiter steigt
Für mich als Nutzer eines PC sind 5 Sekunden Wartezeit für die Prüfung des Passwortes sicherlich verschmerzbar, Bruteforce bremst dies aber schon deutlich aus.
Ich bin mir nicht mehr ganz sicher, aber nach 3 oder 5 falschen Versuchen wird der Wiederherstellungsmodus aktiviert.
Bitlocker fordert dann den Wiederherstellungsschlüssel einzugeben. Dieser Schlüssel ist ein 48-stelliger Code den man hoffentlich/irgendwo gespeichert/gesichert hat.
Also Brute Force mit x-mal rumprobieren nützt da nichts, oder?
Für mich ist Bitlocker mit Prebot PIN genügend sicher gegen einen normalen Diebstahl des Laptops.
Natürlich mit einem guten Password mit grossen, kleinen Buchstaben und Zahlen gemischt. Ein Satz den man sich gut merken kann.
Die Bezeichnung PIN täuscht(?), man kann per GP (Computer Configuration | Administrative Templates | Windows Components | BitLocker Drive Encryption | Operating System Drives | Allow enhanced PINs for startup) einstellen, dass (längere) alphanumerische Passworte genutzt werden können.
Fast. "enhanced" erlaubt auch Zeichen, statt nur Zahlen.
per Default ist eine PIN ohne die Richtlinie nur eine PIN aus Zahlen
Es sollte reichen, das Booten von anderen Datenträgern im BIOS zu verbieten und dieses mit Admin-Kennwort zu schützen. Zumindest in meinem ASUS Zenbook braucht man einen Lötkolben und noch viel mehr, wenn man das vergessen hat…
Das funktioniert allerdings wohl nur auf den wenigsten oder sehr modernen Computern.. Denn die meisten älteren haben die Möglichkeit, das BIOS-Kennwort zu löschen durch Tasterdruck oder Jumper. Nur die wenigsten erfordern offiziell den Austausch der Hauptplatine. Und aktuell sitze ich auch an einem Wohnzimmer-PC, der nur ein ASUS ZenScreen, also Touchscreen hat (nur USB-C mit DP inkl. Stromversorgung, Audio, Onscreen-Tastatur und -Maus). Dort kann ich nicht wirklich einen Bioskennwort vergeben oder eine PIN schon vor dem Booten eingeben lassen. Dann müsste ich zusätzlich eine USB-Tastatur extra nur dafür angeschlossen haben. Daher hoffe ich, dass Microsoft das Problem irgendwann fixt, sodass also Computer wie Laptops, die zum Beispiel aus dem Auto gestohlen werden und die einfach nur Bitlocker verschlüsselt sind, nicht hackbar sind.
"Das funktioniert allerdings wohl nur auf den wenigsten oder sehr modernen Computern."
Nein, das funktioniert seit 'ewig': Zuvorderst muss die HDD/SSD-Firmware es unterstützen (das BIOS (heute: UEFI) natürlich ebenfalls (die Passwortabfrage und Weitergabe an die Disk)). Ich habe das nie benutzt (FDE-Fan¹), aber die Funktion "HDD-Passwort" ist seit sicher 20J verfügbar.
Bzgl. Bitlocker:
MS unterstützt damit die Bequemen und wenn man den Aufwand für den Angriff betrachtet ist es weit besser als Nichts.
Wer das will kann aber Bitlocker mit PBA einrichten (oder man nutzt gleich Veracrypt und kaskadierte Verschlüsselung ;) )
¹ bei "nur HDD-Passwort" ist im Labor ("Datenretter") der Platteninhalt restaurierbar (da Klartext), nur der Controller verweigert ohne Pw den Zugriff darauf
@formwandler – ich würd' weiter differenzieren. Dabei ist Dein Frage-Begriff "beim Starten" wichtig. Bei Boot ist Eingabe von PIN oder Passphrase beim hier diskutierten Vorgehen als Bitlocker mit TPM zu verstehen (also TPM/BIOS-gesteuert), irgendwo muss das Passwort abgeglichen werden… Ebenso ist kein öffnen des Gerätes der Charme dieser Attacke. Es kommt meiner Erfahrung nach auf eine ganze Kette von Dingen an:
Mögliche BruteForces und Hintergrundinfo bietet zB Video Unsicherheit Hardwarebasierter HDD Verschlüsselung vom 29C3. Ab Minute 25:00 gibt es eine gute Übersicht.
Generell erschwert ein zusätzliches Kennwort den Zugriff. Teilweise nutze ich doppelt: "FDE Encryption mit Passwort" – dazu einen Veracrypt Container mit (zweitem) Passwort. Dies kostet etwas Performance. Für Firmen werte ich dies jedoch wenig Praxisnah.
Ein Schelm wer dabei Böses denkt.
Einfach den Bitlocker-Kram vergessen!
Wer seine Daten sicher verschlüsseln will, nimmt statt dessen EFS.
EFS gibts schon seit Windows 2000 und ist bis heute nicht geknackt worden.
Und EFS bietet den Vorteil, das man auch einzelne Dateien und Ordner verschlüsseln kann.
EFS bietet keine Full Disk Encryption. EFS verwendet ein Nutzer-Zertifikat, welches für die Verschlüsselung und Entschlüsselung der Daten verwendet wird. Diese Schlüssel liegen in der Windows Zertifikatsverwaltung. Die Sicherheit der Verschlüsselung hängt damit am Windows Passwort des Nutzers, denn der Zugriff auf die Daten erfolgt transparent ohne Passwortabfrage. Auf jeden Fall sollte man dieses Zertifikat exportieren, um es später z.B. auf einem anderen PC neu importieren zu können. Das ist für den üblichen Anwender sicherlich eine Hürde und nicht unbedingt bekannt. Selbst wenn man auf einem neuen PC einen identischen User mit gleichem Passwort anlegt, so sind die Daten ohne das Zertifikat verloren. EFS Keys können auch per Gruppenrichtlinien in der Domäne verwaltet werden. Ein Domain-Admin ist durchaus in der Lage Zugriff auf das Zertifikat und die Daten zu erhalten. Auch kann die Verwaltung komplex / problematisch werden, wenn mehrere User mit solchen Dateien arbeiten sollen (z.B. bei Netzwerkfreigaben).
zudem sind geöffnete, bearbeitete EFS Dateien mit Recovery Tools wiederherstellbar, da die temp Dateien unverschlüsselt sind
Natürlich ist ein User, den man identisch auf einem anderen PC anlegt, NICHT identisch!
Denn was viele nicht wissen:
Hinter dem Benutzernamen verbirgt sich die sog. SID (Security ID) und die ist immer anders. Denn die wird bei Anlage des Users per Zufallsgenerator erzeugt.
Also 2 User mit identischen Daten angelegt auf 2 PCs haben unterschiedliche SIDs. Und alle Sicherheitseinstellungen fragen ausschließlich die SID ab, nicht den Benutzernamen!
Das sieht man auch schön, wenn man z.B. mal einem Benutzer explizit Rechte auf eine Datei erteilt und dann den Benutzer löscht.
Dann erscheint in den Sicherheitseinstellungen die SID des gelöschten Benutzers, denn durch die Löschung des Benutzers wird die Verknüpfung des Benutzernamens mit der SID ebenfalls gelöscht.
Und deshalb kann man Benutzeraccounts auch nicht einfach durch Neuanlage des Benutzers wieder herstellen. Der neu angelegte Benutzer hat dann zwar den gleichen Namen und Passwort, aber eine andere SID.
Nicht mal auf dem selben PC oder im selben AD identisch, wegen unterschiedlicher SID. Und das mit der Sichtbarkeit der SID von gelöschten Usern in den ACLs im Filesystem ist auch so eine Unsitte. Man macht im Filesystem oder Shares keine Direktberechtigungen auf User. Man macht Berechtigungen immer nur auf AD-Gruppen (nichtmal lokale Gruppen) und legt dort die AD-Benutzer rein. Direktberechtigungen sind "böse", weil es durchaus mal passieren kann, dass ein späterer Benutzer diese SID zufälligerweise mal wieder bekommt, die Wahrscheinlichkeit ist zwar ähnlich hoch wie ein Lottogewinn, aber der bekommt dann in unbereinigten Dateisystemen oder Shares diese alten Berechtigungen, und wenn das vorher ein Zugang nur für einen Admin war, dann ist das halt so… Haltet euren Laden sauber!
Ps.: PowerShell Tipp:
https://community.spiceworks.com/t/powershell-sid-to-user-and-user-to-sid/1005944
Frohes Neues!
NEIN.
eine doppelte Vergabe von SIDs, genau genommen RIDs ist nicht möglich.
dafür sorgt der RID Master und die Logik einer Kontingent Vergabe pro DC, die ein DC selbst verwaltet.
das ist einer der Gründe, warum du nur max ca 2,15 Milliarden Objekte im AD erzeugen kannst. jede RID ist eindeutig, einmalig.
Deswegen https://diskcryptor.org/
kein TPM oder anderer Käse einfach nur ein gutes langes Passwort beim booten,
kein Passwort kein Zugang, as simple as that.
Danke für den Link @DavidXanatos – kannte ich noch nicht.
Ist das Tool aus Deiner Erfahrung praktikabel für Unternehmen (Zielgruppen wie zB bei Bubba, Froschkönig, …)? Ich knobel schon länger über vernünftige und akzeptierte Alternativen zu Bitlocker. Versuche eines mehrstufigen Bootens zB mit einem vorgelagerten Linux und Nutzung eines Schlüssels auf steckbarer SmartCard oder Remote-Key per SSH scheiterten hier bisher an Wartbarkeit oder Komplexität…
Das Tool Unterstützt momentan nur Passwort Eingabe beim booten, keine crypto hardware. Der Bootloader ist ein moderner UEFI Bootloader und quell offen also es ist nicht schwer sich eigene Funktionen rein zu basteln.
Nichts gegen Herrn Xanatos(' Produkte),
aber gerade im Unternehmensumfeld sollte man doch eher Risiken vermeiden, d.h. bekannte und auditierte Software einsetzen.
Wenn es also nicht Bitlocker sein soll (man muss ja eigentlich nur TPM ungenutzt lassen (d.h. "PIN"-Abfrage beim Boot einrichten)) dann doch weit eher Veracrypt(.fr).
Wobei ja nicht TPM das Problem ist, sondern die Konfiguration des Gerätes.
TPM only bzw. TPM mit Secure Boot ist nicht sicher. Auch wenn das die default Konfig ist, die man bei der Masse der Geräte bekommt ist das ja nicht zwingend als sicher anzunehmen. Die Frage ist dabei eher, was wollte man damit erreichen? Ist die default Konfig besser als gar keine Verschlüsslung? Ja, 100% ja. Ist die default Konfig die Bestmögliche in so einem Szenario? Nein, ganz klar nein.
Es gilt also das Motto wie eigentlich immer – wer Sicherheit will, muss sich mit dem Thema auseinander setzen und eben entsprechende Maßnahmen ergreifen.
Ist nicht aber das Problem eher wieder einmal dass hier Sicherheit und usability gegeneinander stehen?
Ich mein, ja, man kann da argumentieren, dass die User keine pre boot authentication wollen. Aber wenn das allein das Maß der Dinge ist, dann kann man halt auch nicht erwarten, dass die Sicherheit bis in jedes Detail gegeben ist. Das gezeigte hier hat schlicht etwas von wegen, ich will keinen Haustürschlüssel mit mir rumtragen, der soll an der Tür stecken bleiben -> um sich dann zu wundern, wenn Jemand diesen einfach nutzt um aufzuschließen.
Ohne einen weiteren Faktor, den nur der Nutzer kennt, sei es ein Pin/PW oder ein externer Key als USB Stick, liegen ALLE Sicherheitsmerkmale, die für die Verschlüsslung in Verwendung sind, in dem Gerät selbst, was man verschlüsseln möchte. Das ist perse unsicher, weil man keine Möglichkeit hat das Auslesen dieser Schlüssel zu verhindern, bspw. bei einem abhanden gekommenen Gerät. Eine Verschlüsslung basiert auf dem Grundsatz, dass ein geheimer Schlüssel nur von der Stelle gekannt wird, der der rechtmäßige Nutzer ist. Das widerspricht zu 100% dem Wunsch, dass man kein Pin/PW/Key whatever nutzen möchte.
Nur weil es "default" ist, das so konfiguriert zu bekommen ist das ja lange nicht sinnig, das so zu betreiben. Der default ist perse besser als gar keine Verschlüsslung, da die Hürden dennoch hoch sind um das zu erreichen und es auch mit neueren UEFI Versionen Möglichkeiten gibt, alt signierte Bootloader auszuschließen. Sprich das Problem ist letztlich nach dem forcieren der neuen CA und dem rausschmeißen der alten CA erstmal endlich in der Form. Es wird aber immer irgendwo irgendwann irgendwas geben, was in der Lage ist, reine "Softwaresicherheit" zu brechen, weil Programmcode in aller Regel irgendwo Fehler enthält.
Was aber auch wichtig zu erwähnen ist, die Verschlüsslung selbst ist nach wie vor ungebrochen. Meines Wissens nach gibt es bisher keine Meldung, dass die Bitlocker Verschlüsslung anfällig ist. Alle bis dato gezeigten und gemeldeten Dinge basieren auf Schwächen in der Implementierung oder eben in falscher Konfiguration und für alle Bitlocker Meldungen die sich bisher kenne ist die Lösung zum Umgehen in aller Regel immer die gleiche -> nutzt einfach diese verdammte Pin bzw. PW Abfrage um einen nur euch bekannten Faktor in die Kette einzubringen. -> Problem solved. Jede andere Methode basiert auf dem gleichen Ansatz eines nur dem Nutzer bekannten Schlüssels.
> die Verschlüsslung selbst ist nach wie vor ungebrochen
Das ist aber komplett egal wenn sich MSFT den key auf ihre server Abschnorchelt wo er gestohlenen werden kann resp an jede halbwegs nicht komplett illegitime Regierung heraus gibt.
Verschlüsslung ist dazu da damit Daten so vertraulich bleiben wie im eigenem Gedächtnis sprich da soll niemand nicht MS und auch nicht irgend eine Regierung oder geheim dienst ran können.
Damit disqualifiziert sich der MSFT Bitlocker IMHO komplett selbst, siehe: https://diskcryptor.org/why-not-bitlocker/
Aber nur wenn du mit einem MS Konto unterwegs bist. Ehrlicherweise – wenn das der Fall ist, benötigst du schlicht auch nicht den Recovery Key als "angreifende" Stelle.
Du hast da ein Gedanken-Folgefehler. Nicht der Recovery Key bei Microsoft ist das Problem sondern das Problem ist, dass du in dem Fall die Account Verwaltung einer dritten Stelle übergibst, dessen Vertrauen du natürlich nicht so ohne weiteres entziehen kannst. Zumindest nicht wenn dir das Gerät abhanden kommt und Dritte sich daran versuchen (können).
Das ist das selbe wie diese ganzen "Login with Facebook, Apple ID, …" Methoden im Netz. Der Jenige, der in der Lage ist, DEINEN Account zu verwalten, hat potentiell auch Zugriff auf die Daten, die mit diesem Account verwendet werden.
Letztlich kannst du dich einfach ohne den Recovery Key am System anmelden, wenn du in der Lage bist (bspw. als "jede halbwegs nicht komplett illegitime Regierung") der Account Verwaltenden Stelle diese Anweisung zu geben diesen Account für dich zu öffnen. Ob mit oder ohne Recover Key Upload zu Microsoft. Das spielt überhaupt keine Rolle (mehr) in so einem Fall.
Und nein, es ist in dem Fall IMMER so. Egal welche Art der Verschlüsslung du nutzt. Solange das Gerät bootet bis an die Stelle, wo dein (externer) Account abgefragt wird, so nutzt dir der ganze Verschlüsslungskram exakt gar nix mehr. Die einzige wirksame Methode ist, dass du hier eben mit einem zusätzlichen Faktor verschlüsseln solltest, den Niemand kennt. Bspw. durch Setzen des Pre Boot Pins.
Um es nochmal klar zu benennen. Das Problem hier ist nicht Bitlocker oder die Verschlüsslung – diese ist mathematisch nach wie vor ungebrochen. Das Problem ist hier, dass eine zu lasche default Konfiguration das externe Booten über PXE möglich macht und dabei ein alter Boot Loader geladen werden kann, der den Fehler beinhaltet, dass der Schlüssel im RAM bei einem Bootfehler nicht gelöscht wird. Und sich in Folge dessen auslesen lässt. Mal mehr mal weniger einfach. Jeglicher Hinweis oder Verweis auf eine Dritt-Verschlüsslungssoftware ist völlig am Thema vorbei, weil man hier explizit den Umstand angeht, wo der Nutzer eben keine Eingaben machen möchte/soll. -> JEDE Software die verschlüsselt hat das selbe Problem in so einem Fall. Denn sowohl verschlüsselte Daten als auch Schlüssel werden dabei zwingend im gleichen Gerät gehalten. Was sich dabei nur ändert ist die Angriffsmethode im Detail. Andere Software hat andere Fehler.
In Zeiten des Cloud Act ist egal, was das Marketing da als "ungebrochen" usw. verkauft…
OK, ist ein Argument. Bitte verlinke doch mal irgend ein POC oder Exploit Code, was die Bitlocker Verschlüsslung bricht!? Mir ist kein derartiges Thema bekannt. Und nein, ich meine nicht das Marketing-Ungebrochen oder das Marketing-Sicher. Sondern ich meine das entschlüsseln der Daten einer Disk ohne den Schlüssel zu haben. Beispielhaft skizziert, ich schicke dir eine per Bitlocker verschlüsselte Disk und du sagst mir, was drauf ist binnen meiner Lebzeit.
Egal wie man es dreht und wendet oder mit welchen Wörtern man das Problem beschreibt. Sobald ein dritter unbekannter Faktor dazu kommt, sind die Bits und Bytes auf der Disk in der Form nicht zurück rechenbar in einer passablen Zeit. Zumindest stand heute.
Der ganze Rest ist mMn quatsch. Wenn Regierungen oder andere Vertreter ins Spiel kommen, die wirklich an DEINE Daten wollen, dann schnappen die dich im Zweifel von der Straße weg und zwingen dich das Gerät selbst zu entsperren. Es mag in 2025 dieser Breitengrade unüblich sein, aber "Folter" ist dir ein Begriff?
>> Bitte verlinke doch mal irgend ein POC oder Exploit Code, was die Bitlocker Verschlüsslung bricht!
Präsentation einer US-Behörde in Oregon
https://archive.techarp.com/showarticlec3f0.html?artno=770
Seite 30 sagt, dass es eine Bitlocker-Backdoor gibt.
Zählt das?
Ich kann es nicht verifizieren, nur zitieren.
Ja, zumindest mMn zählt das.
Wiewohl man sich streiten kann, ob eine Backdoor die Definition von "Verschlüsslung gebrochen" erfüllt wäre das eher Semantik – effektiv ist sie damit gegenüber dem Nutzer der Backdoor wirkungslos.
Die Demo bzw. der Talk zielt sich auf die "Device Encryption" (ab W11 Home) ab und nicht auf "Drive Encryption" (ab W11 Pro). Meine Frage bzw. was (für mich) nicht klar wurde: Funktioniert der gezeigte Angriff der unter W11 Home mit Device Encryption durchgeführt wurde, auch für Geräte mit Drive Encryption?
Letztlich ist das nur Namensbingo.
Unter der Decke ist das Bitlocker, wo bei der Pro und größer etwas mehr Flexibilität bei der Konfiguration möglich ist.
Der Kern des ganzen ist, dass hier in der Default Konfiguration ein Gerät beliebig in der Lage ist, externe Medien zu booten. (im Fall des Fehlers ist es PXE Boot über einen LAN Adapter)
-> der vergessene Schlüssel im RAM bezieht sich auf den Umstand, dass ein Fehler/Bug existiert bei dem der Schlüssel nicht (wie es eigentlich richtig wäre) gelöscht wird, wenn der Bootprozess in einen Fehler läuft. Dieser Fehler existiert aber nur in der PXE Boot Methode laut dem Vortrag.
-> man nutzt hier also eine explizit falsche Boot Konfiguration um den Boot Prozess crashen zu lassen und setzt als Fall Back Version PXE Boot, was dann in der Lage ist, mit einem richtig signierten Boot Medium bspw. ein Linux zu booten.
Da ein Fehler in der PXE Boot Methode existiert, die bei fehlerhaftem Boot Versuch den Key nicht aus dem RAM putzt, bleibt schließlich bei Ausführen der Fallback Methode dieser Key im RAM lesbar. -> Es wird daraufhin ein Linux via PXE gebootet, was mit entsprechenden root Rechten in der Lage ist, eben den Memory auszulesen und nach dem entsprechenden Schlüssel zu suchen.
-> damit das alles zusammen spielt, modifiziert man den den Boot Prozess dahingehend, dass eben die richtige Disk ID durch den TPM entsperrt wird und der Key in den RAM geladen wird, lässt aber den Boot Vorgang selbst crashen, weil man sagt, es solle von "/" bspw. gebootet werden, wo nix zum Booten existiert.
Im Endeffekt ist das ein Fehler der in der Form massiv unschön ist und sich nicht patchen lässt, es sei denn, man ändert das Bootverhalten derart, dass nirgendwo in der Prozesskette ohne Userzutun der Key geladen wird. Letztlich betrifft das alle Versionen von Bitlocker gleichermaßen. Einzig mit dem Pre Boot PIN bzw. einem weiteren Faktor, der das automatische entsperren des Keys und laden in den Speicher verhindert, lässt sich das Thema umgehen.
Achso und was natürlich auch dazu kommt – dem Gerät erlauben externe Medien zu booten ist in aller Regel auch massiv fahrlässig. Man setzt also normalerweise ein UEFI Password und verbietet außer den Windows Boot Manager Eintrag alle externen Geräte. Zudem gibt es meist einen Schalter, der das booten von externen Medien generell verhindert. Bei anständiger Implementierung von UEFI in PC/Notebook kommt man ohne weiteres damit nicht ran. Ein Gerät also im laufenden Zustand zu einem Reboot mit der Bootauswahl zu bewegen, ist in dem Fall dann nicht mehr möglich.
Selbst wenn es einer schafft, meine Platte c: mit TPM und Bitlocker zu knacken (Recovery-Key liegt afaik nicht bei MS, da mit lokalem Konto eingerichtet), meine wichtigen Daten liegen auf einer anderen HDD, die zwar auch mit Bitlocker verschlüsselt ist, aber nicht vom Betriebssystem automatisch entsperrt wird, sondern ein eigenes Passwort hat. Ich hoffe, das macht es etwas sicherer, solange der Folterknecht nicht persönlich vorbeischaut ;-)
Aber ich könnte mir auch mal VeraCrypt anschauen, der letzte Abschnitt des folgenden Artikels sieht interessant aus:
The Verdict: VeraCrypt Is Stronger and More Powerful, but Use Bitlocker Too
https://lifehacker.com/windows-encryption-showdown-veracrypt-vs-bitlocker-1777855025
FWIW: Auf C: liegen alle Tempfiles (wenn man sie nicht nach D: oder besser RAMdisk umleitet), ausserdem Swap (pagefile.sys) und hiberfil.sys, alles dann im Klartext, da lacht des Forensikers Herz.
Ist es denn wirklich so eine grosse Mühe, die "PIN" zum Booten einzutippen? Meine ist > 30 Zeichen und selbst das merkte ich nach ein paar Tagen/Wochen kaum noch, es ist ein kurzer, flüssiger Prozess.