How to Securely Introduce Explicit AUTHORITY-CHECKS into Custom RFC-Enabled Function Modules – Source: securityboulevard.com

Compliance Aspects

Every SAP application provides business-related authorization objects that clearly define specific activities for individual business entities. They are designed to easily fulfill and monitor audit requirements like traceability of assigned authorizations and segregation of duties. 

S_RFC authorizations are not related to a specific business entity or activity. They describe the access permission to a technical object (a function module or a function group). The implicit check on the “technical” S_RFC authorization should not prevent developers from adding explicit AUTHORITY-CHECKs on the intended business-related authorization objects. Otherwise, the activities a user is allowed to do no longer only depend on that user’s identity but also on how the user has accessed the system, via the main door (Dialog Login) or a specific side door (RFC FM).


 

This adds an additional degree of complexity which then leads to a loss of transparency and can cause compliance issues.

Example:


You define your own business entity type and choose activities such as: CREATE, DISPLAY, CHANGE, APPROVE, EXECUTE.

The entities can be managed by the new transaction ZENTITY_TRANS which provides buttons to execute all of the possible activities. Since compliance rules demand a segregation of duties for creating, approving, and processing the entity, a new authorization object ZOBJ_ENTITY is created:

ZOBJ_ENTITY


ID ‘ENTITY_NAME’


     ID ‘FIELD ‘ACTVT’

For each of the transaction buttons, it is possible to check the user’s authorization for the specific activity.

The project requirements state that these activities must be accessible externally. Therefore you create the RFC-FMs:

• Z_ENTITY_CREATE
• Z_ENTITY_DISPLAY
• Z_ENTITY_CHANGE
• Z_ENTITY_APPROVE
• Z_ENTITY_EXECUTE
• Z_ENTITY_SUPER

None of the RFC-FMs contain an explicit AUTHORITY-CHECK on ZOBJ_ENTITY. The RFC-FM Z_ENTITY_SUPER allows the caller to provide the desired activity via an input parameter and all function modules belong to the function group Z_ENTITY.

From an audit and compliance perspective there are several disadvantages to this methodology:

 1.  In order to get all users who are (potentially) authorized to approve entities, it is not enough to use transaction SUIM and search for users with roles containing 

                                  ZOBJ_ENTITY


                                       ID ‘ACTVT’ FIELD ‘APPROVE’

Auditors also have to know that S_RFC authorizations on function modules Z_ENTITY_APPROVE or Z_ENTITY_SUPER and S_RFC authorizations on function group ‘Z_ENTITY’ also allow approving an entity.

2.  The required segregation of duties is automatically violated if a user is assigned to a role with 

                                  S_RFC


                                       ID ‘RFC_TYPE’ FIELD ‘FUGR’


                                       ID ‘RFC_NAME’ FIELD ‘Z_ENTITY’


                                       …                                                        


or

                                  S_RFC


                                       ID ‘RFC_TYPE’ FIELD ‘FUNC’


                                       ID ‘RFC_NAME’ FIELD ‘Z_ENTITY_SUPER’

3.  A consequence of 1. is that defining an appropriate rule set in SAP GRC that considers all possible combinations becomes extremely difficult. If the RFC-FMs include the right AUTHORITY-CHECK, they could be easily identified through a simple where-used analysis.

Consequently, every high-quality code scanning product will report RFC FMs without explicit AUTHORITY-CHECKs as a potential risk. This will force project teams to mitigate these risks before the next audit is scheduled. However, SAP landscapes are extremely complex and project teams are usually afraid of unknown side-effects when introducing AUTHORITY-CHECKS to existing RFC FMs.

Fortunately, SAP provides two powerful tools that support customers in such scenarios, the Unified Connectivity Framework (UCON) and the Switchable Authorization Check Framework (SACF). 

A mitigation project for Missing Authorizations consists of three steps:

Step 1: Housekeeping

The first challenge is to identify these RFC FMs that are in use. When talking about SAP standard RFC FMs, experts say that in an average SAP project, only 5% of them are called in live business processes. This amount should be much higher for RFC FMs developed by customers but a lot of modules are obsolete. This is because:

• Of the often limited life cycle of SAP projects 
• Dynamic changes in the projects’ business demands

There are also a number of customer RFC FMs (and SAP RFC FMs) which were never designed to be externally called. These RFC FMs are only flagged as “Remote-Enabled” because this attribute is required for all function modules that are called locally for parallelization or for decoupling. Such RFC FMs usually don’t necessarily require explicit AUTHORITY-CHECKs since they can be considered local function modules. They can be identified in SAP NetWeaver >= 7.56 by checking the new attribute “Scope”. FMs with scope “From same system, client, and user” do not necessarily require any explicit AUTHORITY-CHECK since they can be considered local FMs:

As of SAP NetWeaver 7.40, SAP has introduced UCON to provide an allowlist approach for filtering which RFC FMs are allowed to access the system externally. The introduction of UCON starts with a logging phase of all calls to RFC FMs. Valuable information for a mitigation project is provided by transaction UCONMON:

• Called RFC FM
• Used RFC Destination
• RFC Server Client (Target Client)
• RFC Server User 
• RFC Caller SID (Calling System)
• RFC Caller Client (Calling Client)

All details about UCON can be found in Protect SAP Systems With Unified Connectivity Framework (UCON). 

As a result of a UCON project, all required RFC FMs are added to the UCON default, communication assembly (CA) and all other RFC FMs are blocked against external calls:

Step 2:  Identifying Missing AUTHORITY-CHECKs

Those RFC FMs of the UCON default CA that are in the customer namespace are used as input for a code scanning product like SAP Code Inspector (Check ID 11A2) or Onapsis Control for Code ABAP (Test Case ID 14). The FMs of the result set can be delegated to the responsible development teams, e.g. based on the owners of the affected packages. 

Step 3: Introducing Explicit Authorization Checks 

The SAP Switchable Authorization Framework (SACF) allows the smooth introduction of new authorization checks in ABAP code that is already in production. Therefore, it is often used by SAP standard applications when introducing explicit authorization checks for already shipped RFC FMs. There are a bunch of SAP Security Notes patching Missing Authorization Check vulnerabilities in SAP standard RFC-FMs. SAP Note 2078596, titled “Further improvements for RFC security”, references more than one hundred SAP Notes that introduce additional AUTHORITY-CHECKs to SAP standard RFC FMs. The majority of the referenced notes take advantage of the SACF to easily introduce the new checks. Unfortunately, SAP hasn’t updated this note since October, 2016. More notes have been released since then–many of them a result of the work of the Onapsis Research Labs (ORL).

The SACF also allows for the creation of customer scenarios (This requires the implementation of SAP Note #3330401 – “SACF: Creation of scenarios in customer namespace”.) and provides the tools to easily integrate new authorization checks into existing customer business processes. 

Introducing explicit authorization checks includes three phases, the Recording phase, the Logging phase, and the Production phase.

Recording Phase


The Recording phase starts with creating an SACF scenario definition and a production scenario with Scenario Status N in transaction SACF. Both are transported into all SAP systems. Developers can then start to mitigate the vulnerable RFC FMs step by step by adding scenario-specific authorization checks. A “scenario-specific authorization check” means that developers add the new authorization checks via the method CL_SACF=>AUTH_CHECK_SPEC, providing the scenario name as an input parameter. The Scenario Status N of the production scenario has two outcomes:

• Newly processed authorization objects are automatically added to the scenario with status Check deactivated (always passes)  
• Authorization objects that are already included in the scenario are checked with regard to their current status

At the end of the Recording phase, the recorded entries can be transferred back from all involved production systems to the development system using transaction SACF_TRANSFER.

Logging Phase


The Logging phase simulates the future active scenario by letting users pass all authorization checks and logging all checks that would have failed in an active scenario. The phase is initialized on the development system by setting the check status for all recorded authorization objects to “Check active without restrictions” and by switching the Scenario Status to L (Scenario in status “Logging” (check valuation successful). The SAL Status must be set to E (Record authorization errors in the Security Audit Log). Note: The SAL recording is only active if the corresponding SAL event (ID DUP) is activated in the SAL configuration for recording. The new settings are recorded in a new transport request and must be transported to all SAP systems. 

The Logging phase should last between three and six months. During this period the Security Event Log should be checked periodically for DUP events indicating a lack of authorizations for an RFC user:

Based on these log entries the role admin can continuously extend the roles of the affected RFC users. 

The Production Phase


Once there are no more SAL entries generated over a period of 2 to 3 months, the Production scenario can be activated. The scenario is activated by setting the Scenario Status to A (Scenario in status “Active” (check valuation as in list) and subsequently transporting the changed scenario to all SAP systems. Note: In active scenarios, failed authorization checks can still be tracked in the SAL. However, if developers add new authorization objects to RFC FMs, checks on these objects will always pass. Therefore, no scenario-specific authorization checks on new authorization objects should be added to RFC FMs after activating the Production scenario. Otherwise, a process must be set up ensuring that the Production scenario is extended and distributed to all systems before the new check is released from the development system.

Security Aspects

For security reasons, it is recommended to replace the scenario-specific authorization checks with regular AUTHORITY-CHECKs after a longer period of stable operation of the production scenario.

Frameworks like UCON and SACF can only provide maximum security if their configuration and status settings can’t be manipulated by unauthorized people. While local changes can be detected via change documents (UCON) or SAL events (event ID DUQ for SACF scenario changes), these mechanisms do not catch changes applied via transports. Thus careful monitoring of all transport requests is required. Monitoring is even more challenging because configuration changes can be transported via the designated object types for RFC states (R3TR RFST), Communication Assemblies (R3TR UCSA), and SACF Scenarios (R3TR SUCD, SUCC) and an attacker could also add entries for the underlying tables to a transport request as well.


The Onapsis Platform is the only SAP security solution that automatically checks for such critical configuration changes in transport requests. Control for Transports detects if 

• New RFC FMs are added to the UCON default CA
• The UCON phase of an RFC FM is changed
• The UCON default CA is changed on a table data level
• The UCON phase of an RFC FM is changed on a table data level
• UCON change documents are manipulated
• An RFC FM is changed that is externally exposed through the UCON default CA
• An active SACF scenario is deactivated
• One or more authorization objects are removed from an SACF scenario
• An SACF scenario is changed on a table data level
• Authorization objects of an SACF scenario are changed on a table data level

Conclusion

The mitigation of missing explicit AUTHORITY-CHECKs in RFC FMs can be complex and challenging. Since RFC FMs are one of the biggest entry points for attackers into SAP systems, SAP customers should definitely add this task to their project plans. Fortunately, SAP supports customers with the Unified Connectivity Framework (UCON) and the Switchable Authorization Check Framework (SACF). Both frameworks track critical configuration changes locally via change documents or SAL events but they don’t detect or track changes applied via transports. These changes can be monitored by the Onapsis Platform which is the only cybersecurity and compliance solution endorsed by SAP. Onapsis Control for Transports provides a set of 10 specific test cases, among others, that identify critical configuration changes in UCON and in SACF configurations.