RFC Gateway security, part 9 – enhanced security for sapxpg

[JoeGoerlich]

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 a talk 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
Part 8: OS command execution using sapxpg
Part 9: enhanced security for sapxpg

Updates:

---

Enhanced security for sapxpg

As you may have read in part 8 of this series, starting a program on OS level is done with the wrapper program sapxpg. To restrict which OS commands can be executed by sapxpg, the enhanced security profile can be configured.

Before going into details about this, let's have a closer look on sapxpg.

In which scenarios can sapxpg be used ?

There are three scenarios in which sapxpg is used to execute OS commands:

1.) on the local application server,

2.) on a target destination which runs a (standalone) RFC Gateway,

3.) on a host to which a connection is established via a (secure) remote shell (according to the parameter gw/rem_start).

Please note: This feature is disabled by default as of ABAP Platform 2020 as part of the Secure-by-default program (profile parameter gw/rem_start). Also on earlier releases this was just barely used in the past.

How does the ABAP system communicate with sapxpg?

sapxpg acts as a ‘Started external RFC Server’ and receives the to be executed command and its parameters via RFC.

For the communication between the ABAP system and sapxpg, either

a) a dynamic RFC destination is automatically created (and deleted) during runtime or

b) the RFC destination SAPXPG_LOCAL or

c) a custom RFC destination or

d) in special scenarios the RFC destination SAPXPG_DBDEST_<DB-HOST> is used.

 

For a)

A dynamic RFC destination named %_TCPIP_%<n> of Type T will be generated automatically at runtime and will be deleted immediately after the command execution. In this RFC destination, the program sapxpg or sapxpg.exe will be defined, and the target host (as explicit Target Host) or target destination (as Gateway Host) will be set, based on the input variables. The input variables are specified by the parameters in the FMs, the batchjob step, or the external command (field targetsystem or field destination).

Please note:This dynamic connection does not support SNC.

For b)

If in the external command or program no target destination or target host was defined and if in the table BTCOPTIONS field BTCOPTION the entry SAPXPG is present, then the RFC destination of Type T named SAPXPG_LOCAL will be used. If this destination is not there, it will be created at the next execution of an external command or program.

Hint: Once this this RFC connection was created, it can be SNC enabled. This is a prerequisite for setting the profile parameter snc/permit_insecure_start = 0.
If the SNC partner name is configured in the  sapxpg.sec (see below), both the communication channel from RFC Gateway to sapxpg as well as from sapxpg to the RFC Gateway are secured.

For c)

A custom RFC destination can be created and assigned to external commands in SM49/SM69.

Furthermore, it is possible to create a mapping for a target hostname to an RFC destination by making the following entry in table BTCOPTIONS:

BTCOPTION	EXTCOMM_HOST_TO_DEST
VALUE1	<hostname-target>
VALUE2	<RFC destination name>

For a), b), and c)

If the OS command is to be executed on a target destination, the defined RFC Gateway will be connected via RFC and sapxpg will be started as the user which runs the RFC Gateway.

If the OS command is to be executed on a target host (which is not mapped to an RFC destination), the defined host is connected by remote shell or ssh and sapxpg will be started.

For d)

Destination SAPXPG_DBDEST_<DB-HOST> is hard-coded and used to execute external commands on the DB host, for example by transaction DB13.

 

General remark for RFC destinations of type T

Programs started on the same system as the application instance runs (indicated in the technical settings of the destination when the radio button 'Start on Application Server' is selected) are started by default as a fork of the work process.
Whether programs are started instead by the RFC Gateway as a fork of the gateway process, is determined by the hostname of the target host: If the hostname does not match either sy-host or the hostname in rdisp/myname, it will be executed as a fork of the gateway process.
This has implications to specific secenarios. For example, this could lead to issues if two SIDs ABC and EFG run on the same host and one system should call sapxpg on the other system. In this case sapxpg would be executed as a fork of the work process of ABC under user abcadm and not on EFG as user efgadm as one may think.

Hint: Whether program are started as fork of the work process can be adjusted with the profile parameter rfc/use_gwstart. With the parameter value 1 set, each OS command execution is performed by the RFC gateway. In the mentioned scenario, this would make sure that if ABC is executing an OS command on EFG sapxpg would be started in the context of efgadm.

In addition to that, if programs are started as a fork of a work process they will run in DIR_HOME, while when they are started as a fork of the gateway process they will run in HOME. This effects the access to files that the relevant program executed by sapxpg may require.

How can we restrict the usage of sapxpg?

As we learned in part 8 of this series, in the scenario "running external programs" there are no further authorization checks involved. Furthermore, by default there are no restrictions for sapxpg to execute arbitrary OS commands. This is where the enhanced security profile enters the stage.

To enable the enhanced security for sapxpg, the following environment variables have to be set:
SAPXPG_SEC_CHECK = POS
SAPXPG_SEC_FILE_PATH = <directory for file sapxpg.sec>

Please note: The environment variables may be set via SAPStartSrv by adding SETENV_<xx>=<environment_variable>=<value> in the DEFAULT profile. Since environment variables set by this method are only valid for child processes of SAPStartSrv (like disp+work or gwrd) it is recommended to set them additionally by other means to cover cases where sapxpg is started by other means. For example, set them in the login shell profile of the <sapsid>adm or by a shell script setting the variables right before invoking sapxpg.

Then the file sapxpg.sec has to be created and filled with rules to restrict which user (#U#) from which client (#C#) can run which OS commands (#O#) from which type (#T#) of which partner system (#S#).
The rules are defined in the format of:

#U#<user name>#C#<client>#T#<list of allowed connection types>#F#<list of allowed functions>#O#<list of allowed operating system commands>#S#<allowed partner SNC name>#

• 
  
  
  
  • After #U# the relevant ABAP username has to be specified (a list is not supported here, instead one line per user has to be maintained) or the wildcard * can be used to allow all users.
  
  
  
  

Hint: While on ABAP side for External Commands the authorization check via S_LOG_COM is in place, here it can be restricted on the sapxpg side which OS commands can be executed. This has an implicit effect on External Programs.

• 
  
  
  
  • After #C# the relevant client has to be specified or the wildcard * can be used to allow users from all clients.
  
  
  
  

Hint: The combination of #U# and #C# should be unique to make sure the rules are applied as desired. If a rule for a combination is found, subsequent rules will not be evaluated.

• 
  
  
  
  • After #T# the type of system from which the call is accepted has to be specified. 3 means that only calls from an SAP system are permitted.
  
  
  • After #O# a comma separated list of allowed OS commands has to be specified or specify the wildcard * can be used to allow all OS commands.
  
  
  • After #S# the SNC partner name of the calling SAP system has to be specified (typically this is the name contained in the profile parameter snc/identity/as) or  +++ can be used to only verify the trust, or the wildcard * can be used to allow command execution from any calling system.
  
  
  
  

Hint: Setting the SNC partner name in the file sapxpg.sec is comparable to maintaining SNCSYSACL in ABAP.

Logging

By default sapxpg itself does not log when and from which host which user from which client executed which OS commands with which parameters.

To enable the logging, the following environment variables have to be set:

SAPXPG_UC_PROTOCOL_PATH = /<path>/
SAPXPG_UC_PROTOCOL = 1

The log files are named xpg_prot_<MM>-<DD>.

Please note: Again, the environment variables may be set via SAPStartSrv by adding SETENV_<xx>=<environment_variable>=<value> in the DEFAULT profile. Since environment variables set by this method are only valid for child processes of SAPStartSrv (like disp+work or gwrd) it is recommended to set them additionally by other means. For example, set them in the login shell profile of the <sapsid>adm or by a shell script setting the variables right before invoking sapxpg.

---

<--Previous