As many readers will already be aware, securing the SAP gateway is of crucial importance for the security of SAP systems. But what can happen if the gateway is configured incorrectly or insecurely?
This article will address this question. Insecure reginfo and secinfo ACL files will be used to show which attacks on SAP systems are possible.
This is not intended as a guide to attacking SAP systems. It merely draws attention to the importance of RFC Gateway security for securing systems.
Attack on systems with insecure reginfo ACL
Let's assume that our SAP Basis administrator has set the reginfo ACL insecurely. This can be done, for example, by one of the following configurations:
- gw/acl_mode = 0 and the reginfo file does not exist.
- gw/sim_mode = 1, which removes the implicit “deny all” line. To prevent an interruption of the SAP system, the simulation mode is normally activated during the setup of secinfo and reginfo.
- In the event of attacks from systems for which an Allow entry that is too open is entered in reginfo.
For example: P TP=* HOST=erpdev.vclass.local
In this case, an attacker can register any program with the gateway. He could choose the following configuration for an attack:
./program -a IGS.
IGS.
An attacker could exploit this behavior to carry out an RFC callback attack. If the registered server (and therefore the implemented function block) is called, a connection handle is automatically created. The attacker can use this connection handle to call any other modules in ABAP. In practice, an attacker would, for example, create a user and assign SAP_ALL (or comparable authorizations) to this user.
This example therefore exploits two vulnerabilities in an SAP system, both of which are frequently found in systems in practice. A well-configured reginfo ACL would prevent the attack in the same way as correctly configured RFC callback security.
Attack on systems with an insecure secinfo ACL
Attacks on an insecure secinfo ACL are even easier for an attacker to carry out if the configuration is insecure. The requirements for an attack are very similar to reginfo. Profile parameters gw/acl_mode = 0 (with missing secinfo file), gw/sim_mode = 1 or an Allow entry that is too open for an attacker system can lead to an attack on the system being possible.
A proof of concept has already been created by Dmitry @_chipik Chastuhin (https://github.com/chipik/SAP_GW_RCE_exploit). Any operating system command can be executed on the attacked system. However, an attacker can also achieve the same with a normal SAP system (as an attacker system). In the following, we assume that the attacker has full control over the attacker system. This is relatively simple in practice, for example if an attacker installs an SAP system on his own laptop and this laptop is connected to the company network.
For the actual attack, the attacker creates a Type T connection to the attacked system with the following settings:
- Activation type: Start on explicit host
- Program: sapxpg
(In some cases, the OS command is also used directly. In this case, however, the attacker does not receive a response from the attacked system) - Target machine: <Anzugreifendes System>
- Gateway host: <gateway host>
- Gateway service: <Port of the gateway>
Next, an external operating system command is created in SM49.
Example: Operating system command: whoami
This command is then executed (using the previously created RFC Type T connection) on the system to be attacked:
Since all these settings or commands take place on the attacker system, authorization checks (e.g. for SM59) are irrelevant. The assumption is that the attacker has full control over the attacker system.
An attacker could also record the connection and replay it to a real attack target. As there is no authentication outside the secinfo ACLs, this would be a worthwhile approach.
In addition to good network segmentation, only a good secinfo configuration offers protection.
Correct configuration of reginfo and secinfo
It is questionable how reginfo and secinfo can be set up securely without restricting the SAP system. According to SAP Note 1408081 (Basic settings for reg_info and sec_info), a good approach is to start with the following initial values:
reg_info:
#VERSION=2
#
# Further lines of reginfo are entered here.
# Last line of the reg_info
P TP=* HOST=internal,local CANCEL=internal,local ACCESS=internal,local
sec_info:
#VERSION=2
#
# Further lines of sec_info are entered here.
# Last line of the sec_info
P USER=* USER-HOST=internal,local HOST=internal,local TP=*
For reginfo and secinfo, the next step depends on whether the security or availability of the systems (temporarily) plays a greater role.
1) Security plays a more important role
The secinfo / reginfo is armed with the recommended setting from SAP Note 1408081. However, simulation mode is not activated for high security. If a connection fails, an entry is added to secinfo / reginfo. Failed requests can be added very easily via a log analysis.
2) Availability plays a more important role
The secinfo / reginfo is activated with the recommended setting from SAP note 1408081. At the same time, the simulation mode is temporarily activated (gw/sim_mode = 1). Now no requests to the gateway are temporarily rejected. Requests from attackers are therefore also fully permitted. Once all entries have been added, also with log analysis, deactivate simulation mode again. The simulation mode prevents an interruption by secinfo or reginfo until the settings for secinfo and reginfo ACLs have been made.
Conclusion
To summarize, it can be stated that the correct configuration of secinfo and reginfo is a very important point for the security of SAP systems. Incorrect configurations offer attackers an easy way to attack the system.
If you want to further enhance your security skills, I recommend the course AD680 Active Defense - SAP NetWeaver Security Workshop. This course is run in cooperation between Claranet and SAP and offers insights into many security-related SAP topics.