Die drei häufigsten Sicherheits-Schwachstellen in SAP IDM
Das SAP Identity Management hilft Unternehmen Benutzer-Accounts und deren Berechtigungen zentral zu verwalten. Da das System Passwörter und kritische Zugriffsrechte in die angeschlossenen Systeme verteilt, sollte es besonders gut geschützt werden. Das wird in der Realität leider oft vernachlässigt. Die komplexe, heterogene Architektur des SAP IDM bringt viele Risiken mit sich, die beim Aufbau des Systems oft nicht beachtet werden. So kann die Fehlkonfiguration zu unberechtigten Zugriffen oder zu Unterbrechungen im Systembetrieb führen.
In diesem Blog werden die drei häufigsten Konfigurationsfehler und die daraus entstehenden Angriffsvektoren sowie die Risiken in Bezug auf Vertraulichkeit, Integrität und Verfügbarkeit aufgelistet. Ein Angriffsvektor beschreibt den Weg oder das Vorgehen eines Angreifers für den Zugriff auf Server oder Systeme, um dort Schadsoftware zu installieren oder andere Störungen zu verursachen.
Table of Contents
Systemarchitektur
Das SAP IDM besteht aus mehreren Komponenten, die über verschiedene Protokolle miteinander kommunizieren. Das Big Picture einer möglichen SAP IDM-Architektur finden Sie hier:
Risiko 1: Unsichere Kommunikation zwischen den SAP IDM-Komponenten und Umsystemen
Zu einem der häufigsten Konfigurationsfehler gehört die fehlende Nutzung von TLS für die Schnittstellen, die auf Protokollen HTTP oder LDAP basieren, sowie SNC für den SAP Java Connector, der für die Verbindung zu SAP ERP-Systemen eingesetzt wird. Durch diese Fehlkonfiguration sind wichtige Sicherheitseigenschaften wie Vertraulichkeit, Datenintegrität oder Authentizität von Daten in Transit nicht gewährleistet. Dadurch erhält der Angreifer bereits eine große Auswahl an Schwachstellen, die ausgenutzt werden können.
Beispielsweise können vertrauliche Daten wie Passwörter von SAP IDM-Administratoren oder Kommunikationsbenutzern, die zwischen den SAP IDM-Komponenten und den Umsystemen ausgetauscht werden, gelesen werden. Dies bringt das Risiko unberechtigter Zugriffe mit sich, welche je nach Motivation des Angreifers unterschiedliche negative Auswirkungen in der IT-Infrastruktur haben können.
So kann ein böswilliger Akteur in einem aktiven Angriff die Anmeldeinformationen eines Kommunikationsbenutzers verwenden, um über einen Webservice oder einen Remote Function Call beliebige Benutzer mit kritischen Berechtigungen in den Backend-Systemen anzulegen, um dort Schaden zu verursachen.
Noch ein besseres Ziel für den Angreifer sind die SAP IDM-Administratoren, die meist über mächtige Berechtigungen in SAP IDM und den Backendsystemen verfügen. Somit können die Logondaten direkt für eine Anmeldung in Umsystemen verwendet werden oder es können beliebige Benutzer mit kritischen Berechtigungen über das User Interface angelegt werden sowie Jobs und Tasks im SAP IDM Developer Studio ausgeführt werden.
Angriff
Nachfolgend wird ein Vorgehen gezeigt, wie ein passiver Angreifer, welcher sich bereits im internen WLAN-Netzwerk befindet, die Anmeldeinformationen eines SAP IDM-Administratoren stehlen kann, wenn die Kommunikation zwischen den SAP IDM-Komponenten nicht ausreichend geschützt ist.
Um im SAP IDM Developer Studio arbeiten zu können, müssen sich die Administratoren mit User-ID und Passwort anmelden. Die Authentifizierungsanfrage wird über einen Webservice an den AS JAVA verschickt. Der Payload beinhaltet die Zugangsdaten des Administrators.
In der ersten Phase des Angriffs analysiert der Angreifer den Netzwerkverkehr, um die IP-Adressen des Opfers und des AS JAVA herauszufinden. Für die Netzwerkanalyse können die Sniffer wie tcpdump oder Wireshark verwendet werden. In diesem Beispiel setzen wir auf die zweite Software zur Analyse der TCP-Pakete.
Wenn der Zugang zum AS JAVA nicht über SSL/TLS erfolgt, ist die Anwendung standardmäßig über den Port 50000 erreichbar. Dies kann im Analysetool gefiltert werden, sodass man im Netzwerkverkehr nur die Verbindungen zu Anwendungen sieht, welche über den erwähnten Port erreichbar sind:
Wenn der Angreifer eine ausreichende Anzahl von Paketen aufgezeichnet hat, fängt er an, diese zu analysieren. Dies kann eine relativ lange und mühsame Aufgabe sein, wenn der Angreifer nicht genau weiß, über welchen Webservice die Authentifizierungsanfrage verschickt wird. Nachdem er aber erfolgreich das richtige Paket identifizieren konnte, kann er sowohl die Zugangsdaten des SAP IDM-Administrators als auch die notwendigen Verbindungsdaten für das SAP IDM Developer Studio in Klartext lesen:
Diese Informationen kann er nutzen, um sich im System anzumelden und dort schwerwiegende Schaden zu verursachen.
Risiko 2: Verwaiste Privilegien
Ein anderes Problem, welches häufig auftritt, sind verwaiste Privilegien. Das sind über eine Business Rolle geerbte Berechtigungen, welche bei der Entfernung einer Business Rolle dem Benutzer nicht vollständig entfernt werden konnten. Die Zuordnung ist im UI auf dem Benutzer nicht mehr sichtbar, besteht allerdings noch immer in der Datenbank und wird dem Benutzer im Zielsystem nicht entfernt. Diese Privilegien sind beispielsweise im View idmv_link_ext mit dem Flag MCORPHAN gekennzeichnet und können mithilfe einer Stored Procedure gelöscht werden. Diese Prozedur sollte in einem Job für die fehlerhaften Zuordnungen aufgerufen werden. Wenn die Zuweisungen bestehen bleiben, kann dies zu SoD-Konflikten führen oder dazu, dass Zuordnungen von kritischen Berechtigungen im Zielsystem bestehen bleiben.
Risiko 3: Fehlkonfiguration der Dispatcher
Zu dem letzten in diesem Blog beschriebenen Fehler gehört eine fehlerhafte Definition der Dispatcher auf den Jobs. Wie in der SAP Note 2437631 beschrieben, sollte jeder Job nur einen Dispatcher zugeordnet haben, weil ansonsten Deadlocks entstehen können. Dies sind Events, in welchen zwei unterschiedliche Prozesse, die auf gleiche Ressource zugreifen wollen, sich gegenseitig sperren. Das kann dazu führen, dass der Job gar nicht ausgeführt wird.
Fazit
In diesem Blog wurden drei mögliche Probleme beschrieben, welche aufgrund einer Fehlkonfiguration in SAP IDM auftreten können. Da das System vielschichtig ist und für die Kundenbedürfnisse entwickelt wird, kann die Anzahl von Sicherheitslücken stark variieren.
Falls Sie Ihr System von einem unabhängigen Dienstleister überprüfen lassen möchten, wenden Sie sich einfach an unsere Expertinnen und Experten des IDM-Teams bei Xiting unter [email protected]. Sie prüfen Ihr System und helfen Ihnen dabei, Ihre Sicherheitsprobleme zu beseitigen. Als Ergebnis unseres Audit Services erhalten Sie einen vollständigen Report mit Risikoanalyse sowie eine Handlungsempfehlung zur Beseitigung von möglichen Risiken.
- Die drei häufigsten Sicherheits-Schwachstellen in SAP IDM - 27. August 2021
- SCIM 2.0: Standardisierte Benutzerverwaltung in der Cloud - 18. September 2020
