Knacken von Passwort-Hashes, Klonen von Benutzern und Identitätsdiebstahl: Drei Risiken, die jeder SAP-Kunde kennen sollte

Der einfachste (und zugleich äußerst lukrative) Weg für Angreifer, sich Zugang zu einem System zu verschaffen, ist die Anmeldung mit gültigen Benutzerdaten. Laut einem aktuellen Bericht sind Sicherheitsverletzungen, die durch gestohlene oder kompromittierte Zugangsdaten verursacht werden, nicht nur für fast 20 % aller^{Sicherheitsverletzungen} verantwortlich1, sondern auch am schwierigsten zu erkennen und einzudämmen. Es kann mehr als 200 Tage dauern, bis solche Sicherheitsverletzungen erkannt werden, und mehr als 80 Tage, bis^{sie eingedämmt sind2}. Phishing-Angriffe sind die zweithäufigste Ursache für Sicherheitsverletzungen und zugleich die kostspieligste.

Es sind verschiedene Arten von Angriffsmethoden bekannt, mit denen Benutzerdaten erlangt werden sollen. Einige davon, wie Keylogger und Credential Stuffing, nutzen keine SAP-spezifischen Sicherheitslücken aus. Phishing-Angriffe werden meist durch E-Mails ausgelöst, die Links enthalten, über die Benutzer auf bösartige Server weitergeleitet werden.

Es gab jedoch bereits in der Vergangenheit Fälle, in denen Angreifer Phishing-Angriffe genutzt haben könnten, um SAP-Sicherheitslücken auszunutzen. Die jüngste davon wurde mit dem SAP-Sicherheitshinweis Nr. 3239152am Patch Day von SAP im Oktober 2022 behoben. Die Schwachstelle ist mit einem CVSS-Score von 9,6 bewertet und ermöglicht es Angreifern, einen Benutzer auf die ursprüngliche SAP-Commerce-Anmeldeseite umzuleiten. Dies geschieht durch die Verwendung einer manipulierten URL, die die Weiterleitungen zu einem bösartigen Server in die vom ursprünglichen Anmeldeformular bereitgestellten Links einfügt. 

Es gibt jedoch auch andere Methoden, um an Benutzerdaten zu gelangen, die spezifische Schwachstellen der SAP-NetWeaver-Architektur ausnutzen und speziell auf Hash-Werte zugeschnitten sind. 

Passwort-Hash-Werte in SAP

Die Passwörter aller SAP-Benutzer werden verschlüsselt als Hash-Werte in transparenten Tabellen in der Datenbank gespeichert. Diese Tabellen sind: 

• USR02: Enthält den aktuellen Benutzerstammsatz einschließlich der Hash-Werte des aktiven Passworts
• USH02: Enthält die Änderungsbelege zu den Benutzerstammsätzen einschließlich der Hash-Werte früherer SAP-Passwörter
• USRPWDHISTORY: Enthält den Passwortverlauf jedes Benutzers
• USH02_ARC_TMP: Wird vorübergehend bei der Archivierung von Benutzeränderungsbelegen verwendet

Ab SAP NetWeaver 7.02 werden die Passwort-Hash-Werte mit einem standardisierten Hash-Verfahren berechnet. Dieses Verfahren verwendet zusätzlich zum Passwort einen zufällig generierten Wert („Salt“), um den Passwort-Hash-Wert zu berechnen. Die Berechnung des Hash-Werts kann auch mehrmals hintereinander durchgeführt werden, d. h., sie kann iteriert werden. Eine Liste der unterstützten Hash-Algorithmen sowie die aktuellen Einschränkungen hinsichtlich der Salt-Größe und der maximalen Anzahl von Iterationen finden Sie im SAP-Hinweis Nr. 991968.  

Passwort-Hash-Werte knacken

Ein gesalzener Hash-Wert kann nicht entschlüsselt werden. Er kann jedoch geknackt werden. Mit Tools wie „hashcat“ oder „John the Ripper“ lässt sich ein Passwort ermitteln. Diese Tools führen eine Brute-Force-Attacke durch, indem sie den von SAP verwendeten Hash-Algorithmus auf ein Wörterbuch mit Hunderttausenden häufig verwendeter Passwörter anwenden. Stimmt der resultierende Hash-Wert mit dem in der SAP-Tabelle gespeicherten überein, ist das Passwort geknackt.

Die Tools nutzen die Tatsache aus, dass der SAP-Hash-Algorithmus und die Anzahl der Iterationen dem endgültigen Hash-Wert vorangestellt werden. Das Gleiche gilt für das Salt, das nach der Dekodierung der Base64-kodierten Hash-Zeichenkette leicht aus dem Ende der Hash-Werte extrahiert werden kann. Die Verwendung eines zufälligen Salts schützt also nicht vor dem Knacken von Passwörtern, verhindert jedoch den Massenabgleich des Passwortwörterbuchs mit allen Benutzerpasswörtern auf einmal, da für jedes Passwort ein anderes Salt verwendet wird. Dies verlangsamt den Angriff erheblich.

Um die Kommunikation mit älteren SAP-Systemen oder Middleware-Komponenten nicht zu unterbrechen, speichern SAP-Systeme auf SAP NetWeaver 7.02 oder höher standardmäßig jedes Passwort redundant. Das bedeutet, dass jedes Passwort zusätzlich als abwärtskompatibles Passwort (nach acht Zeichen gekürzt und in Großbuchstaben umgewandelt) mit zwei älteren (und schwachen) Hash-Algorithmen (MD5, SHA-1) gespeichert wird. Diese zusätzlichen, schwächeren Hash-Werte stellen ein Risiko dar, da sie für alle Benutzer gleichzeitig viel schneller geknackt werden können. Da sie die ersten acht Zeichen des vollständigen Passworts enthalten, können diese Informationen von Cracking-Tools genutzt werden, um die Anzahl der Testkandidaten im Wörterbuch erheblich zu reduzieren und die Zeit zum Knacken eines Passworts zu verkürzen. Eine Anmeldung am lokalen System mit dem abwärtskompatiblen, achtstelligen Passwort ist in der Regel nicht möglich (es sei denn, der SAP-Profilparameter login/password_downwards_compatibility ist auf 3 gesetzt, was nicht empfohlen wird). 

Schutzmaßnahmen

1. Erzeuge keine schwachen Hash-Werte, wenn dies nicht erforderlich ist

Die Erzeugung redundanter Passwörter lässt sich vermeiden, indem man den SAP-Profilparameter „login/password_downwards_compatibility“ auf 0 setzt.

2. Vorhandene schwache Hash-Werte entfernen

SAP stellt das Bereinigungsprogramm CLEANUP_PASSWORD_HASH_VALUES zur Verfügung, mit dem nach der Parameteränderung alle überflüssigen schwachen Hash-Werte entfernt werden können. Einzelheiten zu diesem Report finden Sie in unserem Blogbeitrag „Wie überprüfen Sie alte Hashes in Ihrem ABAP-System?“

3. Beschränken Sie den Zugriff auf die betroffenen Tabellen

Es reicht nicht aus, die Tabelle USR02 zu schützen. Auch die Passwortverlaufstabelle USRPWDHISTORY, die Änderungsbelegtabelle USH02 und die Archivtabelle USH02_ARC_TMP sollten geschützt werden; andernfalls könnte ein Angreifer anhand früherer Passwörter Rückschlüsse auf das aktuelle Passwort ziehen.

Zu den Zugriffsbeschränkungen gehören:

• Schutz vor direktem Datenbankzugriff von außen (über SQL)
  Dies sollte generell gesichert werden, z. B. durch den Einsatz von Firewalls. Andernfalls kann das SAP-Berechtigungskonzept, das den Datenzugriff regelt, vollständig umgangen werden
• Schutz vor Zugriffen über eigene ABAP-Programme
  Die Qualitätssicherungsinstanzen sollten automatisch oder manuell überprüfen, dass im kundeneigenen Code auf keine dieser Tabellen zugegriffen wird
• Schutz vor Zugriffen mit Hilfe bestehender generischer Werkzeuge (SE16/SM30/SM31)
  Berechtigungen für dieBerechtigungsobjekte S_TABU_DIS und/oder S_TABU_NAM sollten äußerst restriktiv vergeben werden
• Erteilen Sie in der Produktions
  keine Debugging-Berechtigungen. Dies sollte vermieden werden, insbesondere die Vergabe von Berechtigungen zum Ändern von Werten in der Produktions .            
• Schutz vor der Exportierung von Tabelleninhalten bei der Verwendung von Transporten
  Öffnen Sie das Produktivsystem nicht für die Freigabe von Transporten, da die Tabellendaten sonst sehr leicht aus dem System extrahiert werden können 

Die ersten drei Maßnahmen gelten auch für alle Views, die die vier Passwort-Hash-Tabellen nutzen. Eine detaillierte Liste mit weiteren Informationen finden Sie im SAP-Hinweis Nr . 1237762. 

4. Starke Passwörter vorschreiben

Sichere Passwörter sind der Feind von Wörterbuchangriffen. Die Zeit, die zum Knacken eines Passworts benötigt wird, hängt stark von dessen Länge und Komplexität ab.

Die bewährten Methoden zur Erstellung sicherer (gegen Wörterbuchangriffe resistenter) Passwörter lauten:

• Ein Passwort sollte aus mindestens 16 Zeichen bestehen
• Ein Passwort sollte aus einer Kombination aus Buchstaben, Zahlen und Sonderzeichen bestehen.
• Ein Passwort sollte keine persönlichen Daten des Benutzers wie seine Adresse oder Telefonnummer enthalten. Es ist außerdem ratsam, keine Informationen zu verwenden, die in sozialen Medien zu finden sind, wie beispielsweise die Namen von Kindern oder Haustieren.
• Ein Passwort sollte keine aufeinanderfolgenden Buchstaben oder Zahlen enthalten.

SAP-Administratoren können durch eine entsprechende Konfiguration der SAP-Profilparameter die Verwendung sicherer Passwörter vorschreiben:

• Anmelden/Mindestlänge des Passworts
• login/min_password_lowercase
• Anmeldung/Mindestlänge des Passworts in Großbuchstaben
• Anmeldung/Mindestanzahl_Passwortzeichen
• Anmeldung/Mindestlänge für Passwort-Sonderzeichen

Besondere Aspekte bei Entwicklungssystemen

Das Sicherheitsniveau von Test- und Entwicklungssystemen unterscheidet sich von dem von Produktionssystemen. Daher bieten diese Systeme einen guten Ansatzpunkt für Insider-Angriffe. Auf Entwicklungssystemen ist es nahezu unmöglich, den Zugriff auf die vier kritischen Tabellen einzuschränken. Da Benutzer häufig dieselben Passwörter auf mehreren Systemen verwenden, könnten Passwörter, die auf einem Entwicklungssystem geknackt wurden, auch für das Produktionssystem verwendet werden. Es wird dringend empfohlen, in Produktionssystemen andere Passwörter zu verwenden als in Test- oder Entwicklungssystemen. 

Benutzer klonen

Sobald die Entwicklerberechtigungen erteilt sind, können die Benutzer alle Aufgaben ausführen, unabhängig von ihren derzeit zugewiesenen Berechtigungen. Das Erstellen und Freigeben von Transporten gehört zum Tagesgeschäft der Entwickler. Daher ist das Extrahieren der Daten aus den Tabellen mit den Passwort-Hash-Werten für sie ein Kinderspiel.

Leider ist der Export der Daten aus den vier kritischen Tabellen für das Knacken von Passwörtern noch nicht das Schlimmste, was passieren kann. Die generierten Passwort-Hash-Werte sind nicht systemabhängig. Das bedeutet, dass ein auf System 1 generierter Hash-Wert auch auf System 2 funktioniert. Ein Entwickler kann seinen eigenen USR02-Benutzereintrag aus dem Entwicklungssystem exportieren und einen Administrator dazu bringen, den entsprechenden Transportauftrag in die Produktionsumgebung zu importieren! Er kann sich dann mit den bekannten Anmeldedaten in der Produktionsumgebung anmelden. 

Der Transport des Benutzersatzes reicht nicht aus, da der geklonte Benutzer Berechtigungen im Produktivsystem benötigt. Es gibt mehrere Möglichkeiten, dem geklonten Benutzer Berechtigungen zuzuweisen. Die beiden einfachsten sind der Transport eines Referenzbenutzer-Mappings (Tabelle USREFUS) oder von Einträgen für den Berechtigungspuffer (Tabelle USRBF2) zusammen mit dem Satz USR02 . Fortgeschrittenere Angriffe könnten auch die Zuweisung von Rollen und Profilen umfassen.

Es ist nicht einmal nötig, einen Administrator dazu zu verleiten, die schädlichen Daten in die Produktionsumgebung zu importieren. Ein Angreifer kann sogar den (riskanten) Schritt überspringen, eine andere Person dazu zu bringen, einen zusätzlichen Transport für den Angriff zu importieren. Stattdessen kann er den manipulierten Datensatz in einem „normalen“ Transportauftrag verstecken, der ohnehin genehmigt wird, da er reguläre Daten enthält, die von der Fachabteilung angefordert und vom Änderungsmanagement genehmigt wurden. Unser Blogbeitrag„SAP Security: Change and Transport System“ beschreibt zwei Möglichkeiten, wie Tabelleneinträge in einem regulären Transportauftrag versteckt werden können.

Identitätsdiebstahl

Single Sign-On: Keine Passwörter, keine Probleme? 

Fast… Der Transport von USR02- Einträgen in die Produktivumgebung zum Klonen eines Benutzers ist in Single-Sign-On-Szenarien (SSO) nicht sinnvoll, da in der Tabelle in der Regel kein Passwort gespeichert ist. Dennoch stellen Transporte auch hier ein Risiko dar. Damit eine SSO-Lösung funktioniert, muss sie jeden SAP-Benutzer seiner externen ID zuordnen, die vom SSO-Tool bereitgestellt wird. Bei SAP NetWeaver SSO wird diese Zuordnung in der Tabelle USRACL gespeichert. Externe Lösungs-IDs werden in der Tabelle USREXTID zugeordnet. Beide Tabellen können ohne Einschränkungen transportiert werden. Die beiden Tabellen können manipuliert werden, was zur Identitätsübernahme eines anderen, berechtigteren Benutzers führen kann. 

Beispiel:In einem SAP-NW-SSO-Szenario ordnet ein Angreifer seine SNC-Identität dem Benutzer „SAP“ zu. Auf einem Entwicklungssystem lässt sich dies leicht bewerkstelligen, indem die Tabelle „USRACL“ über ein eigenes kurzes ABAP-Programm aktualisiert wird. Dazu sind nicht unbedingt die erforderlichen Berechtigungen zur Pflege dieser Tabelle erforderlich:

Nachdem diese Änderung in die Produktionsumgebung übernommen wurde, kann der Angreifer wählen, welchem Benutzer seine SNC-Identität zugewiesen werden soll. Somit kann diese Methode dazu genutzt werden, sich in einem Produktionssystem als beliebige Benutzer auszugeben.

Das Knacken von Passwort-Hashes, das Klonen von Benutzern und die Identitätsfälschung sind realistische Angriffsszenarien in SAP-Systemen. Selbst SSO-Lösungen sind nicht zu 100 % sicher. Der Schutz der Tabellen mit Passwort-Hash-Werten, die Durchsetzung sicherer Passwörter und die Überwachung von Transportobjektlisten sind wichtige Maßnahmen zur Minimierung der damit verbundenen Risiken. 

Die Platform bietet verschiedene Prüfungen, um die Integrität eines SAP-Benutzers sicherzustellen. Diese Prüfungen umfassen Schutzmaßnahmen auf Systemebene, auf Quellcodeebene und auf Transportebene. Die durchgeführten Prüfungen sind:

• Der SAP-Profilparameter „login/min_password_lng“ ist korrekt eingestellt
• Der SAP-Profilparameter „login/min_password_lowercase“ ist korrekt eingestellt
• Der SAP-Profilparameter „login/min_password_uppercase“ ist korrekt eingestellt
• Der SAP-Profilparameter „login/min_password_digits“ ist korrekt eingestellt
• Der SAP-Profilparameter „login/min_password_specials“ ist korrekt eingestellt
• Der Zugriff auf kritische Benutzertabellen erfolgt im Kundencode
• Ein Transportauftrag enthält keine Benutzerdatensätze 
• Ein Transportauftrag enthält keine Daten aus dem Autorisierungspuffer 
• Ein Transportauftrag enthält keine Referenzbenutzerdaten 
• Ein Transportauftrag enthält keine SAP-NW-SSO-Zuordnungsdaten 
• Ein Transportauftrag enthält keine externen SSO-Zuordnungsdaten 
• Ein Transportauftrag enthält keine Daten zur Zuordnung von Rollen zu Benutzern 
• Ein Transportauftrag enthält keine Daten zur Zuordnung von Profilen zu Benutzern 

Erfahren Sie mehr darüber, wie die Platform durch Schwachstellenmanagement, Erkennung und Abwehr von Bedrohungen sowie Tests zur Anwendungssicherheit einen umfassenden Ansatz für die SAP-Sicherheit Platform .

^1,2  Ponemon/IBM-Bericht zu den Kosten von Datenschutzverletzungen 2022