Die ERP – Systeme von SAP zählen wohl zu den am meist genutzten ERP Systemen weltweit.
In den letzten Artikeln habe ich mich stark mit dem Thema Passwörter im Microsoft umfeld beschäftigt.
Aber was ist eigentlich mit SAP? Wie schwierig ist es in SAP-Systemen an die gehashten Passwörter zu gelangen? Und wie aufwändig ist es, diese Passwörter zu „knacken“?
Bei SAP werden die Passwörter wie in den meisten anderen Anwendungen und Betriebssystemen auch in einer Datenbank verschlüsselt abgespeichert. Sobald ein Anwender sich am System anmelden möchte, wird aus dem angegebenen Schlüssel der sogenannte Hash generiert und mit dem in der Datenbank gespeicherten Hash verglichen. Sofern keine weiteren Authentifizierungsmechanismen gefordert sind (z.B. im Rahmen einer Mehrfaktor-Authentifizierung) wird dem User dann im Rahmen seiner zugewiesenen Berechtigungsausprägung zugang zum System gewährt.
Im Laufe der Jahre hat die SAP die Hash-Verfahren für die Passwörter geändert. Die für SAP 4.7 angewendete Methode besteht aus einem einfachen MD5 – Hash, der immerhin noch durch den User-Namen „gesalzen“ wird. Vereinfacht gesagt: Sofern Herr Meier das gleiche Passwort benutzt wie Herr Müller, sehen die gehashten Passwörter trotzdem anders aus. Dies erfordert etwas mehr aufwand zum „knacken“, ist aber auf Grund des verwendeten Algorithmus immer noch relativ schnell – dazu später mehr. Weitere Eigenschaften von SAP B-Hashes sind jedoch fatal: Aus welchen Gründen auch immer werden die Passwörter vor dem Hashen an der 8. Stelle abgeschnitten und Kleinbuchstaben werden zu Großbuchstaben konvertiert. Das Passwort „ManuelsBlog12345“ würde somit vor dem Hashen zu „MANUELSB“ konvertiert. Die Auswirkungen auf den Passwortraum sind immens – es bleiben lediglich 2.800 Milliarden mögliche Passwörter übrig (ohne Sonderzeic
hen). Die gute Nachricht: Durch das „salzen“ der Passwörter mit dem Benutzernamen wird die „Knack-„Geschwindigkeit etwas reduziert. Wie so ein Hash aussieht, könnt ihr in dem Screenshot unten sehen.
Hier ist die Darstellung <Benutzername>$<HASH>. Wie man sieht, sind die „SAP B“ Hashwerte nur 16 stellen lang und bestehen aus Hexadezimalwerten.
Das System, dass in meinem letzten Beitrag noch 8 Millarden Hashes pro Sekunde berechnet hat, schafft mit SAP B – Hashes „nur“ noch 826 Millionen Hashes pro Sekunde. Damit benötigt dieses System rund eine Stunde, um jeden beliebigen Hash-Wert zu entschlüsseln.
Und wie sieht es in aktuellen (SAP-)Systemen aus?
SAP ist zum Glück nicht auf diesem Stand stehen geblieben. Die Passwort-Algorithmen wurden weiterentwickelt. Mittlerweile sind wie bei sehr sicheren bzw. aufwändig zu „knackenden“ Hash-Verfahren angekommen. Der „Passcode“ bzw. „SAP G“ Code benutzt eine SHA-1 Verschlüsselung und eine maximale Kennwortlänge von 48 Zeichen. Dies war schon ein deutlicher Fortschritt. Stand heute (2017) sind wir bei „CODEVN H“ angekommen, wobei es sich um einen iterierenden Hash-Algorithmus handelt, der auch über den Parameter login/password_hash_algorithm ein beliebiges „Salz“ mitgegeben werden kann. Dieses Verfahren ist wirklich sehr langsam zu „Brute-Forcen“. Aber dazu evtl. später mehr.
Soweit zur guten Nachricht. Die schlechte Nachricht: Aus meiner Erfahrung heraus ist in 90 % aller Kundeninstallationen der Passwort-Parameter „backward compatibility“ gesetzt. Dieser Parameter stellt sicher, dass auch ältere Systeme noch angebunden werden können. Hierfür ist es aber notwendig, auch den „alten“ Hash zu speichern. Dies bedeutet: Obwohl die Systeme schon Hash-Algorithmen nach Stand der Technik unterstützen, finden sich im System immer noch die entsprechenden Passwörter im CODEVN B die in wenigen Stunden knackbar sind, egal wie komplex das Passwort ist! Dies wäre in vielen Systemen überhaupt nicht notwendig, aber die Administratoren trauen sich nicht, die Abwärtskompatibilität auszuschalten…
Das ist ja alles schön und (gar nicht) gut! Aber für eine Risikobetrachtung muss man doch wissen, wie man an die Passwörter kommt!
Das ist natürlich völlig korrekt! 🙂 Die gehashten Passwörter werden bei SAP ebenfalls in einer Datenbank abgelegt und zwar (u.a.) in der Tabelle „usr02“. Nun sollte man davon ausgehen, dass nur die Datenbank-Administratoren zugriff auf diese wertvollen Daten haben, was im besten Falle auch nur ein kleiner Kreis ist – dem ist aber leider nicht so.
Viele Unternehmen möchten ihren Anwendern die Möglichkeit gestatten, aus dem System heraus auf Datenbanktabellen zuzugreifen. Mit Hilfe der Transaktion SE16 (und einigen anderen Transaktionen) ist es möglich, direkt auf diese Tabellen zu zugreifen. Nach meiner Erfahrung gibt es hunderte von SAP Installationen, in denen viele viele User zugriff auf diese kritischen Daten haben. Ein einfacher Aufruf von „SE16“ mit Eingabe von „usr02“ zaubert mir alle notwendigen Daten auf den Bildschirm, aus denen sich schnell die benötigten Informationen extrahieren lassen (siehe Bild unten).
Und wie kriege ich das System jetzt sicher hin?
Zunächst einmal muss der alte SAP B Code dringend aus dem System geworfen werden. Hierfür muss auf neueren Installationen die Abwärtskompatibilität über den entsprechenden Parameter unbedingt auf „0“ gesetzt werden. Sofern noch B-Codes in der USR02 gespeichert sind, muss diese bereinigt werden.
Als zweiten Schritt muss der Tabellenzugriff auf die Hashwert-Tabellen eingeschränkt werden. Wenn die Benutzung von SE16 unbedingt notwendig ist, muss dieser Zugriff eingeschränkt werden. Dies ist über ein entsprechendes Berechtigungsobjekt möglich. Normale User dürfen keinen Zugriff auf Systemtabellen haben.
Und schließlich sollte die zugrunde liegende Datenbank entsprechend abgesichert werden.
Weitere Infos / Linksammlung:
https://www.onapsis.com/blog/checking-sap-password-strength-part-i-abap