{"id":121385,"date":"2025-01-17T15:46:00","date_gmt":"2025-01-17T13:46:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/obhod-diskovogo-shifrovaniya-ispolzuyushhego-tpm2-dlya-avtomaticheskoj-razblokirovki"},"modified":"2025-01-17T15:46:00","modified_gmt":"2025-01-17T13:46:00","slug":"obhod-diskovogo-shifrovaniya-ispolzuyushhego-tpm2-dlya-avtomaticheskoj-razblokirovki","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/news\/obhod-diskovogo-shifrovaniya-ispolzuyushhego-tpm2-dlya-avtomaticheskoj-razblokirovki","title":{"rendered":"Umgehung der Festplattenverschl\u00fcsselung, die TPM2 zur automatischen Entsperrung verwendet","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Einer der Begleitpakete in NixOS stellte eine Angriffstechnik vor, die den Zugriff auf Daten auf verschl\u00fcsselten Festplattenpartitionen erm\u00f6glicht, in Konfigurationen, die bei der Bootzeit keine Eingabe eines Entsperrpassworts erfordern, dank der Platzierung von Informationen zur Entschl\u00fcsselung im TPM2 (Trusted Platform Module). Solche Konfigurationen werden h\u00e4ufig auf Servern oder Mehrbenutzer-Workstations verwendet, auf denen es problematisch ist, nach jedem Neustart manuell ein Passwort einzugeben. <\/p>\n
Bei der Anwendung einer solchen Methode zur Festplattenverschl\u00fcsselung erfolgt die Entschl\u00fcsselung mit einem zus\u00e4tzlichen Schl\u00fcssel, der im TPM gespeichert wird und nur bei Best\u00e4tigung des urspr\u00fcnglichen Systemzustands ausgegeben wird. Der Systemzustand wird in Form von Hashes in den PCR-Registers (Platform Configuration Register) gespeichert und ist an eine digitale Signatur gebunden, mit der der Bootloader signiert ist, sowie an die Pr\u00fcfziffern des Bootloaders und der anf\u00e4nglichen Boot-Umgebung (initrd). Der Zugriff auf den Schl\u00fcssel im TPM wird nur gew\u00e4hrt, wenn alle an ihn gebundenen PCR-Register sich im gleichen Zustand befinden wie bei Speicherung des Schl\u00fcssels. <\/p>\n
Es wird angenommen, dass die Bootkette des Betriebssystems mithilfe von UEFI Secure Boot verifiziert wird und der Zugriff auf die Schl\u00fcssel nur aus einem nicht modifizierten initrd-Abbild erfolgen kann. Bei erfolgreicher \u00dcberpr\u00fcfung wird die Festplatte automatisch entsperrt, aber der Zugriff auf die entschl\u00fcsselten Daten kann nur \u00fcber die Anmeldung in ihrem Benutzerkonto im System erfolgen. Bei einem Zugriff ohne verifiziertes Booten oder beim Versuch, \u00c4nderungen am initrd vorzunehmen, um Schl\u00fcssel abzufangen, wird die Vertrauenskette unterbrochen, der Zustand der PCR-Register \u00e4ndert sich und das TPM2 gibt keine Informationen zur Entschl\u00fcsselung heraus. <\/p>\n
Die ver\u00f6ffentlichte Angriffsmethode erm\u00f6glicht es, ohne \u00c4nderung des Inhalts von initrd in Konfigurationen zu arbeiten, die verschl\u00fcsselte LUKS-Partitionen nicht identifizieren. Es wird angemerkt, dass die Aktivierung einer solchen \u00dcberpr\u00fcfung der Partitionen in allen gefundenen Anleitungen zur Einrichtung der Festplattenverschl\u00fcsselung nicht beschrieben wird, da die Identifizierung der Partition die Konfiguration wesentlich komplizierter macht (es ist erforderlich, ein zus\u00e4tzliches PCR-Register zur \u00dcberpr\u00fcfung des Partitionenschl\u00fcssels zu verwenden und initrd unter Ber\u00fccksichtigung seines Wertes zu generieren). Beispiele f\u00fcr den Angriff wurden f\u00fcr Fedora Linux in Verbindung mit dem Tool clevis und f\u00fcr NixOS in Verbindung mit systemd-cryptenroll demonstriert. F\u00fcr den Angriff ist physischer Zugriff auf den Computer und die M\u00f6glichkeit erforderlich, das Speicherger\u00e4t zu extrahieren. <\/p>\n
Die Methode basiert darauf, dass der Angreifer die vorhandene verschl\u00fcsselte Root-Partition durch seine eigene verschl\u00fcsselte Partition ersetzen kann, die mit demselben UUID-Identifikator erstellt wurde und deren Entschl\u00fcsselungsschl\u00fcssel dem Angreifer bekannt sind. Die Umgebung von initrd wird die Kontrolle an den init-Prozess in der Partition des Angreifers \u00fcbergeben. Da der Inhalt von initrd nicht ge\u00e4ndert wurde, wird der Zustand des TPM nicht gest\u00f6rt, und mit Kontrolle in seiner eigenen Umgebung kann der Angreifer TPM zur Entschl\u00fcsselung des Schl\u00fcssels der urspr\u00fcnglichen Festplattenpartition verwenden. <\/p>\n
Der Angriff l\u00e4sst sich in folgende Schritte unterteilen: <\/p>\n
\n
Extrahierung der Festplatte und Durchf\u00fchrung einer Analyse der unverschl\u00fcsselten Daten auf einer anderen Maschine in der Partition \/boot. Bestimmung der Informationen \u00fcber die verschl\u00fcsselte Partition und ihren UUID-Identifikator aus dem initrd-Image, das sich in der Partition \/boot befindet.\n
Erstellung eines Backups der ersten 64 MB der verschl\u00fcsselten LUKS-Partition.\n
Ersatz der angegebenen 64 MB durch ein Image mit der eigenen Root-Partition, die mit einem dem Angreifer bekannten Schl\u00fcssel verschl\u00fcsselt ist und denselben UUID-Identifikator wie die alte Partition hat.\n
R\u00fcckf\u00fchrung der Festplatte in den urspr\u00fcnglichen Computer und Booten von der manipulierten Root-Partition. Da die automatische Entsperrung durch den Schl\u00fcssel aus TPM f\u00fcr die manipulierte Partition fehlschl\u00e4gt, fordert initrd zur manuellen Eingabe des Passworts auf.\n
Erhalt des urspr\u00fcnglichen Schl\u00fcssels aus TPM unter Verwendung der TPM-Metadaten und des verschl\u00fcsselten Tokens aus dem LUKS-Header der alten Partition.\n
Umdisposition der Festplatte in den Computer des Angreifers, Wiederherstellung des \u00fcberschriebenen Teils der LUKS-Partition aus dem Backup und Verwendung des erhaltenen urspr\u00fcnglichen Schl\u00fcssels zum Zugriff auf die Daten. <\/ul>\n