Die Wochenend News von Heise zeigt wie man die Microsoft BitLocker-Verschlüsselung umgehen kann, siehe Link. Der Hack von Sami Laiho zeigt, dass die Angriffe gegen eine transparente (BitLocker) Verschlüsselung noch lange nicht aufhören. Kürzlich der Secure Boot Hack, zuvor mehrere Angriffe per USB/Firewire und DMA-Hack und nun ein unsicherer Update-Prozess. Da wünsche ich mir mehr Schutz für meine Daten!
Da wir bei BitLocker-Verschlüsselung immer über einen Data-at-Rest Schutz sprechen, sollte genau dieser Anspruch erfüllt sein: Daten am Ablageort (lokale Disk, Server, Plug&Play-Device) müssen vor fremden Zugriff geschützt werden. Klingt einfach, funktionieren aber nicht, wenn der Microsoft BitLocker SICH SELBST(!) fürs Update deaktiviert.
Ein weiterer einfacher Hack für die Microsoft Verschlüsselung
Inspiriert von Sami Laiho empfehle ich auf das nächste Update zu warten, um dann die Festplatte mit deaktiviertem BitLocker in ein USB-Gehäuse einzubauen und an einem beliebigen Windows anzustecken. Da die Verschlüsselung systembedingt deaktiviert wurde, kann das System die externe verschlüsselte Partition einfach laden und ihr habt vollen Zugriff auf alle Daten und könnt das System hacken, infiltrieren und manipulieren oder einfach nur die vertraulichen Daten kopieren.
Seit rd. 15 Jahren arbeite ich in der IT-Security Branche, die letzten 10 Jahre primär in der Verschlüsselung. Daher kann ich nur dringend von den folgenden Fehlern in einer Verschlüsselungslösung abraten:
- Transparente Verschlüsselung, d.h. Schlüssel automatisch bereitzustellen
- Verlass auf schwache Passworte für die Verschlüsselung zur Vermeidung von Brute-Force Attacken -> stattdessen Nutzung von Zertifikaten oder zumindest starken Passworten
- Keine eingebauten Backdoors oder versteckte Recovery-Schlüssel
- Keine Prüfbare Kryptokonzepte
Sicherer Betrieb des Microsoft BitLocker mit und ohne TPM
Bei der Microsoft Verschlüsselung werden diese Regeln leider nicht immer befolgt:
Ad 1.) BitLocker mit TPM Nutzung aber ohne TPM-PIN lässt verschlüsselte Systeme automatisch booten. Einfach für die Benutzer, aber Quatsch aus kryptografischer Sicht.
Ad 2.) Mit etwas tricksen kann man den BitLocker auch mit einem Passwort und ohne TPM-Chip betrieben. Meiner Meinung nach ist es nur eine Frage von Zeit, bis es automatische Tools gibt die einen BitLocker verschlüsselten Windows-Rechner über ein zu schwaches Passwort per Brute-Force-Angriff hacken können.
Ad 3.) Hier muss jeder selbst beurteilen, ob er Kryptografie aus Open-Source Produkte oder Closed-Source Produkten aus Europa, USA oder Asien vertraut.
Ad 4.) Hier arbeitet Microsoft vorbildlich, die Verschlüsselung-Security Konzepte sind gut dokumentiert und nachvollziehbar, Recovery-Schlüssel und Ausnahmen zur Verschlüsselung wie beim Update sind allseits bekannt.
Ich bin der Meinung, dass Unternehmen fahrlässig handeln, wenn du die Verschlüsselung mit der Microsoft Methode unsicher konfigurierst und bewusst auf Sicherheitseigenschaften wie TPM-PIN oder Secure Boot verzichtest. Gerne beantworte ich Fragen wie du die Sicherheit bei der Verschlüsselung deutlich erhöhen kannst.
Hi Andreas,
danke für das Thema und deinen Beitrag. Leider gehe ich (was nicht oft der Fall ist) heute nicht mit allen deinen Aussagen d’acor wie unsere Freunde aus Frankreich sagen würden. Also die bei denen Unternehmen zentral Schlüssel bei der Regierung ablegen müssen wenn sie verschlüsseln wollen aber das ist ja ein anderes Thema…
Nun zu deinem Text.
Anmerkung 1:
Secure Boot und Bitlocker haben miteinander nichts zu tun. Mit SecureBoot verhindert Microsoft lediglich, dass es zu einem Austausch von Boot Informationen durch unsignierten Code kommen kann / soll. Leider oder auch zum Glück (je nachdem aus welcher Richtung man schaut) hat MS mittlerweile Linux Code bereitgestellt der entsprechend signiert ist und damit SecureBoot tauglich. Eine Evil Maid Attacke – ich tausche die echte Bitlocker Anmeldung durch einen Fake aus und leite im Hintergrund die Anmeldedaten an die echte Anmeldung weiter und besorge mir dann den Rechner inkl. Passwort – ist damit IMHO wieder sehr einfach möglich. Den Schutz und das Weh von Bitlocker betrifft dieses Setting aber dennoch nicht, da es keinerlei Verbindung zum TPM oder dem Keymanagement hat.
Anmerkung 2:
Die Attacke welche in den Medien beschrieben worden ist, erfordert ein sehr genaues Timing und direkten Zugriff auf den Rechner. In diesem Fall könnte ich dann wenn ich das richtige Timing habe und die entsprechende Tastenkombination kenne eine Shell mit erweiterten Rechten ausführen was mir dann den Zugriff auf das System ermöglicht. Bitlocker selbst wird allerdings zu KEINEM Zeitpunk deaktiviert – lediglich die Authentisierung wird abgeschalten um in das MS Install Environment zu booten. Microsoft schafft damit die Möglichkeit ein Inplace Upgrade des kompletten OS zu machen ohne den Rechner neu starten zu müssen – etwas das sonst KEIN andere Hersteller mit eigener Treibertechnologie kann.
Anmerkung 3:
Der Trick um die o.g. Attacke auszuführen würde nur funktionieren wenn
a) ein Update von MS kommt welches in das o.g. Install Environment Booten möchte den sonst kommt die Authentisierung
b) du Zugriff auf den Rechner hast
c) den von MS initiierten Reboot von Hand unterbrichst um die HDD zu entwenden
>> Für mich sind das zu viele Komponenten und Voraussetzungen um den Anfriff als realistisch einzuschätzen.
Wo ich dir jedoch gerne Recht geben möchte ist in der Tatsache, dass wenn man Bitlocker verwendet, man auch die vom BSI vorgeschlagene Konfiguration in PIN und TPM als Kombination verwenden sollte.
Ich persönlich sehe eher den den TPM Chip als “sicheren Schlüsselspeicher” als Gefahr (wusstest du dass es Rechner gibt bei denen der TPM nur gesteckt und nicht gelötet ist – ein Schelm wer böses denke an dieser Stelle) und dessen Integrität.
Ich bin der noch immer der Meinung, und ich glaube da sind wir uns beide Einig, dass HDD Verschlüsselung gut gegen Diebstahl und im Falle von Verlust hilft aber im Praxisbetrieb und vor allem in Zeiten von Ransomware nur in Kombination mit einer Dateiverschlüsselung wirklich Schutz bieten wird.
Ich freue mich schon auf deinen nächsten Post zu diesem Thema 😉
Wie immer: Danke für deinen Einsatz und mach weiter mit diesem echt interessanten Blog!
Gruß
Daniel
Hallo Daniel,
das war sehr konstruktiver Inhalt von dir, über den ich ein paar Tage nachgedacht und recherchiert habe. Dass es gesteckte Security TPM Chips gibt finde ich aus Servicezwecken ganz gut, aber aus Security Sicht natürlich schlecht.
Beim Secure Boot beschreibst Du eigentlich schon den Angiff den ich im Kopf habe: Ein Angreifer der mehrfach physikalischen Zugriff auf einen Client hat (die “Evil Maid”) spielt Software auf um das BitLocker Passwort oder den TPM-PIN abzugreifen. Meiner Meinung nach geht das per Vortäuschen einer BitLocker-Anmeldung aber auch wenn man Software dem Secure Boot unterschiebt der Tastatureingaben überwacht/protokolliert oder einen Debugger startet.
Zu deiner Anmerkung #2 meine ich, dass wann man die Authentisierung deaktiviert eine Verschlüsselung generell kompromittierbar ist. Dazu hatte ich kürzlich auch eine Online Diskussion in Xing mit weiteren Experten wie wichtig ein kryptographischer Schutz von Verschlüsselungsschlüsseln im Zuge einer Authentisierung ist, siehe Xing Beitrag https://www.xing.com/communities/posts/ein-weiterer-hack-fuer-die-bitlocker-verschluesselung-1012338013
Bei deiner Anmerkung 3 sehe ich den Ausschluss einer Attacke nur weil die Parameter a) – c) gegeben sind als überhaupt kein Problem, wenn ein Angreifer wirklich an wichtige Daten kommen möchte. Da gehe ich sogar so weit, dass ein Angreifer versuchen wir ein Microsoft Update per gefälschten DNS Einträgen oder manipulierten Update-Dateien zu erzwingen, um eine temporäre Aussetzung der BitLocker-Verschlüsselung zu erzwingen. Da sind schon viel komplexere Angriffe überlegt und augeführt worden… 😉
Ich freue mich schon, wenn ich meine BitLocker-Verschlüsselung mit einer Handy-App aufsperren kann, das wäre für mich der angenehmste Weg einer Zwei-Faktoren-Benutzeridentifizierung.
Deinen letzten fachlichen Satz möchte ich auch nicht unkommentiert lassen, da eine HDD Verschlüsselung tatsächlich gar nicht vor Ransomware oder Datenabfluss schützt, sobald Angreifer dein laufendes System befallen/infizieren. Da helfen nur gute Virenscanner, Verhaltensanalysen oder Sandboxing-Technologie und natürlich auch Firewalls und klassische Perimeter-Security.
Sichere Grüße, Andreas
Um die Tragweite des von Sami Laiho dargestellten Problems zu verstehen, darf man nicht nur von externen Tätern ausgehen. Bitlocker ist unabdingbar um für die Unternehmens-IT die Integrität der Maschinen zu gewährleisten. Dazu zählt auch, dass Anwender nur jene Rechte haben, die man diesen zugesteht – also sicherlich keine Admin-Rechte auf der Maschine. Ohne BitLocker könnte sich jeder Anwender des Unternehmens mit 3 Minuten Aufwand selbst zum Administrator machen, die Unternehmens-IT merkt davon nichts.
Gemäß neuem Windows 10 Lifecycle-Modell rollt Microsoft nun 2x jährlich eine neue Windows Release aus. Ganz ohne Hacker-Kenntnisse kann ein Anwender also nun 2x pro Jahr die Gunst der Stunde nutzen, und den Update-Zeitpunkt (den er eventuell sogar selbst einfach bestimmen kann) dazu nutzen sich Admin-Rechte zu verschaffen.
So wie Microsoft das derzeit anbietet, ist BitLocker nun also kein wirksamer Integritätsschutz mehr. Anwender können sich – mit minimalen Kenntnissen – im Zuge eines Updates selbst zum Admin machen. Auch wenn aus der für das Feature-Update verwendeten WinPE-Version die Funktionalität entfernt wird, so ist ein Null-Protektor während des Updates aktiviert, der Schutz somit aus Sicht der Unternehmens-IT “verloren”.
Hallo Gunnar,
Danke für Deine Bestätigung, dass das deaktivieren der BitLocker Verschlüsselung ein massiver Einschnitt bei der Security ist, vor allem da ein Angreifer – egal ob intern oder extern – nun bei den 2x jährlichen Windows Releases schon planen kann, wann sich der BitLocker selbst deaktivieren wird.
Bei kommerzieller Nutzung von Windows Clients mit BitLocker würde ich das automatische Upgrade deaktivieren und Upgrade nur unter Admin-Aufsicht durchführen. Leider entspricht das gar nicht der Realität und bei großen Umgebungen mit mehreren Hundert bzw. Tausend Clients haben Unternehmen gar nicht die Ressourcen ein Upgrade zu beaufsichtigen.
Zusatzsoftware für das Problem kenne ich. Wenn jemand einen Tipp hat wie ein BitLocker Kunde dieses offene Problem direkt lösen kann würde ich mich sehr um weitere Meldungen freuen.
Sicher Grüße, Andreas
Ich habe heute Sami Laiho gefragt, ob er von Microsoft schon neue Infos diesbezüglich hat. Die Variante die Problematik direkt mit dem von Microsoft für das Feature-Update verwendeten WinPE durch Drücken von SHIFT+F10 auszunutzen dürfte geschlossen werden. Solange Microsoft bei Feature-Updates an der nun neuen Praxis festhält, das OS durch Booten eines WinPE-Kernels vollständig auszutauschen, ist das kryptographisch aber sauber kaum lösbar, dieser WinPE-Kernel kann ohne einen Hinweis zu erhalten die Bitlocker-verschlüsselte Disk nicht mounten.
Man könnte die Latte allerdings schon noch ein Stück höher legen, um zumindest technisch mäßig versierten Anwendern die Sache nicht allzu einfach zu machen. Vor dem Reboot könnte Microsoft einen temporären, zufälligen Protektor anbringen (derzeit wird ja ein Null-Protektor verwendet!), der Key hierfür müsste dann vor dem Reboot ins WinPE-Image injected werden, das von Microsoft für das Update verwendete WinPE dürfte keinen ByPass (Shift F10) zulassen. Klar könnte ein Anwender dann immer noch sein eigenes WinPE booten und im auf der Disk liegenden WinPE nach dem injecteten Protektor suchen – das müsste man mit geeigneter Obfuskierung eben so gut als möglich erschweren. Keine saubere Lösung, aber besser als völlig ungesichert.
Hallo Gunnar,
Danke, dass du dich so intensiv mit dem Thema beschäftigst und versuchst die offensichtlichen Lücken zu erläutern. Ohne noch weiter in die technischen Details um Shift-F10 und WinPE einzusteigen, bringt mich auf den einzigen Schluss, nämlich:
(1) Jede Verschlüsselungslösung benötigt eine explizite Benutzer Authentisierung oder das Vorzeigen eines geheimen Schlüssels für jedes “Aufsperren” von Daten oder einer Festplatte. Meine Forderung ist, dass der Benutzer legitimieren muss, wenn ein Verschlüsselungsschlüssel aktiviert wird und das soller mit einem Passwort, einer TPM-PIN oder einem zweiten Faktor wie einer Handy-App oder einer Smartcard tun.
(2) Die Benutzer Authentisierung muss kryptographisch mit der Verschlüsselungslösung verbunden sein. Daher eignen sich biometrische Methoden in der Regel nicht, da dies Biometriedaten keinen fixen Schlüssel liefern, sondern nur eine Wahrscheinlichkeit einer Übereinstimmung. Konkret also sperrt diese biometrische Wahrscheinlichkeit per if then else Befehl einen versteckt gespeicherten Schlüssel auf. Wenn man den if then else Befehl im Programmcode manipuliert, dann umgeht man ganz automatisch jede Verschlüsselung.
Wen stört es schon, wenn man während einem Inplace Upgrade 1-2x das Verschlüsselungspasswort eingeben müsste, dafür die System-Sicherheit aber vollständig gewahrt bleibt!
(3) Eine Verschlüsselungslösung darf sich nicht automatisch deaktivieren.
Lustig finde ich die 3 Regeln sind irgendwie so wie die Robotergesetze von Isaac Asimov. Wäre doch wirklich schön, wenn ich daraus ein allgemein gültiges Verschlüsselungsgesetz erfunden hätte.
Gibt es von den Lesern konstruktive Einwände zu meinem neuen “Verschlüsselungsgesetz”?
Sichere Grüße, Andreas
zu (1): Im Kontext von Unternehmens-IT passt der Begriff “Benutzer” nicht unbedingt. Mit Benutzer assoziiere ich jene Person, die interaktiv vor dem Gerät sitzt, die (in meiner Welt) jedoch keine Administrator-Rechte und möglichst gar keinen Zugriff auf das Schlüsselmaterial hat.
zu (2): Biometrische Methoden würde ich nicht zwingend ausschließen, es muss der Container der das tatsächliche Schlüsselmaterial beherbergt nur ausreichend vor Kompromittierung geschützt sein, und das Schlüsselmaterial eben nur dann freigeben, wenn die biometrischen Merkmale eindeutig vorgewiesen wurden. Wenn z.B. eine Smartcard mit Template-Matching/Match-on-Card die Biometrie prüft und das Schlüsselmaterial sicher verwahrt, dann habe ich da keine grundsätzlichen Bedenken. Was bleibt ist aber die Problematik, dass das Sicherheitsniveau bei Biometrie immer von der verwendeten Biometrie-Hardware abhängt (z.B. billiger versus hochwertiger Fingerprintreader mit Lebend-Erkennung etc…), und man daher eine Absicherung dahingehend benötigt, dass das Template sicher frisch ist (Replay-Schutz) und jetzt soeben von einem tauglichen (hochwertigen) Gerät erfasst wurde.
Hallo Gunnar,
bei “zu (1)” sehe ich das nicht so streng. Sowohl bei der Full-Disk-Encryption, als auch der userbasierten File & Folder Encryption, als auch bei der E-Mail-Verschlüsselung ist es ein normaler Benutzer der Zugriff auf vertrauliche Schlüsselmaterialen benötigt, um sein Arbeit mit vertraulichen Daten durchzuführen. Andere Verschlüsselungstechnologien wie Server-TLS, LAN-Verschlüsseler oder Site-to-Site VPN sind tatsächlich nur von Administratoren zu verwalten.
bei “zu (2)” das hast Du natürlich vollkommen recht. Biometrisches Match-on-Card ist ein sehr guter Zwei-Faktoren-Schutz, wenngleich der Schlüssel nicht aus der Biometrie kommt sondern die Biometrie nur die Benutzung eines zuvor generierten RSA oder ECC Schlüssel autorisiert. Für die Masse sind natürlich hochwertige Biometrie-Leser i.d.R. zu teuer, daher würde ich eher auf andere Authentisierungsmethoden setzen, als auch Low-Cost Fingerprintreader die beispielsweise mit einem Silikonabdruck eines Fingers getäuscht werden können.
Mein massentaugliches Medium der Zukunft ist eine mit PIN oder Fingerprint geschützte Handy-App. Die Handy-App sollte einen individuellen Schlüssel für Signatur und Authentisierung speichern, den Schlüssel in einem sicheren Speicherbereich des Handys schützen und eine geschützte Tunnelverbindung zum Verschlüsselungssystem nutzen. Das kann meiner Meinung nach zukünftig in der Privatwirtschaft gängige OTP-Token oder Smartcard-Lösungen ersetzen.
Sichere Grüße, Andreas