Wie ich bei meinem eigenen User eingebrochen bin

Ich hatte vor einiger Zeit die Situation gehabt, schnell Zugriff zu einem in RFC-Verbindungen genutzten User wiedererlangen zu müssen.

Das einzige Problem: Mir war das Passwort nicht (mehr) bekannt. Der Systembenutzer wurde vor 5 Jahren erstellt und irgendwo lag das Kennwort auch rum, nur ausgerechnet an diesem Tag war niemand zu erreichen, der das Kennwort kannte oder irgendwo abgespeichert hatte. Und leider war es wie so häufig dringend.

Der erste Lösungsansatz wäre nun gewesen, das Kennwort einfach zurückzusetzen. Dieser Ansatz entfiel, da der Systemuser in unzähligen RFC-Verbindungen von unterschiedlichen Systemen aktiv für die Verbuchung von Dingen genutzt wurde. Ebenfalls war der Benutzer in den unzähligen anderen SAP-Systemen für Rückverbindungen hinterlegt. Das wäre also nicht nur eine zeitliche Herausforderung gewesen, sondern wir hätten auch Prozesse zwangsweise abschalten müssen.

In diesem Fall pragmatischer, minimalinvasiver Lösungsansatz: Wir schauen mal, wie man bei einem Systemuser einbrechen kann. Alle Beteiligten waren damit auch einverstanden. Es stellte sich heraus, dass die Tabelle USR02 auf einigen älteren Systemen bzw. bei Systemen, die noch nicht nach dem Security-by-default-Ansatz der SAP installiert wurden, einige Überraschungen bereithalten kann.

Es gibt unterschiedliche Möglichkeiten, wie die Kennwörter auf einem SAP-System gespeichert werden können. Immerhin bedienen wir mit SAP eine Software mit einer Historie von über einem halben Jahrhundert.

Kommen wir zu den Basics

Kennwörter werden allgemeinhin nicht im Klartext irgendwo gespeichert, sondern verschlüsselt als Hashwert. Würden Kennwörter im Klartext gespeichert, könnte jeder mit entsprechenden Leserechten sie direkt in Masse auslesen. Eine Hashfunktion hingegen ist ein mathematisches Verfahren, das beliebig lange Eingaben in einen festen, scheinbar zufälligen Hash umwandelt.

So wird aus „WTRKNT“ durch das Hashverfahren SHA-256 Folgendes:

37ca0b98f4a37e64f2ab4c466cde2d21920cf7c254c4cf35da66f60ed2276923

Das Elegante hierbei ist, dass die Berechnung eines Hashverfahrens in eine Richtung recht simpel, einfach und günstig ist. Hierbei wird gerne auch von einer Einwegfunktion gesprochen, da das Kennwort praktisch nicht zurückgerechnet werden kann.

Ein Hashverfahren nimmt ebenfalls für sich in Anspruch, deterministisch zu sein. Bedeutet: Gleiches Kennwort führt zum selben Hash. Auch ein guter Grund, evtl. seine persönliche Passwortstrategie zu überdenken… Wenn ich 50-mal dasselbe supersichere Kennwort verwende und nur an einer Stelle kommt dies „abhanden“, habe ich ggf. an bis zu 50 unterschiedlichen Stellen gleichzeitig ein Problem. Moderne Hashverfahren kennen das Problem und verwenden deshalb salted Hashverfahren. Hierbei wird zusätzlich immer noch ein zufälliger Wert ergänzt, der jedoch eindeutig in Bezug zum User, System oder z. B. WLAN-SSID ist. Somit ist praktisch 2+2 nicht mehr 4, sondern 5, weil +1 im Sinn. Sehr vereinfacht ausgedrückt.

Mit salted Hashverfahren wird ein weiteres Problem gelöst. Die Berechnung eines Hashes in die eine Richtung ist einfach. Niemand kann mich daran hindern, eine große Anzahl von zufälligen Werten einfach mal durchzurechnen und mir die Hashwerte in eine durchsuchbare Datenbanktabelle abzulegen. In die Richtung funktionieren auch Angriffe mit sogenannten Rainbowtables. Praktischerweise gibt es auch Verfahren, die Kollisionen ermöglichen. Unterschiedliche Werte führen zu ein und demselben Hashwert. Nicht nur 2+2 ist 4, sondern auch 1+3 ergibt 4. Sehr vereinfacht ausgedrückt.

Eine weitere Eigenschaft ist die Empfindlichkeit: Ändere ich die Eingabe minimal, bekomme ich einen völlig anderen Hash. So wird aus „WTRKNt“ durch das Hashverfahren SHA-256 Folgendes:

27e59939b3abab4d6ab57823f121436da011ae05d59ff388c9466e2f1c13b4d2

Die drei Eigenschaften sind erstmal Annahmen beim Design eines Hashverfahrens und jeweils Stand der Technik. RC4 lässt grüßen. Auch wenn RC4 ein Stromchiffre-Algorithmus und kein Hashverfahren ist, steht er wie DES als Beispiel für ehemals verbreitete, heute unsichere Kryptografie.

Stand der Technik ist das passende Stichwort, wenn wir uns die in einem SAP-System verwendeten Hashverfahren einmal näher anschauen. In der Tabelle USR02 (und ergänzenden Tabellen) finden sich je nach Codeversion unterschiedliche Hash-Felder:

USR02-Feld	Verfahren	Eigenschaften
BCODE	MD5-basiert (CODVN A/B/D/E)	max. 8 Zeichen, nur Großbuchstaben, ohne zufälligen Salt – sehr schwach
PASSCODE	SHA-1-basiert (CODVN F)	bis 40 Zeichen, case-sensitive, ohne zufälligen Salt
PWDSALTEDHASH	iterierter, gesalzener SHA-1 / iSSHA-1 (CODVN H)	zufälliger Salt + viele Iterationen – Stand der Technik

Das alte BCODE-Verfahren entspricht längst nicht mehr dem Stand der Technik: Es ist auf die ersten acht Zeichen begrenzt, ignoriert die Groß-/Kleinschreibung und nutzt keinen zufälligen Salt. Mit heutiger Hardware ist so ein Hash in Minuten zu knacken. Zum Vergleich: Schon der DES-Verschlüsselungsstandard gilt seit 1998/1999 als gebrochen – und BCODE ist nicht besser dran.

CODVN steht hierbei für die in der USR02 verwendete Codeversion, also das Hashverfahren:

CODVN	Feld	Hashverfahren	Salt / Iterationen	Einsatz / Status
A	BCODE	frühes, proprietäres Verfahren	Benutzername als Salt / 1×	historisch, extrem unsicher
B	BCODE	MD5-basiert	Benutzername als Salt / 1×	unsicher, abgelöst
D / E	BCODE	MD5-basiert (UTF-8)	Benutzername als Salt / 1×	unsicher
F	PASSCODE	SHA-1-basiert	Benutzername als Salt / 1×	besser, aber ohne zufälligen Salt
G	BCODE + PASSCODE	MD5 + SHA-1 (B und F parallel)	wie B/F	Übergang / Abwärtskompatibilität
H	PWDSALTEDHASH	iterierter, gesalzener SHA-1 (iSSHA-1)	zufälliger Salt + Iterationen	aktuell, empfohlen
I	BCODE + PASSCODE + PWDSALTEDHASH	B + F + H parallel	Salt + Iterationen für H	viele Legacy-Hashes – problematisch

Hinweis: Bei CODVN H ist das konkrete Verfahren über den Parameter login/password_hash_algorithm einstellbar (standardmäßig iSSHA-1, optional mit stärkeren SHA-Varianten).

In der Regel wollen wir als Systemowner ein Verfahren verwenden, das nach aktuellem Stand der Technik als sicher angenommen wird:

• Nicht geknackt
• viele Stellen
• zufälliger Salt

Was habe ich vorgefunden? Zu meinem Glück ein I. Ein I klingt auf den ersten Blick besser als H, weil das I nach dem H kommt. Problem ist, hier werden aus Gründen der Abwärtskompatibilität mit der ZBV auch alle alten Hashverfahren parallel mitgeführt.

Hinweis: Falls Sie Unterstützung bei der Ablösung einer alten ZBV benötigen, sprechen Sie uns gerne an.

Damit liegt auch der alte, schwache BCODE-Hash in der USR02 – und der enthält für uns sehr brauchbare Informationen. Aus hoffentlich nachvollziehbaren Gründen werde ich nicht in die Details gehen, welche Werkzeuge ich eingesetzt habe. Aber es gibt einschlägig bekannte Tools, die in wenigen Minuten so lange herumprobieren, bis das zum BCODE-Hash passende Passwort gefunden ist.

Nur zur Vollständigkeit: Man sieht in so einem Fall bei allen Usern die Hashes in der USR02 und man könnte alle Werte herunterladen und in aller Ruhe herumprobieren. Ab diesem Zeitpunkt benötige ich das SAP-System erstmal nicht mehr.

In dem Fall wurde mir tatsächlich das damals verwendete Kennwort dargestellt. Zwar auf die ersten acht Zeichen und ohne Groß-/Kleinschreibung beschränkt, jedoch war das für mich ausreichend. Der Tag war erstmal gerettet. Wir haben uns anschließend intensiv mit dem Thema Passwortsicherheit in SAP-Systemen auseinandergesetzt und das offensichtliche Problem war dann schnell keins mehr.

Dieses Beispiel zeigt auch, dass IT-Security ein sehr breites Feld mit ungeahnten Möglichkeiten ist. Hier hatte keiner im Vorfeld vorsätzlich oder bösartig gehandelt. Es gab einfach einen Umstand, der ausgenutzt werden konnte und der eher wenigen bekannt war.

IT-Security kann man dabei gut mit dem Betrieb eines kommunalen Wassernetzes vergleichen. Irgendwo verliert man Wasser, man sucht die Stelle, bei der es tropft, wenn man Glück hat, findet man die richtige Stelle, eventuell gibt es weitere Stellen, weil alte Rohre vorhanden sind. Irgendwann trifft der Baggerfahrer, der auch keine bösartigen Absichten hat, eine Leitung und am Ende ist alles eine Frage von Prioritäten und Budget.

Was hätte das alles verhindert?

• Verwendung von CODVN H → Entspricht dem Stand der Technik; keine Abwärtskompatibilität
• Höhere Anforderung an Minimallänge eines Kennwortes → bei z. B. 12 Zeichen steigt die Wahrscheinlichkeit, dass man mit acht nun bekannten Zeichen nicht so schnell weiterkommt
• Leseberechtigung auf sensible Tabellen wie die USR02 maximal einschränken
• Passwortdatenbanken verwenden / aktuell halten → Problem wäre dann aber nicht so schnell erkannt worden

Weitere Take-Aways

• Keine Kennwörter mehrfach verwenden
• Kennwörter regelmäßig ändern
• SSO-Einsatz evaluieren

Zur Vollständigkeit: Es gibt neben der USR02 noch weitere Tabellen, zum Beispiel mit historischen Hashes. Ein SAP-System prüft schließlich auch die zuletzt verwendeten Kennwörter.

Wir können hierbei unterstützen. Wir führen Berechtigungsredesigns durch, helfen bei der Implementierung von moderneren Anmeldeverfahren wie SSO oder dem Identity Authentication Service (Cloud Identity Services).