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:

Zeitraum / SAP Release	Verfahren	Eigenschaften
bis ca. 2005	BCODE (7‑stellige Hashes)	7‑stellige Großbuchstaben-Passwörter, sehr schwach, DES‑basiert
ab SAP_BASIS 4.6C	PASSCODE (CODVN B)	MD5‑basiert, 40‑stelliger Hex‑Hash
SAP_BASIS 6.10 / 6.20	PWDSALTEDHASH (CODVN C/D)	SHA‑1 mit Salt, 160 Bit, deutlich sicherer
SAP_BASIS 7.00 (SP23+)	PWDSALTEDHASH + Downward Hashes	SHA‑1 + Salt, optional parallel MD5/BCODE für alte RFC/Logons

DES ist ein Verfahren, welches definitiv nicht dem Stand der Technik entspricht und seit 1998/1999 als geknackt gilt.

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

CODVN	Bezeichnung	Hashverfahren	Salt / Iterationen	Einsatz / Status
A	BCODE	7‑stelliger DES‑basierter Hash	Kein Salt / 1x	Historisch, extrem unsicher
B	PASSCODE	MD5‑basiert (40‑stelliger Hex‑Hash)	Kein Salt / 1x	Unsicher, abgelöst
C	PWDSALTEDHASH	SHA‑1	Mit Salt / 1x	Früher sicher, heute veraltet
D	PWDSALTEDHASH + BCODE	SHA‑1 + paralleler BCODE	Mit Salt / 1x	Für Abwärtskompatibilität
E	iSSHA‑1	Iteratives SHA‑1	Salt + Iterationen	Mittel, heute veraltet
F	iSSHA‑1 + BCODE	Iteratives SHA‑1 + paralleler BCODE	Salt + Iterationen	Für alte Systeme / CUA
G	iSSHA‑256	Iteratives SHA‑256	Salt + Iterationen (5k–15k)	Aktuell, sicher
H	iSSHA‑512	Iteratives SHA‑512	Salt + Iterationen (5k–15k)	Aktuell, empfohlen
I	Kombi (BCODE + MD5 + iSSHA‑1)	Mehrfachhash (A/B + F/H)	Salt + Iterationen für iSSHA	Problematisch, viele Legacy‑Hashes

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

• Nicht geknackt

• viele Stellen

• 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 angewendet.

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

Damit wird auch DES verwendet und das Feld BCODE in der USR02 enthält für uns sehr brauchbare Informationen. Aus hoffentlich nachvollziehbaren Gründen, werde ich nicht in die Details gehen, welche Tools ich eingesetzt habe. Aber es gibt einschlägig bekannte Tools, die in wenigen Minuten so lange rumprobieren, bis der richtige DES-Hash vor uns liegt.

Nur zur Vollständigkeit:

Man sieht in so einem Fall bei allen Usern die Hashes in der USR02 und man könnte alle Werte runterladen und in aller Ruhe rumprobieren. 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 7 Zeichen 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 7 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)

Bei Anmerkungen, Ergänzungen, Hinweise auf Fehler, gerne eine kurze Mail an blog@wtrknt.com

MfG DMa