USB-Stick mit Hardware-AES-Verschlüsselung - geknackt
Zertifizierung hin, 256-Bit-AES her – die beste Verschlüsselung nützt nichts, wenn eine nachträglich angestrickte Zusatzfunktion das Passwort preisgibt.
Bei diesem Test der Objectif Sécurité [1] ging es nicht um einen USB-Stick mit ein bisschen Sicherheit für Dummies. Die bereits letztes Jahr in c't kurz vorgestellten Stealth MXP Sticks von MXI Security können immerhin mit einer FIPS-140-2-Zertifizierung aufwarten [1]. Und das bedeutet, dass sie das US-amerikanische National Institute of Standards and Technology (NIST) nach ausgiebigen Tests als sicher für den Einsatz in Bundesbehörden erklärt hat [2].
Schon der erste Eindruck bestätigt: Hier waren keine Anfänger am Werk. Die Stealth MXP Sticks haben einen eigenen Prozessor und einen FPGA-Chip, der AES-Verschlüsselung in Hardware umsetzt und sich gegen Auslesen der Programmierung sperren lässt (Actel ProASIC 3 A3P250). Die Markierung des Prozessors und eines Speicherbausteins sind weggekratzt, um Reverse Engineering zu erschweren. Optional kommt noch ein Fingerabdruckleser hinzu.
Verschlüsselt
Wenn man den Stick einsteckt, sieht man zunächst nur eine Partition, die man lesen und sogar beschreiben kann. Sie wird allerdings bei jedem Einstecken wieder auf den Originalzustand zurückgesetzt, was einen Angriff mit trojanisierten Programmen verhindert. Das dort abgelegte Programm namens Start.exe präsentiert einen Login-Dialog für Benutzernamen und Passwort. Nach der erfolgreichen Anmeldung erscheint ein zweites Laufwerk, dessen Inhalt der Stick laut FIPS-Prüfprotokoll mit AES-256 transparent ver- und entschlüsselt.
Die Authentifizierung via Fingerabdruck erfordert kein Programm; man fährt mit dem Finger einfach über den Abdruckleser. Dies funktioniert somit auch unter Linux oder sogar am Autoradio. Für die Verwaltung des Sticks ist man jedoch auf Windows-Software angewiesen.
Unsere Analyse im Debugger zeigte, dass die Kommunikation zwischen der Software und dem Prozessor auf dem Stick über den USB-Port ebenfalls verschlüsselt erfolgt. Sie ergab beispielsweise, dass die Funktion SSD_AuthenticatePassword eine Anfrage an den Stick zunächst mit SSD_MSG_Encode vorbereitet, dann mit CipherSession::encrypt verschlüsselt und schließlich via Stealth_DeviceCom::SendRequest sendet. Die Überprüfung des Passworts und auch von Fingerabdrücken erfolgt also offenbar wie im Zertifizierungsprofil festgelegt auf dem Stick und nicht im PC, wo sie angreifbar wäre.
An diesem Punkt hätten wir – beeindruckt von so viel Sicherheit und offiziellen Zertifizierungen – den Test beinahe abgebrochen. Doch bei einem abschließenden Blick ... [2]
Verschusselt
Verschusselt
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!
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.
Literatur
[1] Christiane Rütten, Datenbunker [3] (kostenpflichtiger Download), c't 14/07, S.61
[2] Policy For Stealth MXP [4], Geprüfte FIPS-Policy (PDF)
[3] Karsten Nohl, Kunterbuntes Schlüsselraten, Von Wörterbüchern und Regenbögen [5], c't 15/08, S.190
[4] Security Bulletin: MXI06-001 [6], Sicherheitsnotiz von MXI Security
(ju [7])
URL dieses Artikels:
https://www.heise.de/-270086
Links in diesem Artikel:
[1] http://www.objectif-securite.ch/en/index.php
[2] #page2-u1
[3] http://www.heise.de/kiosk/archiv/ct/2007/14/60_kiosk
[4] http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp748.pdf
[5] https://www.heise.de/hintergrund/Von-Woerterbuechern-und-Regenboegen-270088.html
[6] http://www.mxisecurity.com/mxi/categories/display/23
[7] mailto:ju@ct.de
Copyright © 2008 Heise Medien