Sicherheit bei SAP-Remote-Funktionsaufrufen: Die entscheidende Rolle der S_ICF-Berechtigung

Sicherung von RFC auf dem Client: Autorisierungsobjekt S_ICF

Remote Function Call (RFC) ist ein proprietäres Framework und Netzwerkprotokoll, das als zentrale Säule für den Datenaustausch in SAP-Landschaften dient. Für die auf dem RFC-Framework basierende Netzwerkkommunikation müssen Verbindungsinformationen auf der Client-Seite konfiguriert und gespeichert werden. Der SAP NetWeaver Application Server ABAP und Platform RFC-Destinationen, um sowohl Serverinformationen als auch Anmeldedaten für Remote-Systeme zentral zu verwalten. 

Da SAP-Software in der Regel auf eine Vielzahl von Remoting-Mechanismen angewiesen ist, kann man davon ausgehen, dass in der Phase nach der Kompromittierung bei Cyberangriffen großes Interesse an unsicher konfigurierten RFC-Zielen besteht. Angreifer können vorhandene Ziele nutzen, um sich in der Systemlandschaft zu bewegen und ihren Zugriff auf andere Hosts auszuweiten, wobei sie gespeicherte Benutzeranmeldedaten und Vertrauensbeziehungen ausnutzen, wenn ein Benutzerkontextwechsel stattfindet. Techniken, die genutzt werden, um RFC-Ziele für die laterale Bewegung auszunutzen, werden zusammenfassend als „RFC-Hopping“ [1] bezeichnet und sind bereits seit geraumer Zeit bekannt. In diesem Artikel wird eine der weniger bekannten, aber wirksamen Sicherheitsvorkehrungen zur Verringerung des Risikos von RFC-Hopping behandelt – das Autorisierungsobjekt S_ICF.

Was ist das?

Als Teil des Berechtigungskonzepts von ABAP-basierten SAP-Systemen ist S_ICF ein funktionsübergreifendes Berechtigungsobjekt [2], mit dem sich der Zugriff auf Web-Services des Internet Communication Framework (ICF) [3], systemweite Proxys [4] und RFC-Destinationen [5] control lässt. Bei der Verwendung für Letzteres ermöglicht es die Beschränkung des Zugriffs auf statische Ziele auf eine bestimmte Gruppe von Benutzerkonten. Somit handelt es sich um eine sicherheitskritische Einstellung auf dem RFC-Client, die verhindert, dass unerwünschte Anfragen initiiert werden, und es Angreifern effektiv erschwert, ihre Berechtigungen durch gespeicherte Anmeldedaten in RFC-Zielen zu erweitern. Durch die Zuordnung eines Ziels zu einer Autorisierungsgruppe entsprechend seiner Sicherheitsklassifizierung wird auf Kernel-Ebene eine zusätzliche Laufzeitprüfung des S_ICF-Objekts eingeführt. 

Diese Prüfung stellt sicher, dass nur Benutzer mit den erforderlichen Berechtigungen für die Berechtigungsgruppe die RFC-Destination auf dem RFC-Client nutzen können. Da für neu angelegte RFC-Destinationen keine automatische Zuordnung zu einer Berechtigungsgruppe erfolgt, handelt es sich bei der technischen S_ICF-Prüfung um eine nicht standardmäßige Sicherheitsmaßnahme, die für jede einzelne RFC-Destination manuell registriert werden muss. Das heißt, sie wird für eine bestimmte RFC-Destination erst dann durchgesetzt, wenn diese einer Berechtigungsgruppe zugeordnet wurde [1].

Wie funktioniert das?

Administratoren haben die Möglichkeit, einer Berechtigungsgruppe RFC-Ziele mit unterschiedlichen Verbindungstypen zuzuweisen, beispielsweise „3“ (ABAP-Verbindung), „T“ (TCP/IP-Verbindung), „H“ (HTTP-Verbindung zum ABAP-System), „G“ (HTTP-Verbindung zu einem externen Server) oder „L“ (logisches Ziel), indem sie die Transaktion SM59 aufrufen und das Ziel auswählen. 

Auf der Registerkarte „Anmeldung & Sicherheit“ können Sie im Feld „Autorisierung für Ziel“ einen Literalwert definieren, der den Namen der gewünschten Autorisierungsgruppe enthalten soll. Abbildung 1 zeigt ein klassisches Beispiel für eine RFC-Destination vom Typ „3“ mit gespeicherten Anmeldedaten.

Um unbefugten Zugriff und Missbrauch des Anmeldematerials zu verhindern, wurde es einer neuen Berechtigungsgruppe „CHECK“ zugeordnet. Nach dem Speichern wird das Ziel für die S_ICF-Prüfung registriert und kann nicht mehr für Funktionsaufrufe verwendet werden, die von lokalen Benutzern initiiert werden, die nicht über die Berechtigungen für diese Gruppe verfügen. So führt beispielsweise das Auslösen eines nicht autorisierten Funktionsaufrufs in der Transaktion SE37 dazu, dass die S_ICF-Laufzeitprüfung den Aufruf blockiert, wie in Abbildung 2 zu sehen ist. Gleiches gilt für andere Anwendungsfälle, in denen die Destination programmgesteuert im ABAP-Code verwendet wird, wie in Abbildung 3 für einen Webservice dargestellt.

Abbildung 1: Einem Berechtigungskreis in SM59 zugewiesene RFC-Destination.

Abbildung 2: Fehlgeschlagener Funktionsaufruf aufgrund einer S_ICF-Laufzeitprüfung für das Zielobjekt.

Um berechtigten Benutzern den Zugriff auf die Destination zu ermöglichen, muss das Berechtigungsobjekt S_ICF ihren Benutzerstammsätzen zugeordnet werden. Tabelle 1 zeigt den allgemeinen Aufbau dieses Berechtigungsobjekts einschließlich der Werte, die für die oben konfigurierte RFC-Destination benötigt werden. 

Tabelle 1: Das Autorisierungsobjekt S_ICF zum Schutz von RFC-Zielen (basierend auf [2, 5]).

While the predefined ICF_FIELD value ‘DEST’ is used to indicate the functional purpose of the object assignment (used for RFC destination protection), the ICF_VALUE field has to include the name of the authorization group as defined for the destination in transaction SM59 [5]. Note that the configured name could also be looked up in token x=<group name> of field RFCOPTIONS in database table RFCDES.

Während in SM59 eine einzelne RFC-Destination nur einer bestimmten Berechtigungsgruppe zugeordnet werden kann, lässt sich das Feld ICF_VALUE des Objekts S_ICF nutzen, um Benutzern Zugriff auf eine Vielzahl unterschiedlicher Berechtigungsgruppen zu gewähren, von denen jede eine Reihe von RFC-Destinationen abdeckt.

Abbildung 3: Fehlgeschlagener Funktionsaufruf aufgrund einer S_ICF-Laufzeitprüfung für das Ziel (Fortsetzung).

Warum ist das wichtig?

Bei RFC-Hopping-Angriffen durchlaufen Angreifer das Netzwerk, indem sie Anmeldedaten und Berechtigungen von Benutzern sammeln, die in RFC-Zielen gespeichert sind. Dies geschieht nach der anfänglichen Kompromittierung des schwächsten Glieds und kann Angreifern dabei helfen, hochwertige Ziele zu erreichen. Wenn für statische RFC-Ziele keine Autorisierungsgruppen angelegt werden, können alle Benutzer auf dem RFC-Client-System denselben Satz von RFC-Benutzern in den Zielen verwenden, um Funktionen auf den Remote-Systemen auszulösen, ohne dass zusätzliche Autorisierungsprüfungen auf dem Client durchgeführt werden [1]. Dies stellt ein Risiko für sensible RFC-Ziele dar, die Anmeldedaten für privilegierte Benutzer auf der Remote-Seite enthalten. Durch die Zuweisung einer Autorisierungsgruppe pro Ziel kann das Risiko durch eine zusätzliche Autorisierungsprüfung auf dem Client-System verringert werden.

Schlussfolgerung und Diskussion

Zusammenfassend lässt sich sagen, dass das Autorisierungsobjekt S_ICF bei der Verwendung für RFC-Ziele eine unterstützende Sicherheitsmaßnahme auf ABAP-Kernel-Ebene darstellt, um RFC-Hopping-Angriffe abzuwehren, bei denen Angreifer bestehende RFC-Verbindungen missbrauchen, um sich in SAP-Systemlandschaften seitlich zu bewegen. Die Wahrscheinlichkeit erfolgreicher Angriffe wird verringert, indem die Anzahl der Benutzer, die zur Laufzeit auf eine RFC-Destination zugreifen können, streng begrenzt wird. Auch wenn der anfängliche Aufwand für die Erstellung und Zuweisung geeigneter Berechtigungsgruppen für alle bereits vorhandenen Destinationen als hoch angesehen werden könnte, könnte die Priorisierung und Stärkung der Sicherheit jener Destinationen, die auf die geschäftskritischsten Systeme verweisen, ein guter Ausgangspunkt für Administratoren sein. 

Es sei darauf hingewiesen, dass dieser Artikel ausschließlich einen einzelnen Sicherheitsmechanismus auf der RFC-Client-Seite beleuchtet hat, der nicht mit anderen wichtigen Schutzmaßnahmen auf der RFC-Server-Seite verwechselt werden darf. Weitere Maßnahmen müssen berücksichtigt werden; einige davon finden sich in früheren Blog-Artikeln [6, 7, 8, 9] sowie in der unten aufgeführten Herstellerdokumentation [1].

Literaturverzeichnis

[1] SAP SE. SAP-Hinweis 2008727 – Absicherung von Remote Function Calls (RFC), Kapitel 4 – Absicherung der RFC-Kommunikation auf dem Client. [Online] Verfügbar unter: https://me.sap.com/notes/2008727 (Zugriff am: 30.07.2024).

[2] SAP SE. SAP-Hilfeportal: Berechtigungsobjekt S_ICF. [Online] Verfügbar unter: https://help.sap.com/docs/ABAP_PLATFORM_NEW/c495ada972d045b2be2869f5573af8e7/489671360eec3987e10000000a421937.html (Zugriff am 30.07.2024).

[3] SAP SE. SAP-Hilfeportal: Konnektivität – Servicedaten definieren. [Online] Verfügbar unter: https://help.sap.com/docs/ABAP_PLATFORM_NEW/753088fc00704d0a80e7fbd6803c8adb/48d18402f6c96745e10000000a421937.html  (Zugriff: 30.07.2024).

[4] SAP SE. SAP-Hilfeportal: Internet Communication Framework – Konfiguration eines Proxyservers. [Online] Verfügbar unter: https://help.sap.com/docs/ABAP_PLATFORM_NEW/753088fc00704d0a80e7fbd6803c8adb/48d50d6b982b424be10000000a421937.html (Zugriff am 30.07.2024).

[5] SAP SE. SAP-Hilfeportal: ICF-Kommunikation – Zugriff auf RFC-Destinationen steuern. [Online] Verfügbar unter: https://help.sap.com/docs/ABAP_PLATFORM_NEW/c495ada972d045b2be2869f5573af8e7/489668140eec3987e10000000a421937.html (Zugriff am 30.07.2024).

[6] Onapsis SE, Thomas Fritsch. Die Risiken von SAP-RFC-Callbacks und wie man sie vermeidet. [Online] Verfügbar unter: https://onapsis.com/blog/risks-sap-rfc-callbacks-and-how-avoid-them/ (Zugriff am 30.07.2024).

[7] Onapsis SE, Thomas Fritsch. Schutz von SAP-Systemen mit dem Unified Connectivity Framework (UCON). Verfügbar unter: https://onapsis.com/blog/protect-sap-systems-unified-connectivity-framework-ucon/ (Zugriff am 30.07.2024).

[8] Onapsis SE, Thomas Fritsch. Wie man explizite AUTHORITY-CHECKS sicher in benutzerdefinierte RFC-fähige Funktionsbausteine integriert. [Online] Verfügbar unter: https://onapsis.com/blog/how-securely-introduce-explicit-authority-checks-custom-rfc-enabled-function-modules/ (Zugriff am 30.07.2024).

[9] Onapsis SE, Thomas Fritsch. SAP RFC Read Table: Zugriff auf beliebige Tabellen in SAP. [Online] Verfügbar unter: https://onapsis.com/blog/sap-rfc-read-table-accessing-arbitrary-tables/ (Zugriff am 30.07.2024).