Remote Function Call (RFC) is a proprietary framework and network protocol used as a key pillar for data exchange in SAP landscapes. For network communications based upon the RFC framework, connection information needs to be configured and stored on the…
Remote Function Call (RFC) is a proprietary framework and network protocol used as a key pillar for data exchange in SAP landscapes. For network communications based upon the RFC framework, connection information needs to be configured and stored on the client side. SAP NetWeaver Application Server ABAP and ABAP Platform use RFC destinations to centrally manage both server information and logon material for remote systems.
Since SAP software is usually dependent on a diverse set of remoting mechanisms, it’s fair to assume that there’s a great interest in insecurely configured RFC destinations during the post-compromise stage of cyber attacks. Adversaries may use existing destinations to navigate in the system landscape and escalate their access to other hosts, exploiting stored user credentials and trust relations where a user context switch occurs. Techniques used to capitalize on RFC destinations for lateral movement are collectively referred to as “RFC hopping” [1] and have been known for a considerable time. This article will discuss one of the lesser known but effective security precautions to reduce the risk of RFC hopping – the S_ICF authorization object.
What is it?
Included in the authorization concept of ABAP-based SAP systems, S_ICF is a cross-functional authorization object [2] that can be used to control fine-granular access to web services of the Internet Communication Framework (ICF) [3], system-wide proxies [4], and RFC destinations [5]. When utilized for the latter, it gives the power to restrict access to static destinations to a specific set of user accounts. As such, it’s a security-critical setting on the RFC client that prevents unwanted requests to be initiated, effectively making it more difficult for adversaries to escalate their privileges through stored logon data in RFC destinations. By assigning a destination to an authorization group according to its security classification, an additional runtime check on the S_ICF object is introduced at kernel level.
This check ensures that only users with the required privileges for the authorization group can leverage the destination on the RFC client. Because there’s no automatic authorization group assignment for newly created destinations, the technical S_ICF check is a non-default security measure that must be manually registered on a per destination basis. That is, it’s not enforced for a particular RFC destination until the same has been assigned to an authorization group [1].
How Does it Work?
Administrators have the option to assign RFC destinations with different connection types, such as ‘3’ (ABAP Connection), ‘T’ (TCP/IP Connection), ‘H’ (HTTP Connection to ABAP System), ‘G’ (HTTP Connection to External Server), or ‘L’ (Logical Destination), to an authorization group by entering transaction SM59 and selecting the destination.
The ‘Logon & Security’ tab provides the means to define a literal in the ‘Authorization for Destination’ field, which is supposed to hold the name of the desired authorization group. Figure 1 shows a classic example of an RFC destination of type ‘3’ with stored credentials.
To prevent unauthorized access and misuse of the logon material, it has been assigned to a new authorization group ‘CHECK’. Once saved, the destination is registered for the S_ICF check and can no longer be used for function calls initiated by local users not possessing the authorizations for this group. For instance, triggering an unauthorized function call in transaction SE37 is leading to the S_ICF runtime check blocking the call, as can be seen in Figure 2. The same applies for other use cases where the destination is used programmatically in ABAP coding, as illustrated for a web service in Figure 3.
Figure 1: RFC Destination Assigned to an Authorization Group in SM59.
Figure 2: Failed Function Call Due to S_ICF Runtime Check for Targeted Destination.
In order to provide legitimate users with the access to the destination, the S_ICF authorization object has to be assigned to their user master records. Table 1 shows the general structure of this authorization object including the values needed for the RFC destination configured above.
Table 1: Authorization Object S_ICF Used For Protection of RFC Destinations (based on [2, 5]).
| Authorization Object S_ICF | ||
| Field | Description | Value |
| ICF_FIELD | Type of the object that is being protected | DEST |
| ICF_VALUE | Check value for target object. That is, the authorization group for a RFC destination. | CHECK |
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.
Whereas a single RFC destination can only be assigned to one specific authorization group in SM59, the ICF_VALUE field of the S_ICF object can be used to provide users with access to a multitude of different authorization groups each covering a set of RFC destinations.
Figure 3: Failed Function Call Due to S_ICF Runtime Check for Targeted Destination (cont.).
Why is it Important ?
During RFC hopping attacks, adversaries traverse the network by harvesting credentials and privileges of users stored in RFC destinations. This happens after the initial compromise of the weakest link and it may aid attackers in reaching high-value targets. If no authorization groups are created for static RFC destinations, all users on the RFC client system can use the same set of RFC users in the destinations to trigger functions on the remote systems without additional authorization checks being performed on the client [1]. This imposes a risk on sensitive RFC destinations holding credentials for privileged users on the remote side. By assigning an authorization group per destination, the risk can be reduced through an extra authorization check on the client system.
Conclusion and Discussion
In summary, the S_ICF authorization object when used for RFC destinations is a supportive security measure at ABAP kernel level to mitigate RFC hopping attacks in which adversaries abuse existing RFC connections to move laterally in SAP system landscapes. The likelihood of successful attacks is reduced by imposing a strict limit on the number of users capable of accessing an RFC destination at runtime. Although the initial efforts required to create and assign adequate authorization groups for all already existing destinations might be considered high, prioritizing and strengthening the security of those destinations pointing to the most business-critical systems could be a good starting point for administrators.
It should be noted that this article solely highlighted a single security mechanism at the RFC client side, which doesn’t have to be confused with other important protection measures at the RFC server side. Further actions have to be taken into account, some of which can be found in previous blog articles [6, 7, 8, 9] and in the vendor documentation below [1].
References
[1] SAP SE. SAP Note 2008727 – Securing Remote Function Calls (RFC), Chapter 4 – Securing RFC communication on the client. [Online] Available: https://me.sap.com/notes/2008727 (Accessed: 30.07.2024).
[2] SAP SE. SAP Help Portal: Authorization Object S_ICF. [Online] Available: https://help.sap.com/docs/ABAP_PLATFORM_NEW/c495ada972d045b2be2869f5573af8e7/489671360eec3987e10000000a421937.html (Accessed 30.07.2024).
[3] SAP SE. SAP Help Portal: Connectivity – Defining Service Data. [Online] Available: https://help.sap.com/docs/ABAP_PLATFORM_NEW/753088fc00704d0a80e7fbd6803c8adb/48d18402f6c96745e10000000a421937.html (Accessed: 30.07.2024).
[4] SAP SE. SAP Help Portal: Internet Communication Framework – Configuring a Proxy. [Online] Available: https://help.sap.com/docs/ABAP_PLATFORM_NEW/753088fc00704d0a80e7fbd6803c8adb/48d50d6b982b424be10000000a421937.html (Accessed 30.07.2024).
[5] SAP SE. SAP Help Portal: ICF Communications – Controlling Access to RFC Destinations. [Online] Available: https://help.sap.com/docs/ABAP_PLATFORM_NEW/c495ada972d045b2be2869f5573af8e7/489668140eec3987e10000000a421937.html (Accessed 30.07.2024).
[6] Onapsis SE, Thomas Fritsch. The Risks of SAP RFC Callbacks and How to Avoid Them. [Online] Available: https://onapsis.com/blog/risks-sap-rfc-callbacks-and-how-avoid-them/ (Accessed 30.07.2024).
[7] Onapsis SE, Thomas Fritsch. Protect SAP Systems With Unified Connectivity Framework (UCON). Available: https://onapsis.com/blog/protect-sap-systems-unified-connectivity-framework-ucon/ (Accessed 30.07.2024).
[8] Onapsis SE, Thomas Fritsch. How to Securely Introduce Explicit AUTHORITY-CHECKS into Custom RFC-Enabled Function Modules. [Online] Available: https://onapsis.com/blog/how-securely-introduce-explicit-authority-checks-custom-rfc-enabled-function-modules/ (Accessed 30.07.2024).
[9] Onapsis SE, Thomas Fritsch. SAP RFC Read Table: Accessing Arbitrary Tables in SAP. [Online] Available: https://onapsis.com/blog/sap-rfc-read-table-accessing-arbitrary-tables/ (Accessed 30.07.2024).
