Sie sind hier: Zentrale | Sicherheit | Passwort-Sicherheits-Check  Harry Boeck - Heimserver

Passwort-Sicherheits-Check

John the Ripper

Veranlassung zu diesen Betrachtungen: Meldung über eine Aktualisierung des Werkzeugs bei Heise

Leider habe ich keine veröffentlichten Konfigurationen zum selbst kompilieren für Windows unter GCC oder einer der MSVC-Versionen gefunden, und zum selbst Zusammenstellen solcher Pakete fehlt mir die Muße, etliche Wochen meines Lebens zu opfern. Glücklicherweise gibt's vorkompilierte Pakete, dank denen die Installation auch unter Windows trivial ist.

Da auf meinem System "Write-xor-Execute" gilt, sind die zur Installation gehörenden Dateien strikt von allem, was nutzungsspezifisch ist, getrennt. Das steht zunächst mal im Widerspruch zur DOS-Playmobil-Philosophie der Programmierer, die das Windows-Paket angepaßt haben. Danach wäre man gezwungen, die Nutzerdaten mit den Installationsdateien zu vermischen und Schreibrechte im Installationsverzeichnis zuzulassen. Entsprechend habe ich Batchdateien (die global ausführbar sind) und eine im Nutzerbereich abgelegte Konfigurationsdatei ("john.conf") vorbereitet, welche die John-the-Ripper-Executables greifbar machen und die Einstellungen der Pfade an mein System anpassen.

Die in "john.conf" vordefinierte Variable "$John" wird leider nicht auf das Startverzeichnis der Exe eingestellt, sondern komplett sinnlos auf das aktuelle Verzeichnis - und kann dadurch auch einfach komplett gelöscht werden, ohne daß sich an der Funktion der Konfigdatei etwas ändert. Die Pfade zum Installationsverzeichnis sind als Absolutpfade einzutragen (war zumindest meine anfängliche Vermutung - Korrektur weiter unten).

Zum Test, ob das ganze funktioniert, habe ich die Handlungen laut einem Einsteiger-Tutorial ausgeführt. Da ich allerdings bei mir kein DES verwende, sondern vorzugsweise Blowfish (was beim Ripper auf der Kommandozeile "bf" sein dürfte), war ich an einem Test-Passwort in dieser Verschlüsselung interessiert und wühlte mich dazu durch jene Tutorial-Ecken, in denen es um das Format der Konten-Datei ging, die für den Ripper das Ausgangsmaterial darstellt...

Ich fand zunächst nur Hinweise darauf, daß der Passwort-Hash letztlich in base64 kodiert und vom Kontennamen mit einem Doppelpunkt getrennt sein sollte, jedoch keinerlei weitere Hinweise (auf eventuell erlaubte Leerzeichen, Trennzeichen, Zeilenvorschubvarianten, erlaubte oder erforderliche Paddings und dergleichen denkbares). In den Tutorials wurde auch nirgendwo näher auf die Zusammensetzung oder Erzeugung dieser Kontendatei eingegangen. Ausschließlich auf deren Extraktion aus Konten unter Linux.

Ich schrieb mir also eine kleine Batchdatei, die per openssl ein Blowfish-kodiertes Passwort erzeugt, das in base64 abglegt und einen Kontennamen samt Doppelpunkt davor setzt. Sah alles vom Anschein her korrekt aus.

Das Ergebnis war niederschmetternd: "No password hashes loaded (see FAQ)"

Die FAQ dazu war noch niederschmetternder: Abgesehen davon, daß das Ding offenbar an einem 80er-Jahre-Modem im Internet hängt, war dort nur der läppische und vollkommen unbrauchbare (woran erkennt man, daß man es mit der Hotline von Microsoft zu tun hat?) Kommentar zu finden:

Your password file taken from a Unix-like system might be shadowed. 
You need to get both /etc/passwd and the shadow file (typically /etc/shadow or /etc/master.passwd), 
and combine them into one file using "unshadow" (which is supplied with John).
Please refer to EXAMPLES.
	
Hmmmhmmm... Ja. Klar. Hätte ich noch meine jugendlichen Zähne, wäre eine Wellenlinie im Tisch gewesen...

"Procmon" von Sysinternals gab keinen weiteren Aufschluß: Ich hatte erstmal damit gerechnet, daß die Programmierer zu dämlich hätten sein können, auf einem Windows-System eine Datei laden zu lassen (indem sie irgendwelche schwachsinnigen Annahmen zu Standardpfaden voraussetzen oder dergleichen anstatt das aktuelle Verzeichnis zu benutzen). Das wars jedoch nicht.

Auf der Suche im Internet, was denn nun diese mystifizistische Fehlermeldung hergott nochmal zu bedeuten hätte (es IST ja tatsächlich gar nicht SOOO schwer, wie wir gleich sehen werden), habe ich KEINEN EINZIGEN Fund angetroffen, wo die tatsächliche Ursache behandelt worden wäre. Statt dessen - natürlich - immer nur pur blinde Schüsse ins Blaue hinein und in der Regel nach dem Motto: "Da mußte dann eben Deinen Rechner komplett plätten, Linux ganz frisch aufsetzen, dat System aktualisieren und dann wird dat schon laufen... Bei mir geht dat schließlich auch!"

Leider reichte mein eigener Verstand allerdings auch nicht für die Schnellösung: Ich hätte nur mal genau den im Tutorial vorgesetzten Inhalt der Kontendatei copy-pasten brauchen und alles wäre gut gewesen.

Der gesunde Menschenverstand brachte mich dann aber dennoch dazu, mal davon auszugehen, daß das Format - EBEN WEIL es dazu keinerlei weitere Beschreibung gab - als schuldig anzunehmen sei, und was anderes zu probieren. Namentlich eine ganz simple sha1-Verschlüsselung (wo das base64 schon mit drin ist).

Ja, und das war's dann. Vom Ripper wird das dann im Log als "raw-sha1" bezeichnet.

Diese Fehlermeldung No password hashes loaded (see FAQ) bedeutet also im Klartext:

Die Konfigdateien konnten geladen werden (fein!),
die Laufzeitumgebung stimmt (fein!),
die Konten-Datei konnte geladen werden (klasse!),
aber es konnte kein Eintrag nach dem erwarteten Format erkannt werden (:'(
Das erwartete Format suchen Sie bitte beim Orakel in Griechenland!
	
Gut: Wie das mit "raw-sha1" funktioniert, wußte ich damit ja zumindest schonmal im Ansatz...



Das Problem mit der Ripper-Dokumentation: Sie ist zum Arsch abwischen und runterspülen! Sie wird von verfreakten Script-Kiddies für verfreakte Script-Kiddies gemacht, die erstens keine Dokumentation mehr benötigen, bestenfalls ein paar Erinnerungs-Stichpunkte, und die zweitens in der sozialen Kompetenz zur Erläuterung von Sachverhalten auf dem Niveau von Affen herumlungern...

Nach knapp einem Jahr hatte ich mal wieder mit dem Ripper herumgespielt und - natürlich - ein geringfügig anders aussehendes Problem gehabt. Diesmal hatte ich einen md5-Wert zu bruteforcen (ja: NEIN, ich bin kein Verbrecher und/oder Geheimdienstler, der das täglich, massenweise und berufsmäßig macht, um andere Leute zum Geldverdienen zu erpressen, daher nur einen einzigen Problemfall innerhalb eines Jahres).

Die gesamte im Netz zu findende Dokumentation über den Ripper enthält außer völlig belanglosen Hinweisen zum Cracken von Linux- und Windows-Betriebssystem-Passwort-Dateien für Script-Kiddies (wo entweder weit unterhalb der Gürtellinie in copy&paste eingeführt wird oder aber weit oberhalb der Gürteilinie irgendwelche verfreakten Details des Password-Crackens in speziellen Umgebungen bis zum Erbrechen durchgenudelt wird) restlos nichts, wo das konkrete Format der vorausgesetzten Dateien erläutert werden würde.

Namentlich ging es diesmal darum, daß mir der MD5-Wert mit Großbuchstaben notiert in Hexadezimalschreibweise (als "raw-md5" bezeichnet) vorlag. Wobei ich natürlich den Vorgabewert schlicht mit copy&paste übernahm. Und nicht im Traum davon ausging, daß jemand sich da an irgendwas stören können würde. JTR aber verarbeitet ausschließlich Kleinbuchstaben in den hexadezimal notierten Werten.

Ansonsten kommt wieder diese grenzenlos vielsagende Fehlermeldung:

"No password hashes loaded (see FAQ)"

Ich meine: So ein minimmalistischer Hinweis, daß hexasezimal kodierte Werte ihre Buchstaben in Kleinschreibweise benötigen, ist doch nicht zuviel verlangt, oder? Wenn es zu den zentral zwingenden Bedingungen gehört, daß das Zeug fuktioniert?! Zumal die trivialen Umsetzungsfunktionen, die man üblicherweise als Anfängerübung kodiert, es bestenfalls genau andersrum erwarten: Da werden Großbuchstaben vorausgesetzt, nicht Kleinbuchstaben.

Sowas ist ein Paradebeispiel für falsch verstandene Prinzipien von Exceptionbehandlungen: Es gibt sehr wohl sehr konkrete Ursachen für die Fehlerzustände. Die Programmierer von JTR haben die aber nicht nahe an der Entstehungsursache behandelt, sondern irgendwo weit oben zentral bündeln lassen. JEDWEDE Art von Fehler bei Navigieren zur Datei, beim Laden der Datei, beim zeilenweisen Zerlegen, beim Interpretieren der Werte und selbst beim Umwandeln von hex in binär gilt bei denen rundweg über einen Kamm geschert als:

"No password hashes loaded (see FAQ)"

Und dann waren sie darüber hinaus zu dämlich, die konkreten Ursachen wenigstens als Textnachricht durchzureichen.

Klasse! Profis!



Danach kommt aber erstmal noch die Fehlermeldung "fopen: password.lst: No such file or directory"...

Na gut: Das ist ein Fehler analog denen, die ganz zu Anfang die Konfig-Dateien bemeckert hatten, weil die in "john.conf" stehenden Pfade halt in DOS-Playmobil-Mentalität ausgelegt sind ("alles in einen Topf und kräftig rühren!")... OK, kein Ding: Tragen wir halt überall in der Konfig-Datei mal den Absolutpfad ein in der Art...

[Incremental:Alpha]
File = /Werkzeug/System/Security/JohnTheRipper/run/alpha.chr
	
Das beseitigt aber die Fehlermeldung nicht.
Kontrolle mittels Procmon liefert:

PATH NOT FOUND "D:\Werkzeug\System\Security\JohnTheRipper\Werkzeug\System\Security\JohnTheRipper\run\alpha.chr"

Aha! Der Pfad ist also mitnichten als Absolutpfad gemeint (meine ursprüngliche Vermutung), sondern relativ zum Verzeichnis oberhalb des Installationsortes von "john.exe". Wenn man KEIN "$John" in den Pfadnamen schreibt.

Das muß ja nur einfach mal gesagt werden, gelle?!

Wir ändern also in:

[Incremental:Alpha]
File = /run/alpha.chr
	
(und alle äquivalenten Stellen genauso) ...und: jau, da legt er los mit Probieren...

Ich hab erstmal mit einem extrem einfachen Passwort angefangen ("Hans"), aber der Ripper braucht auf meinem System offenbar schon für sowas simples eine wahre Ewigkeit...
Es KANN natürlich auch sein, daß die Hashes eben doch auf eine ganz bestimmte Art und Weise vorbehandelt werden müssen (da sie solches MÖGLICHERWEISE unter Linux oder Windows oder was auch immer SIND - keine Ahnung, hab selber nch nicht bei Microsoft oder im Linux-Team mitgemacht...). Und daß der Ripper deshalb keine Chance hat, dieses einfache Passwort zu erkennen.
Oder "Hans" einschließlich seinen Buchstaben ist dermaßen ungewöhnlich, daß der Ripper es wirklich erst nach Tagen rauskriegen kann... (Nein, wohl eher kaum, gelle?!)

Die Logdatei erzählt nach ner halben Stunde was von "character count" in den 20ern und von "length" 7 (im alpha-Modus)... Da MUSS der schon lange über den Hans gelaufen gewesen sein... Der "pot" bleibt aber leer...

Ahhh ja: "alpha" testet ja nur Kleinbuchstaben...