Der Konflikt zwischen Microsoft und dem 'Sicherheitsforscher' Nightmare Eclipse verschärft sich weiter. Nach Sperrungen auf großen Entwickler-Plattformen weicht der Hacker nun auf seinen eigenen Blog aus und droht für Juli mit einem Angriff.
Zu dem Bitlocker “Backdoor” YellowKey kann ich verstehen, warum Microsoft sagt, dass es kein Bug in Bitlocker ist. Zumindest für den bislang bekannten Exploit. Der angeblich auch vorhandene Exploit für TPM+PIN, der (noch) nicht öffentlich ist würde mich ggf. umstimmen.
Was passiert hier im Exploit?
Ich boote den PC, der Bitlocker über TPM aktiv hat in ein Recovery-Environment über einen USB-Stick. Normalerweise startet das Environment direkt in die entsprechenden Tools zur Fehlerbehebung / Neuinstallation. Dafür muss Bitlocker die Platte entschlüsselt haben. Das kann Bitlocker, weil hier der originale Kernel von MS vom Stick gebootet wird, der signiert ist und SecureBoot das OK gibt. Das entsperrt hier auch den Zugriff auf das TPM und somit lassen sich die nötigen Keys zur Verschlüsselung daraus ableiten. Damit ist die Festplatte “offen”. Bitlocker schützt hier nur, wenn entweder nicht via SecureBoot gestartet wird (weil TPM nicht entsperrt), oder die Festplatte/SSD in einem anderen Rechner steckt (anderes TPM das den Key nicht kennt).
Der genannte FsTx Ordner auf dem Stick ist kein wirklicher Exploit, sondern enthält einfach eine (fingierte) offene Transaktion im Dateisystem des Sticks, die scheinbar unterbrochen wurde und noch durchzuführen ist. Beim Boot vom Stick wird die nachgeholt und löscht einfach eine .ini-Datei auf dem Stick, die angibt, welches Programm nach dem Boot ausgeführt werden soll. Da durch die gelöschte Datei diese Info fehlt, startet Windows als Fallback eine Shell. IIRC als Admin oder sogar SYSTEM. Bitlocker ist aber zu dem Zeitpunkt bereits initialisiert und hat die Keys bekommen, der Zugriff auf die Daten ist also möglich. Somit alles gewollte Features, und nur ungewöhlich verkettet. Keines der Tools selber hat nen Bug. Genau derselbe Trick geht eben NICHT, wenn TPM+PIN o.ä. eingerichtet ist, da das TPM dann ohne den PIN den Key nicht erzeugen kann und die Entschlüsselung nicht geht. Und der PIN sollte nur dem User bekannt sein und somit sollte kein Zugriff möglich sein.
Daher: Erst mal verständlich, wenn dieser Bug NICHT im Scope des Bug Bounty von Bitlocker ist, da Bitlocker hier das tut was es soll.
Wenn hier nun raus kommt, wie man OHNE den PIN die Platte entschlüsselt (bzw. dass Windows an irgendeiner Stelle den Key so in den Metadaten cached, dass man den rekonstruieren kann o.ä.), DANN sieht die Sache anders aus.
Hinweis: Das ist nur die Bewertung, ob die Ablehnung im Bug Bounty gerechtfertigt sein könnte - NICHT, ob das einfach eine blöde Konstellation in einem komplexen System ist, oder nicht doch eine leicht abstreitbare Hintertür ist.
Zu dem Bitlocker “Backdoor” YellowKey kann ich verstehen, warum Microsoft sagt, dass es kein Bug in Bitlocker ist. Zumindest für den bislang bekannten Exploit. Der angeblich auch vorhandene Exploit für TPM+PIN, der (noch) nicht öffentlich ist würde mich ggf. umstimmen.
Was passiert hier im Exploit?
Ich boote den PC, der Bitlocker über TPM aktiv hat in ein Recovery-Environment über einen USB-Stick. Normalerweise startet das Environment direkt in die entsprechenden Tools zur Fehlerbehebung / Neuinstallation. Dafür muss Bitlocker die Platte entschlüsselt haben. Das kann Bitlocker, weil hier der originale Kernel von MS vom Stick gebootet wird, der signiert ist und SecureBoot das OK gibt. Das entsperrt hier auch den Zugriff auf das TPM und somit lassen sich die nötigen Keys zur Verschlüsselung daraus ableiten. Damit ist die Festplatte “offen”. Bitlocker schützt hier nur, wenn entweder nicht via SecureBoot gestartet wird (weil TPM nicht entsperrt), oder die Festplatte/SSD in einem anderen Rechner steckt (anderes TPM das den Key nicht kennt).
Der genannte
FsTxOrdner auf dem Stick ist kein wirklicher Exploit, sondern enthält einfach eine (fingierte) offene Transaktion im Dateisystem des Sticks, die scheinbar unterbrochen wurde und noch durchzuführen ist. Beim Boot vom Stick wird die nachgeholt und löscht einfach eine .ini-Datei auf dem Stick, die angibt, welches Programm nach dem Boot ausgeführt werden soll. Da durch die gelöschte Datei diese Info fehlt, startet Windows als Fallback eine Shell. IIRC als Admin oder sogarSYSTEM. Bitlocker ist aber zu dem Zeitpunkt bereits initialisiert und hat die Keys bekommen, der Zugriff auf die Daten ist also möglich. Somit alles gewollte Features, und nur ungewöhlich verkettet. Keines der Tools selber hat nen Bug. Genau derselbe Trick geht eben NICHT, wenn TPM+PIN o.ä. eingerichtet ist, da das TPM dann ohne den PIN den Key nicht erzeugen kann und die Entschlüsselung nicht geht. Und der PIN sollte nur dem User bekannt sein und somit sollte kein Zugriff möglich sein.Daher: Erst mal verständlich, wenn dieser Bug NICHT im Scope des Bug Bounty von Bitlocker ist, da Bitlocker hier das tut was es soll.
Wenn hier nun raus kommt, wie man OHNE den PIN die Platte entschlüsselt (bzw. dass Windows an irgendeiner Stelle den Key so in den Metadaten cached, dass man den rekonstruieren kann o.ä.), DANN sieht die Sache anders aus.
Hinweis: Das ist nur die Bewertung, ob die Ablehnung im Bug Bounty gerechtfertigt sein könnte - NICHT, ob das einfach eine blöde Konstellation in einem komplexen System ist, oder nicht doch eine leicht abstreitbare Hintertür ist.
Mega, danke für deine ausführliche Erklärung.