Die Risiken von SAP-RFC-Callbacks und wie man sie vermeidet
In unserem jüngsten Blogbeitrag zum Thema „So schützen Sie Ihr SAP-System mit dem Unified Connectivity Framework (UCON)“ haben wir darüber gesprochen, wie sich das Risiko böswilliger Remote Function Calls (RFC) in ein SAP-Produktionssystem minimieren lässt, die von anderen, weniger gut geschützten SAP-Systemen oder von externen Clients ausgehen (Inbound Calls). Das UCON-Framework bietet leistungsstarke Funktionen, um sich vor solchen RFC-Aufrufen zu schützen und diesen Schutz aufrechtzuerhalten.
Diese Angriffe können von böswilligen Akteuren durchgeführt werden, allerdings müssen diese zunächst die Anmeldedaten eines berechtigten Benutzers im Produktionssystem beschaffen. Der Benutzer muss über die entsprechenden Berechtigungen verfügen, um den schädlichen Funktionsbaustein auszuführen (S_RFC-Berechtigung) und alle im Funktionsbaustein explizit implementierten Berechtigungsprüfungen erfolgreich zu bestehen.
Es sind jedoch keine Benutzeranmeldedaten zur Durchführung dieses Angriffs erforderlich, wenn ein RFC-Callback genutzt wird, um in das Produktionssystem zu gelangen.
Was ist ein RFC-Callback?
Wird auf einem Produktivsystem ein RFC-Aufruf initiiert, der eine Verbindung zu einem weniger gut geschützten SAP-System herstellt (ausgehender Aufruf), kann der aufgerufene Funktionsbaustein von einem Angreifer manipuliert werden. Der Angreifer kann das Zielsystem kompromittieren und es dazu bringen, einen RFC-Rückruf an das Produktivsystem zu starten. Der Angreifer kann die vordefinierte RFC-Destination „BACK“ nutzen, um den böswilligen Rückruf zu starten. Ein Rückruf wird dann auf dem Produktionssystem im Benutzerkontext des Produktionsbenutzers ausgeführt, der den ursprünglichen ausgehenden Aufruf gestartet hat, sodass keine Benutzeranmeldedaten erforderlich sind.
Beispiel: Ein Angreifer hat Zugriff auf ein unzureichend geschütztes System und manipuliert den Quellcode des SAP-Funktionsbausteins RFC_PING so, dass dieser den Funktionsbaustein BAPI_USER_CREATE mit dem Ziel „BACK“ aufruft. Er bittet den Systemadministrator des Produktivsystems um einen Verbindungstest von der Produktion zum kompromittierten System. Der Administrator startet die Transaktion SM59, um den Test einzuleiten.
Aufgrund des manipulierten RFC_PING-Moduls im Zielsystem wird auf dem Produktivsystem unbemerkt ein neuer Benutzer angelegt, und zwar im Benutzerkontext des SAP-Admin-Benutzers. Glücklicherweise erfordern RFC-Funktionsaufrufe über Callback die entsprechenden S_RFC-Berechtigungen für den Benutzer, der den ursprünglichen RFC-Aufruf auf dem Produktivsystem initiiert hat. Dies unterstreicht einen wichtigen Grund dafür, Berechtigungen für das Berechtigungsobjekt S_RFC nicht zu großzügig zu vergeben – auch nicht an SAP-Administratoren.
Systemschutz vor RFC-Callbacks
Ab SAP NetWeaver 740 (rückportiert auf SAP NW 731 mit Kernel 7.21 SP 321) hat SAP das Konzept der Callback-Zulassungslisten eingeführt. Dieses Konzept ist sehr detailliert und ermöglicht die Definition einer separaten Zulassungsliste für jede RFC-Destination über die Transaktion SM59. Eine Zulassungsliste umfasst Paare aus aufrufenden Funktionsbausteinen und zulässigen Callback-Funktionen.
Beispiel: Um den Funktionsbaustein RFC_READ_TABLE als Callback innerhalb des Funktionsbausteins ZTF_OUTBOUND zuzulassen, ist folgender Eintrag in der Zulassungsliste erforderlich:
Hinweis: Auf einigen Bildschirmen verwendet SAP den Begriff „Positivliste“, auf anderen „Zulassungsliste“.
Whitelists können aktiv oder inaktiv sein. Die Auswirkung des Aktivierungsstatus einer Whitelist hängt vom SAP-Profilparameter „rfc/callback_security_method“ ab. Mögliche Werte für diesen Parameter sind:
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Zulässiger Rückruf, der abgelehnt würde, falls die derzeit inaktive Zulassungsliste aktiviert würde:
|
 |
|
|
|
|
|
Der Parameter rfc/callback_security_method kann dynamisch über die Transaktion RZ11 geändert werden. Dies sollte jedoch nur für vorübergehende Tests in Betracht gezogen werden, und es wird dringend empfohlen, den Parameterwert im Standardprofil des SAP-Systems festzulegen. Der aktuelle Parameterwert ist auch in der Transaktion SM59 einsehbar (siehe Spalte „SM59-Kennzeichen“ in der Tabelle).
Erstellung von anfänglichen Zulassungslisten
Ähnlich wie bei der Aktivierung von UCON besteht die größte Herausforderung beim Callback-Schutzkonzept in der anfänglichen Befüllung der Zulassungslisten. Glücklicherweise bietet SAP auch hier technische Unterstützung an. Eine wichtige Voraussetzung ist die Aktivierung der Ereignisse im Sicherheitsprotokoll:
- DUI: RFC-Callback ausgeführt (Ziel &A, aufgerufen &B, Callback &C)
- DUJ: RFC-Callback abgelehnt (Ziel &A, aufgerufen &B, Callback &C)
- DUK: RFC-Callback im Simulationsmodus (Ziel &A, aufgerufenes Objekt &B, Callback &C)
In der Regel wird „rfc/callback_security_method“ für einige Monate auf den Wert 2 (Simulationsmodus) gesetzt. Das SAP Security Audit Log (SAL) protokolliert in dieser Phase alle zugelassenen und alle abgelehnten Callback-Versuche. Am Ende der Phase können mit der Transaktion SM59 automatisch Zulassungslisten auf Basis der protokollierten Callback-Informationen generiert werden. Nach Aufruf des Menüeintrags:
RFC -> RFC-Callback-Whitelist erstellen
oder über die entsprechende Schaltfläche,
Sie können den Zeitbereich einschränken, der im SAL analysiert wird. Die resultierende Liste enthält alle Paare aus aufgerufenen Funktionsbausteinen und Callback-Funktionsbausteinen, die während des Analysezeitraums verarbeitet wurden, sowie die Anzahl der Verarbeitungen für jede definierte RFC-Destination. Sie können alle Datensätze auswählen oder einige davon ausschließen, bevor Sie die Zulassungslisten generieren (und optional aktivieren). Anschließend können Sie den Parameter `rfc/callback_security_method` auf den Wert 3 setzen.
Hinweis: Im Rahmen der SAP-Initiative „Secure by default“ wurde der Standardwert für „rfc/callback_security_method“ ab SAP S/4HANA 1909 von 1 auf 3 geändert.
Schutz des Quellcodes vor RFC-Callbacks
Ein Callback-Schutz kann auch in dem Quellcodeobjekt realisiert werden, das synchrone Aufrufe von RFC-Funktionsbausteinen enthält. Durch den Aufruf des Funktionsbausteins RFC_CALLBACK_REJECTED vor dem ersten RFC-Funktionsaufruf wird die Möglichkeit der Verwendung von Callbacks auf dem Zielsystem deaktiviert:
FUNKTION „RFC_CALLBACK_REJECTED“ AUFRUFEN
EXPORT
REJECT_OPTION = ‘S’
SET_REJECT_STATE = ‘X’
AUSNAHMEN
INVALID_REJECT_OPTION = 1
INVALID_REJECT_STATE = 2
FUNCTION_NOT_SUPPORTED = 3
INTERNAL_ERROR = 4
OTHERS = 5.
Dieser Schutz ist der sicherste, da er stets aktiv ist, unabhängig vom Profilparameter `rfc/callback_security_method`. Somit ist der ausgehende Aufruf auch dann geschützt, wenn der Profilparameter versehentlich oder absichtlich auf einen unsicheren Wert gesetzt wurde. In den ersten Monaten nach der Einführung von Callback-Allowlists gab es auch einige SAP-Hinweise, in denen empfohlen wurde, rfc/callback_security_method nicht auf 3 zu setzen, da einige SAP-Standardfunktionen aufgrund des restriktiven Callback-Schutzes nicht mehr funktionierten.
Abhängigkeit zwischen UCON und dem Schutz vor RFC-Callbacks
Es besteht eine Abhängigkeit zwischen UCON und dem RFC-Callback-Schutz, die die durch das Allowlist-Konzept für Callbacks gebotene Granularität untergräbt. Wenn UCON aktiviert ist, reicht es nicht aus, das erforderliche Paar aus aufgerufenem Funktionsbaustein und Callback-Funktionsbaustein in die aktive Allowlist der betroffenen RFC-Destination aufzunehmen. Sie müssen das Callback-Funktionsmodul zusätzlich zur Standard-Kommunikationsassembly (CA) in UCON hinzufügen. Das bedeutet: Wenn Sie ein Funktionsmodul in einem sehr spezifischen, lokalen RFC-Callback-Szenario zwischen Ihrem Produktivsystem und einem anderen System nutzen möchten, müssen Sie es allgemein verfügbar machen! Eine separate UCON-CA, die ihre Mitglieder nur für Callback-Szenarien freigibt, wäre hier sehr hilfreich, siehe das folgende Beispiel.
Beispiel:
Damit das oben beschriebene RFC-Szenario funktioniert, muss auf System A für die verwendete Zieladresse ein Eintrag in der RFC-Callback-Zulassungsliste vorhanden sein, damit eine Verbindung zu System B hergestellt werden kann:
„Funktionsmodul A / Funktionsmodul B“
Wenn UCON auf System A aktiviert ist, der Funktionsbaustein B jedoch nicht in der Standard-CA enthalten ist, schlägt der Rückruf fehl:
Wenn der Funktionsbaustein B zur Standard-CA auf System A hinzugefügt wird, kann er grundsätzlich von außerhalb des Systems aufgerufen werden:
Fazit
Die Risiken von RFC-Callbacks lassen sich durch die Aktivierung des Whitelist-Konzepts für RFC-Ziele minimieren. Sowohl UCON als auch der Callback-Schutz sollten als zusätzliche Sicherheitsebenen über dem Autorisierungskonzept eingesetzt werden. Kunden, die die Platform nutzen, erhalten zudem zusätzlichen Schutz. Onapsis bietet verschiedene Prüfungen gegen RFC-Callbacks. Diese Prüfungen umfassen Schutzmaßnahmen auf Systemebene, auf Quellcodeebene und auf Transportebene. Die durchgeführten Prüfungen umfassen:
- Der SAP-Profilparameter „rfc/callback_security_method“ ist auf 3 gesetzt
- Der SAP-Profilparameter „auth/rfc_authority_check“ ist auf 6 gesetzt
- Ein RFC-fähiger Funktionsbaustein enthält eine explizite Berechtigungsprüfung
- Der Funktionsbaustein RFC_CALLBACK_REJECTED wird vor dem Start eines RFC-Aufrufs aufgerufen
- Ein Transportauftrag enthält keine Einträge in der Callback-Zulassungsliste
- Ein Transportauftrag enthält keine Informationen zum Aktivierungsstatus einer Callback-Zulassungsliste