Festplattenverschlüsselung mit Brute-Force knacken

Inhaltsverzeichnis

Die letzten sechs Monate forschte ich als Gast-Wissenschaftlerin in Japan. ­Meinen schweren Desktop-Rechner habe ich für diese Reise nicht mitgenommen. Stattdessen begleitete mich ein leichtes Notebook – mit allen damit verbundenen Einschränkungen. Wieder zu Hause angekommen, konnte ich es kaum erwarten, mich an den starken Linux-PC mit mehreren Monitoren zu setzen. Ich drückte den Startknopf, der Rechner bootete und Ubuntu begrüßte mich Weiß auf Lila mit „Please unlock disk sda3_crypt“. Der Rechner wartete auf mein Passwort, denn bei der Installation hatte ich mit der Linux-Festplattenverschlüsselung LUKS eine verschlüsselte Partition erstellt. Den Rechner hatte ich vor sechs Monaten zuletzt benutzt und jeden Account und jedes meiner Geräte hatte ich mit einem individuellen Passwort abgesichert. Nun fiel mir das für die LUKS-Partition einfach nicht mehr ein!

Verzweifelt probierte ich händisch eine Reihe verschiedener Passwörter, aber keines gewährte mir Einlass ins Linux. Den Rechner deswegen neu aufzusetzen war keine Lösung, denn ich wusste von ein paar Dateien auf dem PC, die in meinem Backup fehlten. Trotzig dachte ich mir: „Ich bin doch Expertin für IT-­Sicherheit, ich hacke jetzt meinen eigenen Rechner.“ Bei dem Gedanken musste ich schmunzeln. Denn Verschlüsselung gibt es ja nicht grundlos. Sie soll mich genau vor jenen Leuten schützen, die ohne Passwort an meine Daten möchten. Trotzdem wollte ich es versuchen.

Zuerst baute ich die SSD aus und schloss sie über einen geliehenen SATA-­USB-Adapter an einen anderen Linux-­Rechner an. Prompt forderte mich das zweite Linux auf, mein vergessenes Passwort einzugeben – kein Fortschritt!

Mit der gesamten LUKS-Partition zu arbeiten dauerte entschieden zu lang. Daher exportierte ich den LUKS Header – wenige Daten, die genügen, um Pass­wörter auszuprobieren:

sudo cryptsetup luksHeaderBackup /dev/UUID --header-backup-file backup

Angriff mit roher Gewalt

Bei der Suche nach Open-Source-Programmen zum Knacken meines eigenen Passworts stieß ich zuerst auf bruteforce-luks, ein Konsolentool, welches für meine Attacke passend erschien. Zahlreiche Parameter erlauben den Passwortraum, also die Menge auszuprobierender Passwörter für die Brute-Force-Attacke einzuschränken, sofern man sich an Teile das Passworts oder dessen Länge erinnern kann. Ich startete mit 8 bis 14 Zeichen Länge (-l 8 -m 14):

bruteforce-luks -t 8 -v 30 -l 8 -m 14 /tmp/luks-header

Dies startete einen Prozess mit acht Threads (-t 8), der mir alle 30 Sekunden (-v 30) ein Status-Update anzeigte. Das erste Statusupdate verkündete mir direkt schlechte Nachrichten: „ETA more than 200 years :(“

Genau für so etwas ist Verschlüsselung ja gemacht: Das Raten des richtigen Passworts soll so richtig viel Zeit in Anspruch nehmen.

Ich überlegte, wie ich das irgendwie beschleunigen könnte. Vielleicht fallen mir ja Teile des Passworts ein oder ich kann ­welche ausschließen? Oder finde ich eine Möglichkeit, den Prozess mit einer GPU zu parallelisieren? Ich setzte mich vor den Rechner und starrte den Bildschirm an, während ich nach Assoziationen zu meinem Passwort suchte. Und tatsächlich ­fielen mir nach längerem Überlegen die letzten sieben Zeichen meines Passworts ein! Mit dieser Information sollte ich die Attacke enorm verkürzen können.

Also stoppte ich den Brute-Force-­Prozess und startete einen neuen mit

bruteforce-luks -t 8 -v 30 -l 10 -m 14 -e "abcdefg" /tmp/luks-header

Das erste Status-Update erschütterte meine neu gewonnene Zuversicht, denn an den über 200 Jahren Rechenzeit änderte sich gar nichts. Das Passwort war schlicht zu lang.

Also machte ich mir weitere Gedanken, um die Länge und mögliche Zeichen, die ich (nicht) verwendet haben könnte (Parameter -s). So verkleinerte ich das mögliche Passwortalphabet und kam zum ersten Mal auf ein konkretes Datum: 24. Dezember 2057 – na toll, Weihnachten in nur 37 Jahren.

Erneut setzte ich mich an die Tastatur und dachte nach. Diesmal versuchte ich mich „sensorisch“ zu erinnern das Passwort einzugeben. So als würde ich hören, wie ich die Tasten anschlug. Ich kam mir esoterisch vor, war aber trotzdem sicher, dass mein Passwort exakt elf Zeichen haben muss. Der Konsolenbefehl sah nun wie folgt aus:

bruteforce-luks -t 8 -v 30 -1 11 -m 11 -e "abcdefg" /tmp/luks-header

Schnellere Alternative

Mit dieser Einschränkung hätte ich nur noch maximal vier Jahre rechnen müssen. Auch wenn das wie ein großer Fortschritt wirkt, waren vier Jahre Rechenzeit für mich inakzeptabel. Eine schnellere Alternative musste her!

Durch weitere Recherchen stieß ich dann auf hashcat – ein Tool, das auch die GPU für mehr parallele Berechnungen einspannt. hashcat brauchte einen ­anderen Header als bruteforce-luks, den der folgende Befehl extrahiert:

sudo dd if=/dev/UUID of=luks_header bs=1M count=5

Mit dem neuen Header konnte ich nun die zweite Brute-Force-Attacke in Gang setzen. Damit die möglichst wenig ausprobieren muss, legte ich ein sogenanntes „Maskfile“ an. Diese Datei legt die Struktur des Passworts sowie das Passwort­alphabet fest. Der Inhalt meines Maskfiles sah folgendermaßen aus:

?u?l?d,?1?1?1?1abcdefg

?u steht für einen Großbuchstaben, ?l für einen Kleinbuchstaben, ?d für eine Ziffer. Zusammen definiert das die Menge der alphanumerischen Zeichen. Das Komma (,) zeigt Hashcat, dass davor nur die erste selbst definierte Zeichenmenge steht (Custom-Charset 1) und noch nicht die Maske. Die folgt nämlich direkt danach: Die vier ?1 legen fest, dass die ersten vier Zeichen des Passworts alphanumerisch sein müssen. Den Rest setzt das Maskfile fest auf „abcdefg“ – daran konnte ich mich ja erinnern. Die Attacke begann mit folgendem Befehl:

./hashcat64.bin --force --attack-mode 3 --hash-type 14600 --outfile recovered_passphrase ../luks_header ../mask_file.hcmask

Die Eingabe eines s zeigt den aktuellen Status an: Hashcat verwendete die GPU und deren Temperatur betrug bereits 77 °C. Es fing ordentlich an zu brummen. Die verbleibende Rechenzeit schätzte Hashcat auf sechs Stunden – also noch am gleichen Tag! Ich war positiv überrascht, immerhin bekam ich kurz zuvor noch über 200 Jahre angezeigt..

Glücklich gefunden

Nach viereinhalb Stunden war das Programm fertig und ich öffnete die Aus­gabe-Datei recovered_passphrase. Darin stand ein Passwort! Aufgekratzt schloss ich die SSD per USB an und gab das Passwort ein – es tat sich nichts. Das Zweit-­Linux behauptete aber auch nicht, dass das Passwort falsch sei.

Voller Nervosität und Vorfreude verlor ich die Geduld und baute die SSD wieder in den PC ein. Er bootete und ich wartete gespannt wie ein Bogen auf den lila Bildschirm. Ich gab das Passwort ein. Für einen Wimpernschlag passierte nichts. Dann erschien Anmeldebildschirm – das Passwort war richtig!

Umkehrschlüsse erwünscht

Letztlich bin ich da noch mal glimpflich davongekommen! Hätte ich mich nicht an den größten Teil des Passworts und die Gesamtlänge erinnert, hätte mir weder Hashcat noch die parallele Rechenpower der Grafikkarte geholfen. Aus meiner ­Erfahrung lässt sich aber ein nützlicher Umkehrschluss ableiten: Können Angreifer große Teile eines Passworts erraten, haben Sie bessere Chancen den fehlenden Teil zu berechnen. Ein Passwortsystem, bei dem sich nur wenige Zeichen von Dienst zu Dienst ändern, wird angreifbar, wenn eines der Passwörter gehackt wird. Kann der Angreifer dagegen nichts erraten, ist das Passwort sicher, sofern es lang genug ist – auch gegen Angriffe von einem selbst.

Dieser Artikel stammt aus c't 13/2020. (pmk)