RFC Gateway security, part 8 – OS command execution using sapxpg
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
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.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
Please note: When running external commands an authorization check is performed for
S_LOG_COM. The authorization object
S_LOG_COMallows 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
sapxpgin general. This will be described in another part of this series.
Why is the secinfo of the gateway involved?
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
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
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
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 .
Very good article, like always!
Besides the authorization we use the sapxpg.sec and additional logging for sapxpg, because command-execution is crucial.
866732 - Security check when executing external commands/programs
Best regards, Daniel
thank you for your comment! Regarding the enhanced security mechanism I will publish another blogpost in this series, soon.#