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

Updates:

OS command execution using sapxpg

As you may have read in part 1 of this series, starting a program on OS level is an interactive task. This means, on OS level the call of a program is always waiting for an answer. And in many cases the return code of the executed program is relevant for further processing in ABAP. If the called program on OS level is not an RFC enabled program (compiled with the SAP RFC library), there is no back channel to populate the return code and furthermore, the RFC connection used to start the program may time out, while the program is still running on the OS level.

To overcome this situation, sapxpg was introduced.

What is the purpose of sapxpg?

sapxpg is an RFC enabled program (or RFC server program) which is used as a wrapper to execute commands or programs on the OS level out of the ABAP stack. It keeps the connection to the gateway open until the command on OS level is finished and it sends back the return code to the ABAP stack for further processing.

Where do we find sapxpg?

While this program is shipped as sapxpg or sapxpg.exe with SAP Kernel, it can also be found on a standalone SAP RFC Gateway or even as a standalone executable on any host.

When is sapxpg involved?

When running external programs:

External programs are OS commands or executable programs/scripts which are directly specified within a step of a batch job:

Please note: This should only be performed by administrative users. The authorization object S_RZL_ADM:ACTVT=01 has to be assigned to the relevant user but no further auth check is carried out!

When running external commands

External commands created in transaction SM49/SM69 can be started within a step of a batch job:

Furthermore, external commands can either be executed directly in SM49/SM69 or from ABAP coding via FM SXPG_COMMAND_EXECUTE_LONG, SXPG_CALL_SYSTEM, or SXPG_COMMAND_EXECUTE.

Please note: When running external commands an authorization check is performed for S_LOG_COM. The authorization object S_LOG_COM allows to specify the external command, OS vendor, and target host. If all of those fields use the wildcard “*”, any external command can be executed on any host.

There is an enhanced security mechanism which allows to restrict the OS programs or commands which may be executed by sapxpg in general. This will be described in another part of this series.

Why is the secinfo of the gateway involved?

As sapxpg acts as an RFC client for handing back the return code to the ABAP, the secinfo file needs the relevant entries allowing this communication. For example,

P USER=* USER-HOST=local HOST=local TP=sapxpg
P USER=* USER-HOST=internal HOST=internal TP=sapxpg

Typically sapxpg is already covered by the default entries:
P USER=* USER-HOST=local HOST=local TP=*
P USER=* USER-HOST=internal HOST=internal TP=*

When external commands or programs are used in batch jobs, the authorizations of which user are relevant?

For batch jobs starting external commands, the auth. check requires that in addition to the scheduling user also the step user must have S_RZL_ADM:ACTVT=01 assigned.
This secure-by-default behavior should not be changed.

When creating or copying a job where an external program is called, it is checked whether the step user has the authorization object S_RZL_ADM assigned.
This secure-by-default behavior should not be changed.

When creating or copying a job where an external program is called, an additional auth check can be enabled. This checks whether the scheduling user has the authorization object S_LOG_COM also assigned, while for the step user this is always checked.

Hint: To enable this check, create the following entries in table BTCOPTIONS:
BTCOPTION = LOGCOMM_AUTHCHECK
VALUE1 = ON

Does sapxpg support SNC secured connections?

To use SNC secured communication between the RFC Gateway and sapxpg, the following entries have to be made with report BTC_SAPXPG_SNC in table BTCOPTIONS:
BTCOPTION = SAPXPG
VALUE1 = SNC
VALUE2 = <SNC partner name of the gateway>

Please note: At time of writing VALUE2 has a limit of 40 characters which may be insufficient. As a workaround, follow the steps described in SAP note 1362020.

To make the sapxpg verify the trust relationship and (optionally) the partner name of the caller, the enhanced security mechanism needs to be leveraged .