Die Logik und der Hash der SAP Passwörter

von Daniel Berlin

In den letzten Jahren melden die Medien in zunehmender Häufigkeit, dass wieder einmal mehrere Millionen Passworte gestohlen wurden und danach im Internet auftauchen. Im Falle des Hacks eines amerikanischen Seitensprungportals war nicht nur das Bekanntwerden der Kennworte brisant, vielmehr dürfte allein das Engagement auf einer Seite mit solch eindeutigem Hintergrund für die betroffenen Nutzer peinlich sein. Dies ist aber nur eines von vielen Beispielen – es kursieren bereits viele weitere Listen mit mehreren Millionen Kennworten, teilweise sogar in Verbindung mit dem dazugehörigen Benutzernamen.

Wir werden uns in den folgenden Abschnitten ansehen, wie Passworte üblicherweise gespeichert werden und welche Absicherungsmaßnahmen notwendig sind, um sie hinreichend abzusichern. Anschließend werden wir Ihnen konkrete SAP-Einstellungen und Maßnahmen vorstellen, um die Kennworte Ihres Systems optimal zu schützen.

1.1      Technologie und Logik von Hash-Prüfungen

Als sicherheitsbewusster Leser werden Sie sich fragen, ob es denn so schwer sein kann, die simple Kombination von Benutzername und Passwort so abzusichern, dass ein Angreifer sie nicht erlangen oder zumindest nicht ausnutzen kann.

Oftmals ist das Sicherheitsverständnis der Betreiber von IT-Diensten zumindest soweit gediehen, dass sie nicht die Klartextkennworte ihrer User speichern, sondern den sogenannten Hashwert – eine kryptische Zeichenfolge, die über eine Hashfunktion errechnet wird. Das besondere an der Hashfunktion ist, dass der ursprüngliche Wert – das Klartextkennwort also – nicht aus dem Hash-Wert zurück berechnet werden kann. Es handelt sich dabei also um eine Einweg-Funktion, die nur die Umwandlung vom Klartext in den Hash-Wert erlaubt und nicht anders herum. Beim Login eines Nutzers wird dann das gesendete Passwort erneut gehasht und mit dem gespeicherten Passworthash verglichen.

Hashfunktionen werden für verschiedene Zwecke genutzt, z.B. um bei der Übertragung von Daten deren Unversehrtheit zu überprüfen – also als eine Art Prüfsumme. Hierbei ist vor allem wichtig, dass es möglichst wenige Kollisionen gibt, d.h. zwei Eingabewerte, die zum selben Hashwert führen. Beim Hashen von Passworten kommen weitere Anforderungen hinzu. Es sollte möglichst schwer sein:

• den Klartext eines Hashes zu finden
• einen zweiten Klartext zu finden, der zum selben Hashwert führt

Bekannte Hash-Algorithmen sind zum Beispiel MD5, SHA-n, RIPEMD, Whirlpool.  Die Erfahrung der letzten Jahre hat jedoch gezeigt, dass Hashfunktionen Schwachstellen aufweisen können, die einen Angriff erleichtern; zudem ist die Rechenkapazität sehr schnell gestiegen. Heutzutage ist es bereits mit einem einfachen Arbeitsplatzrechner und einer handelsüblichen Grafikkarte möglich, extrem viele Hash-Werte pro Sekunde zu berechnen und so die „Rückberechnung“ der Klartextkennworte aus den Hash-Werten einfach per Ausprobieren zu erreichen (ein sog. Brute-Force Angriff). Die Sicherheitsvorkehrungen greifen so also oftmals nicht wie gewünscht.

Gesalzene Hashwerte

Eine grundlegende Eigenschaft von Hashfunktionen ist, dass sie für gleiche Eingaben immer denselben Hashwert erzeugen. Dies ist gleichzeitig aber auch eine große Schwäche, es bedeutet nämlich auch, dass man anhand des Hashwertes erkennen kann, ob verschiedene User dasselbe Kennwort verwendet haben. Zudem muss für jedes mögliche Kennwort so nur einmal der Hashwert berechnet werden; anschließend kann man Passwort-Hashes einfach mit einer solchen Liste vorberechneter Kennworte, sog. Rainbow Tables, vergleichen. Um dies zu verhindern und den Aufwand eines Angriffs zu erhöhen, verwendet man ein sog. Salt – einen Wert, der an das Kennwort vor der Hasherzeugung angehängt wird. Dadurch kann ein Passwort-Hashwert nicht einfach in einer vorberechneten Liste nachgeschlagen werden, da diese Liste alle möglichen Kennworte in Kombination mit allen möglichen Salt-Werten enthalten müsste. Diese zu erzeugen, wäre jedoch vom Rechen- und Speicheraufwand kaum durchführbar.

Auch wenn die Informationspolitik der gehackten Firmen und Webseiten funktioniert und die User gewarnt und zu einem Passwortwechsel veranlasst werden, so ist es doch traurige Wahrheit, dass viele Benutzer ein einmal gewähltes Kennwort wiederverwenden – wenn auch in leicht modifizierter Form. Dieser Umstand erlaubt es dann auch weniger begabten Hackern, anhand dieser Kennwortlisten, simpler Permutationsregeln und frei verfügbarer Tools, Einbruchsversuche mit guten Erfolgsaussichten zu starten. Eine einfache Permutationsregel wäre, die aktuelle Jahreszahl an das Kennwort anzufügen – und mal Hand aufs Herz: ist Ihnen nicht auch schon mal ein Kennwort wie Sommer2016 über den Weg gelaufen?

1.1      Technische Implementierung der Passwörter in SAP

Für die Authentifizierung von Benutzern am SAP System gibt es mehrere Mechanismen – die gängigste Methode davon ist auch heute noch die klassische Kombination von Username und Passwort. Diese Methode macht es erforderlich, dass das Kennwort – bzw. dessen Hashwert – im SAP System gespeichert wird, um es beim Login mit dem vom Benutzer eingegebenen Wert vergleichen zu können. Dies führt in Konsequenz dazu, dass die im letzten Abschnitt beschriebenen Angriffe somit auch für die SAP-Welt relevant sind!

Eine gute Nachricht vorweg: alle SAP Hashverfahren verwenden Salts, sind also gegenüber Angriffen mit Rainbow Tables geschützt. Leider gibt es dennoch gravierende Sicherheitslücken, die Sie jedoch mit etwas Know-how schließen können.

Mit der Zeit wurden verschiedene Algorithmen zur Hashberechnung verwendet, die SAP als Code-Versionen bezeichnet. Ihre Weiterentwicklung wurde maßgeblich von Sicherheitsanforderungen getrieben, Abwärtskompatibilität wurde jedoch bei jeder Änderung ermöglicht, so dass parallel mehrere Hashverfahren von System berechnet werden und zur Authentifizierung herangezogen werden können. Dies ist z.B. bei Upgrades ein wichtiger Aspekt, damit nicht alle Kennworte auf einmal neu gesetzt und so nach dem neuen Hashverfahren berechnet werden müssen. Es birgt allerdings die Gefahr, dass die alten und unsicheren Hashwerte im System weiter existieren, extrahiert und geknackt werden können. Selbst wenn die Rückwärtskompatibilität nach einiger Zeit ausgeschaltet wird, verbleiben immer noch alte Passwort-Hashwerte in der Datenbank, die ggf. einen Rückschluss darauf zulassen, wie die Benutzer ihre Kennworte wählen.

Dies ist ein Teil eines Kapitels über Passwörter, die mein Kollege Daniel Berlin für das Buch SAP Systeme schützen geschrieben hat. Wie es weitergeht, und wie die Passwörter nun wirklich gehackt werden können, wird im Buch beschrieben und zu einem späteren Zeitpunkt auch hier im Blog in weiteren Auszügen veröffentlicht.

Das komplette Kapitel ist im  Buch: SAP Systeme schützen