USB-Stick mit Hardware-AES-Verschlüsselung - geknackt

Seite 2: Verschusselt

Inhaltsverzeichnis

Doch bei einem abschließenden Blick auf die Daten auf dem Heap entdeckten wir dort den Klartext-String "PwdHashes". Dahinter folgten 40 Bytes mit Daten, in die zwei SHA-1-Hashes genau hineinpassen würden. Ein schneller Test mit dem Passwort "test1234" ergab tatsächlich, dass sich die Datenstruktur um weitere 20 Bytes verlängerte – nämlich um den SHA-1-Hash unseres Testpassworts. Bingo!

Wie man mit "echo -n heise1234 | sha1sum" leicht nachprüfen kann, findet sich hier ein ungesalzener SHA1-Hash im Speicher.

Offenbar hatten die Entwickler nachträglich eine Zusatzfunktion in die Software eingebaut, die das Wiederverwenden von bereits einmal genutzten Passwörtern verhindern soll. Das ist eine in Firmenumgebungen oft geforderte Sicherheitsmaßnahme, deren realer Nutzen allerdings umstritten ist. Bei der Implementierung dieser Funktion ist den Entwicklern gleich eine ganze Reihe von Fehlern unterlaufen, die schlussendlich dann tatsächlich zum Klartextpasswort für den Zugang zum USB-Stick führten.

Wie das Fehlen von spezifischer USB-Kommunikation beweist, findet der Vergleich mit den bereits benutzten Passwörtern auf dem PC und nicht auf dem Stick statt – Fehler eins. Dazu holt sich die Software die Liste von Hashes aus einem Speicherbereich auf dem Stick. Als wir den Stick an einen zweiten, bis dahin nicht benutzten PC ansteckten und das Login- Programm starteten, fanden wir die Hashes auch dort. Das bedeutet, dass der Speicherbereich mit den Hashes – Fehler zwei – auch ganz ohne Anmeldung lesbar ist. Praktischerweise holt die Anmeldesoftware die Passwort-Hashes bereits beim Start. So genügt es, den aktiven Prozess mit einem Debugger anzuzapfen, um sie zu extrahieren.

Und da kommt der endgültig fatale, dritte Fehler: Diese Hashes sind ungesalzen. Derartige Hashes lassen sich mit passenden Rainbow-Tabellen recht einfach knacken. Selbst bei einem achtstelligen Passwort aus Zahlen und Buchstaben dauerte das gerade mal 15 Minuten. Ein zusätzliches Salt hätte zumindest diesen Angriff unmöglich gemacht [3].

Wie der Hersteller bestätigte, wurde diese Zusatzfunktion erst im Nachhinein für die Enterprise-Version entwickelt; sie kommt beim Stand-Alone-Betrieb des Geräts normalerweise nicht zum Einsatz. Wird sie jedoch verwendet, untergräbt sie für einen eher fragwürdigen Sicherheitsgewinn das aufwendige Sicherheitskonzept des sonst sehr sicheren USB-Sticks. MXI Security konnte das Problem mit Hilfe unserer Beschreibung nachvollziehen. Die Firma reagierte innerhalb einer Woche mit einem Sicherheitsbulletin und einer aktualisierten Version der Software Access- Enterprise 3.1 [4]. Ein kurzer Nachtest ergab, dass diese zumindest keine ungesalzenen Hashes mehr verwendet.

[1] Christiane Rütten, Datenbunker (kostenpflichtiger Download), c't 14/07, S.61
[2] Policy For Stealth MXP, Geprüfte FIPS-Policy (PDF)
[3] Karsten Nohl, Kunterbuntes Schlüsselraten, Von Wörterbüchern und Regenbögen, c't 15/08, S.190
[4] Security Bulletin: MXI06-001, Sicherheitsnotiz von MXI Security (ju)