Nachdem wir im letzten Blog Post auf die notwendigen systemweiten Parametereinstellungen für die Vergabe von Passwörtern in SAP hingewiesen haben, machen wir uns jetzt die Hände schmutzig und zeigen, wie unsichere Passwort Hashes in SAP Schritt für Schritt geknackt werden können.
In welcher Tabelle stehen die Passwort Hashes in SAP?
Als kleine Gedankenstütze aus dem letzten Blog Post sei noch einmal erwähnt, dass die gehashten Passwörter in SAP in der Tabelle USR02 zu finden sind. Sie haben außerdem die Parametereinstellungen und notwendigen Grundlagen von Hash Funktionen verpasst? Dann empfehle ich an dieser Stelle nochmal den Artikel:
SAP Cybersecurity: Wie sicher sind Ihre Passwörter?
Besonders die Parametereinstellungen werden im nachfolgenden noch sehr hilfreich sein, weshalb ich diesen Abschnitt verstärkt empfehle.
Die Vorbereitungen zum Cracken von Passwort Hashes
Nach kurzer Recherche habe ich mich für das Tool HashCat zum cracken / knacken von Passwort Hashes in SAP entschieden. Die Anwendung auf Kommandozeile schreckt zunächst erstmal ab, aber sobald man sich ein wenig mit dem Tool auseinandergesetzt hat, dann geht es auch zügig von der Hand. Eine Gruppe aus Entwicklern hat sich zudem hingesetzt und eine GUI programmiert, die ich allerdings nicht getestet habe. HashCat finden Sie hier.
Nachdem wir das Tool runtergeladen haben, werfen wir nochmal einen Blick auf die unterstützten Algorithmen von HashCat. In der Liste der unterstützten Hash Algorithmen finden wir unter anderem:
- SAP CODVN B (BCODE)
- SAP CODVN F/G (PASSCODE)
- SAP CODVN H (PWDSALTEDHASH) iSSHA-1
Das ist seltsam. Im letzten Artikel wurde doch nur der PASSCODE erwähnt und was bedeutet eigentlich CODVN B / F / G / H? Aber eins nach dem anderen. Gehen wir nochmal einen Schritt zurück. In der Tabelle USR02 finden sich unter Umständen neben dem Feld PASSCODE noch weitere Felder, in denen, je nach Konfiguration, SAP das Passwort speichern kann. Dazu gehören die Felder BCODE und PWDSALTEDHASH. Soweit allerdings nur die halbe Wahrheit über die Felder BCODE, PASSCODE und PWDSALTEDHASH. Im letzten Blog Post wurden bereits die Hash Algorithmen MD5, SHA1 und SHA2 erwähnt. Aber woher weiß ich denn, welcher Hash Algorithmus verwendet wurde? Ganz einfach: Sofern das Feld BCODE einen Wert enthält, kann man sich sicher sein, dass der MD5 Algorithmus verwendet wird. Dieser ist im Vergleich zum SHA1 nochmals deutlich unsicherer und besteht in SAP aus maximal 8 Zeichen, wobei alle Buchstaben als Großbuchstaben gespeichert werden. Warum das aus Sicherheitsgesichtspunkten ein Nachteil darstellt, wird später erläutert, wenn es um die Einstellungen zum Knacken geht.
Im Gegensatz zum BCODE wird der Passwort Hash im Feld PASSCODE nicht mit dem MD5 Algorithmus gehashed, sondern mit SHA1. Außerdem kann das Passwort bis zu 40 Zeichen lang werden und die Buchstaben werden unter Berücksichtigung der Groß-und Kleinschreibung gespeichert (case-sensitive).
In der SAP Tabelle USR02 findet sich außerdem ein Feld mit der Bezeichnung „CODVN“ (Codeversion des Kennworthash-Algorithmus (neue Systeme)). Einen guten Überblick dazu finden Sie im Blog von Daniel Berlin zum Thema:
Im Grund genommen steht in dem Feld „CODVN“ noch einmal, welcher Hash Algorithmus verwendet wurde. Diese Informationen nutzen wir später zum Cracken des Passworts.
Der Hash Algorithmus und der Salt
In der Regel findet sich bereits einer oder beide der genannten Passwort Hashes in der USR02. Die sicherste Variante der drei ist der iSSHA-1 Algorithmus. Dieser kann ebenfalls bis zu 40 Zeichen lang sein, beinhaltet im Unterschied zum MD5 und SHA1 allerdings einen zufälligen Salt. Ein Salt erschwert das Knacken von Passwörtern ein wenig, da es zum eigentlichen Passwort hinzugefügt wird, sodass gleiche Passwörter nicht zum gleichen Hash Wert führen. Beim MD5 und SHA1 Algorithmus verwendet SAP entweder die ersten 1-6 Buchstaben des Usernames (Feld USNAM) oder den kompletten Usernamen, der mit einem $-Zeichen vom Passwort getrennt wird.
Dazu ein kleines Beispiel:
Hans ist neu im Unternehmen und soll nach dem ersten Login in SAP sein Initialpasswort ändern. Weil Hans sich das Leben leichtmachen will, verwendet er überall das gleiche Passwort. Das setzt sich aus dem Ort seiner Geburt „Bremen“ und seinem Geburtsjahr 1983 zusammen. Hans muss laut Policy schließlich mindestens eine Zahl und einen Großbuchstaben verwenden. Zu seinem Glück ist es auch noch zwischen 6 und 8 Zeichen lang.
Hans Passwort lautet damit: Bremen83
Hans Username wurde vom Admin auf „Hans“ gesetzt, damit es leicht zu merken ist.
In diesem Beispiel wird der MD5 Algorithmus verwendet und SAP berechnet folglich den Hash Wert mit der folgenden Zeichenkette:
HANS$BREMEN83
Das Ergebnis des MD5-Algorithmus lautet damit:
ccd1890a8473069a27bb98a16a1ca4cb
Soweit zum Verständnis der Generierung von Hash Werten.
Das Cracken der Hashes
Ein Angreifer möchte natürlich nicht den gehashten Wert, sondern das Passwort als Klartext. Folglich möchte ein Hacker den Hash Wert entschlüsseln. Doch wie erhält man aus dem MD5-Wert von Hans:
ccd1890a8473069a27bb98a16a1ca4cb
wieder den Klartext?
Das erscheint zunächst komplizierter, als es eigentlich ist. Zunächst tragen wir alle Informationen zusammen, die wir bereits über die Passwörter sammeln konnten. Beginnen wir bei den Parametereinstellungen aus dem letzten Blog Post:
Passwortmindestlänge: 6 bedingt durch den verwendeten Algorithmus haben wir ein Maximum von 8 Stellen
Mindestanzahl Buchstaben: 1
Mindestanzahl Zahlen: 1
Mindestanzahl Sonderzeichen: 0
Alleine diese Informationen bringen uns schon ein ganzes Stück weiter. Zusätzlich wissen wir aufgrund des Wertes „CODVN B“, dass ein gespeichertes Passwort lediglich Großbuchstaben enthält. Diese Erkenntnis alleine reduziert die Anzahl möglicher Passworte um den Faktor 26, weil wir nur auf Großbuchstaben testen müssen. Wie dem Blog von Daniel Berlin zu entnehmen ist, können lediglich ASCII Zeichen verwendet werden. Bedeutet, dass jede Stelle 128 mögliche Zeichen annehmen kann. Da laut Policy allerdings keine Sonderzeichen verlangt werden, stellen wir als Angreifer die These auf, dass auch keine verwendet werden. Damit reduzieren sich die möglichen Zeichen auf die 36 folgenden Zeichen pro Stelle (Kleinschreibung und Sonderzeichen entfallen):
ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789
Würde bedeuten, dass bei einem sechsstelligen Passwort 366 = 2.176.782.336 Möglichkeiten bestehen, die das Passwort annehmen kann. Klingt zunächst recht viel oder? Ist es heutzutage aber leider nicht mehr. Bei einem Test schaffte mein knapp 7 Jahre alter Computer zwischen 30.000.000 und 50.000.000 Möglichkeiten die Sekunde. Bedeutet im Worst-Case, wenn das Tool alle 2,2 Milliarden Möglichkeiten ausprobieren muss, eine Wartezeit von knapp 2 Minuten, bis das Passwort ersichtlich wird. Die Zeit erhöht sich selbsterklärend, sofern das Passwort mehr Stellen hat. Bei 8 Stellen gibt es bereits 368 = 2.821.109.907.456 Möglichkeiten. Selbstverständlich haben wir auch die Mühen nicht gescheut. Im schlechtesten Fall braucht mein alter Computer ca. 1 Tag und 6 Stunden für das Ausprobieren aller Möglichkeiten mit 8 Stellen. Für einen Hacker eine überschaubare Zeit, wenn man sich ausmalen mag, was man damit alles anstellen könnte. In meinem Test hat es übrigens ca. 6-7 Stunden gedauert, bis das Passwort ersichtlich war. Außerdem bestehen eine Vielzahl an Optionen zur Parallelisierung des Crackings, wodurch das Ausprobieren deutlich beschleunigt werden kann.
Das Cracken mit HashCat
Für das Knacken der Passwörter habe ich wie bereits erwähnt HashCat verwendet. Nach dem entpackten gestaltet sich der Vorgang recht einfach. Zunächst startet man die Eingabeaufforderung von Windows (Windows Taste – CMD) und navigiert zum entpackten Pfad von HashCat. In meinem Beispiel liegt HashCat unter D:\Programme\:
„D:“
„cd Programme\HashCat 3.6.0“
Anschließend gibt man „hashcat64.exe –help“ ein. Dann erscheinen alle möglichen Einstellungen und Optionen für das Starten von HashCat. Wir beschränken uns auf das Wesentliche und verwenden die Optionen:
-a 3 „Brute-Force Attacke“
-m 7700 „Modus SAP CODVN B (BCODE)“
Und geben zusätzlich noch unsere Erkenntnisse (Großbuchstaben und Zahlen) über das Passwort mit an:
-1 ?u?d
beschreibt eine benutzerdefinierte Zeichenkette, bestehend aus Großbuchstaben (?u) und Zahlen (?d)“. Zusätzlich müssen wir unter Verwendung einer benutzerdefinierten Zeichenkette hinter dem Hash Wert eine Mask angeben, die definiert, wie lang das Passwort ist:
?1?1?1?1?1?1?1?1
Da wir wissen, dass ein Passwort unter Verwendung des CODVN B maximal 8 Zeichen haben kann, setzen wir die Mask folglich auf 8 Zeichen. Allerdings lassen wir alle Passwörter mit weniger Zeichen mit dem Vorgehen außer Acht. Daher verwenden wir zusätzlich den Parameter:
–increment
Dieser bewirkt, dass alle Möglichkeiten ausprobiert werden vom einstelligen bis zum achtstelligen Passwort. Außerdem müssen wir natürlich den Hash Wert unter vorangestelltem Nutzernamen (Salt) mit angeben.
Damit HashCat weiß, wo das Passwort gespeichert werden soll, verwenden wir zusätzlich den Output-Parameter unter Angabe einer Textdatei, die im gleichen Ordner wie die hashcat64.exe zu finden sein wird.
-o plain.txt
Die komplette Eingabe sieht bei mir dann folgendermaßen aus:
D:\Programme\HashCat 3.6.0\hashcat64.exe -a 3 -m 7700 -1 ?u?d HANS$ccd1890a8473069a27bb98a16a1ca4cb ?1?1?1?1?1?1?1?1 -o plain.txt –increment
Hinweis: Der Hash Wert im Feld BCODE aus SAP hat lediglich 16 Zeichen. Im vorliegenden Fall dient der Hash Wert lediglich der Veranschaulichung und wird unter der Verwendung von HashCat nicht funktionieren, da er zu lang ist.
Wie können SAP Hashes abgesichert werden?
Im Grunde genommen muss man sich nur fragen, wie eine solche Schwachstelle zu Stande kommt. Da SAP ein historisch gewachsenes ERP System ist und auf Schwachstellen reagieren musste, ohne Unternehmen abzuhängen und gleichzeitig rückwärtskompatibel zu sein, kann die Kompatibilität über die Profilparameter eingestellt werden. Über die Transaktion RZ11 unter Eingabe des Profilparameters „login/password_downwards_compatibility“ kann die Kompatibilität eingesehen und verändert werden. Ein Wert von „1“ entspricht dem Standard, der dazu führt, dass auch die alten Hash Werte (mit MD5 und SHA1) berechnet werden. Ändern Sie den Wert auf „0“, so werden die alten Hash Werte nicht mehr berechnet und es wird lediglich der bislang sicherste Hash Wert mit dem iSSHA1-Algorithmus berechnet. Ein kleiner Hinweis an dieser Stelle: Die Änderungen werden erst nach einem Neustart der Instanz wirksam.
Mit der Änderung des Profilparameters auf „0“ sind Sie allerdings noch nicht auf der sicheren Seite. Denn die alten Hash Werte befinden sich nach wie vor in dem SAP System. Allerdings kann ich Sie beruhigen. Auch diesen Umstand können wir bereinigen. Mittels der Transaktion „SA38“ und dem Programm „CLEANUP_PASSWORD_HASH_VALUES“ werden alle schwachen Hash Werte mandantenübergreifend aus der Datenbank entfernt.
Die Verwendung erfolgt ausschließlich auf eigene Gefahr und es sei nochmal darauf hingewiesen, dass ein Cracken von SAP Passwörtern nur nach ausdrücklicher Rücksprache mit den entsprechenden Verantwortlichen gestattet ist. Wir übernehmen keine Verantwortung für eventuelle Schäden, die z.B. aufgrund der hohen Prozessorlast / Grafikkartenlast oder falschen Einstellungen entstehen können.
