Technical Articles
RFC Gateway security, part 3 – secinfo ACL
From my experience the RFC Gateway security is for many SAP Administrators still a not well understood topic. As a result many SAP systems lack for example of proper defined ACLs to prevent malicious use.
After an attack vector was published in the talk “SAP Gateway to Heaven” from Mathieu Geli and Dmitry Chastuhin at OPDCA 2019 Dubai (https://github.com/gelim/sap_ms) the RFC Gateway security is even more important than ever. This publication got considerable public attention as 10KBLAZE.
With this blogpost series i try to give a comprehensive explanation of the RFC Gateway Security:
Part 1: General questions about the RFC Gateway and RFC Gateway security.
Part 2: reginfo ACL in detail.
Part 3: secinfo ACL in detail.
Part 4: prxyinfo ACL in detail.
Part 5: ACLs and the RFC Gateway security.
Part 6: RFC Gateway Logging.
Part 7: Secure communication
Updates:
2021-11-10: Added Part 7: Secure communication
2021-03-17: Rephrased some sections to be more precise.
secinfo ACL
Please make sure you have read at least part 1 of this series to be familiar with the basics of the RFC Gateway and the terms i use to describe things.
What exactly is defined in the rules in the secinfo ACL?
The secinfo ACL contains rules related to ‘Started external RFC Servers’.
Every line corresponds one rule. A rule defines
-
- if it specifies a permit or a deny. This is defined by the letter
P or D
at the beginning of a rule. - which user is allowed to start a program. This is defined in
USER=
.
Please note: If a rule should be restricted to certain users please be aware that for ‘USER’ it is not possible to maintain a comma separated list. Instead separate rules must be created.
- from which RFC client can this be initiated. This is specified in
USER-HOST=
. - the remote host on which the executable is to be started. This is defined in
HOST=
. - the executable which will be executed on the OS level with the permissions of either the OS user running the RFC Gateway process or the credentials of an SAP user. This is defined in
TP=
based on the executable name or its fullpath (e.g., if it is not in $PATH).
- if it specifies a permit or a deny. This is defined by the letter
What are the common use cases?
Starting external programs on the local RFC Gateway
On SAP NetWeaver AS ABAP starting external programs by the local RFC Gateways is commonly used. For example the STMS calls the executable ‘tp’ during transport management, transaction SM49/SM69 calls ‘sapxpg’ to execute OS commands, or ‘saphttp’ is called to connect to content servers (if not switched to the ICM plugin as described in SAP note 2570180).
To identify this use case we can look for TCP/IP connections with “Technical Setting” – “Activation Type = Start on Application Server”:
We can verify this during runtime by going to transaction SMGW and look for the active connections:
or by going to “Logged on Clients” and looking for lines with “System Type = External Client” and “Gateway Host = 127.0.0.1” (in some cases this may be any other IP address or hostname of a server of the same system). The related program name can be found in column ‘TP Name’:
Please note: ‘SAPXPG’ has a special behavior: Whenever a command is executed in SM49/SM69 a temporary TCP/TP connection named ‘%_TCPIP_%<n>’ will be created with the program name ‘/usr/sap/$SAPSYSTEMNAME/<Instance-Name>/exe/sapxpg’ and the actual command as parameters. After execution this temporary TCP/IP connection will be deleted.
Since these programs are shown only during their execution it would be a better approach to look into the log files of the RFC Gateway and search for ‘secinfo accepted:’ or ‘secinfo denied:’ to identify which programs have been called in the past, e.g.,:
SAP introduced an internal rule in the secinfo ACL to allow the starting of any programs on the same server :
P USER=* USER-HOST=internal,local HOST=internal,local TP=*
This rule is generated when gw/acl_mode = 1 is set but no custom secinfo ACL was defined.
It is common to define this rule also in a custom reginfo file as the last rule.
Starting external programs on a remote host
The RFC Gateway allows to connect to remote hosts using SSH or remote Shell (depending on the configuration in the corresponding TCP/IP connection and the value of parameter ‘gw/rem_start’) to execute programs on it.
Please note: Additional setup to allow connecting to the remote server is necessary.
To identify this use case we can look for TCP/IP connections with “Technical Setting” – “Activation Type = Start on Explicit Host” and a “Target Host” different from hosts of the application servers of the same system.
For this scenario a custom rule in the secinfo ACL would be necessary, e.g.,
P USER=<username> USER-HOST=internal,local,<rfc-client-host> HOST=<target-host> TP=<TP-Name>
Starting external programs on a remote RFC Gateway
RFC clients can also connect to a remote RFC Gateway using RFC or SNC to start programs on its host.
To identify use cases for starting external programs via remote RFC Gateways from our AS ABAP we can look for TCP/IP connections with “Technical Setting” – “Activation Type = Start on Explicit Host” and a “Target Host” as well as “Gateway Host” different from the IP address or hostname of any application server of the same system.
For this scenario acustom rule in the secinfo ACL of the remote RFC Gateway would be necessary, e.g.,
P USER=<username> USER-HOST=<AS-host>,<rfc-client-host> HOST=local TP=<TP-Name>
Hi Johannes,
nice collection of the RFC gateway topics - especially making the hint to the well known RCEs.
I would also recommend to check sapxpg.sec implementation, because most scenarios are attacking sapxpg-usage.
The given SAP note about sapxpg.sec is pretty old, but still valid.
Best regards,
Daniel
Hi Johannes,
can you also post ACL examples with system type "Remote Gateway"?
Best regards
Sreenivas
Hello Sreenivasa,
What do you mean by 'system type "remote gateway"'?
The secinfo file will be checked at the gateway were the program will be started.
So, for example:
It has an SM59 destination that will start a program on demand, and the "gateway options" of this destination point to a remote gateway on "server2".
Regards,
Isaías