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.
There are standard function module to check the RFC connection is working or not, check these function modules. RFCTRUSTEDCHECK - RFC connection test for trusted systems Check other FMs also accoding to your usage. CPLB29RFCDESTCHECK - Checks the existence of a RFC Destination. Details of RFC IN BACKGROUND TASK The post described about tRFC(Asynchronous RFC - IN BACKGROUND TASK) details. Consider we have two system and one system does some business process, then calls another system to pass the data via RFC connection in an asynchronous way and commits the business process. 1- Go to Markview Home Administration - Module Admin- Gateway Admin Click Configure BAPI connection Check the connections details and make sure that you use the correct fully qualified host name. 2- Go to Markview Home Administration - Module Admin- Gateway Admin Click Configure RFC Server Check the server details and make sure that you use the correct fully qualified host name. Manual way to test a RFC connection is to goto transaction SM59, select the RFC Destination, Double click on the same and Click on Action Button – Connection Test AUTOMATED PROGRAM TO SIMULATE SM59 – Connection Test I have create a program using a standard function module CATCHECKRFCDESTINATION, Syntax of the program as follows. ABAP, Connection Test, HTTPS service, Process Integration 7.0, PI 7.0, PI 7.01, PI 7.02, Process Integration 7.10, PI 7.10, Process Integration 7.11, PI 7.11, Process.
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.
Sap Rfc Port Number
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.
For setup of trusted RFC’s read this blog.
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.
The result will give you a list of potentially dangerous RFC connections and the user ID’s used.
Sap Rfc Connection Test Timeout
This you can use as a work list for checking.
Read more on RFC security checking in this blog.
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.
Test Rfc Connection In Sap
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”.