SAP Vulnerability Type: OS Command Injection
Chapters
Share Article
When it comes to cybersecurity, it is crucial to understand the different types of vulnerabilities that can affect software systems. This is shown during the monthly SAP Security Patch Days, where SAP shows patches to known vulnerabilities within its software products.
A type of SAP vulnerability that frequently receives a patch and poses a significant risk to SAP applications is OS Command Injection. This article will delve into the concept of this SAP vulnerability type, how it can be orchestrated from the SAP application stack, its potential risks, and mitigation practices to minimize its impact.
What is SAP OS Command Injection Vulnerability?
OS Command Injection is a security vulnerability when an application allows unauthorized users to execute arbitrary operating system commands. It happens when the S/4HANA or SAP NetWeaver application does not properly validate or sanitize user input, which leads to the injection of malicious commands executed by the underlying operating system.
Attackers can use this vulnerability to take over the host, modify, or delete operating system files to corrupt the environment. Successful attack attempts can therefore cause devastating damage, including the risk of reputational damage, data loss, or unplanned outage of critical infrastructure.
How can attackers exploit the OS Command Injection Vulnerability?
SAP applications like S/4 HANA typically run on Unix/Linux-based operating systems (OS). The proper function of the SAP technology stack must communicate with the underlying OS leveraging a user on OS-level. This makes it difficult to distinguish malicious OS commands from calls executed by standard SAP operations.
SAP S/4HANA runs as a service on the operation system, which is started in the context of the <SID>ADM user. With <SID> being the 3-digit SAP system ID, a system with the ID „PRD“ would have the context user „PRDADM“.
This <SID>ADM user is created as part of the installation process as an operating system user, not as a database user. This user has full access to all local resources associated with SAP systems and is also known as the system administrator.
Next to OS users, there are also SAP kernel users having capabilities like the <SID>ADM OS-user: SAPSYS, user UNKNOWN, and even the User ‘…………’ (12-Dots).
Any SAP application user account that injects arbitrage OS commands will execute the desired command with system administrator privileges.
You can imagine that many possibilities to execute an OS command exist, e.g., through the transaction SM69. While you can control the OS commands triggered through SM69, an easy way to bypass this can be using the report RSBDCOS0 (SNote: 2443193 – Report RSBDCOS0 – Execute OS command from SAP GUI).
Unless the authorization of the report RSBDCOS0 properly secures it, it does not pose a risk. Besides the outlined examples that are publicly known and can be found in many KB/Help pages online, there are several ways to exploit unpatched OS command vulnerabilities within the SAP application stack to take control of the operation system.
How to detect SAP OS Command Injections?
Manually validating the audit or system logs will hardly lead to the detection of malicious calls and result in security fatigue due to the substantial number of legitimate calls. Monitoring, however, remains the only chance to identify malicious OS commands and their caller.
When continuous monitoring is established, it is crucial to identify the calling vector. OS calls may be triggered via standard processes, standard or custom source code, external calls etc. By combining all relevant data sources such as audit logs and system logs it is possible to identify the source and context of an OS command call.
OS commands executed via e.g., ABAP-program RSBDCOS0 are recorded within the system log. OS-command executions via transactions get recorded by reading the logs stored in trace files dev_cp and dev_w*.
This is also the reason so many organizations still struggle with the activation of the Security Audit Log without filtering. However, assessing the SAP Security Audit Log may not even be enough to detect the exploitation.
How to prevent SAP OS Command Injections?
The most obvious solution to control SAP OS Command executions and prevent malicious injections is through strict authorization management. The transaction SM69 allows you to maintain a “whitelist” of authorized OS commands that can be executed from the application level:
However, this filter applies only if the command is called from SAP standard transaction SM69.
You can e.g. scan for users having the authorization to define OS commands via transaction SM69 with the query
- S_TCODE, TCD = SM69 AND
- S_RZL_ADM, ACTVT= 01
One more vector of calling is through the ABAP statement ‘CALL SYSTEM’. Here calls can be prevented via the CALL ‘SYSTEM’ expression by setting the rdisp/call_system parameter value to ‘0’. It can be done by means of the RZ11 transaction. However, the call-barring command is applied to the entire system, which can lead to unpredictable consequences, as SAP uses CALL ‘SYSTEM’ for the execution of OS commands too.
You can forbid command calls via SYSTEM. If for some reason you still need the execution of dynamic generated OS command via CALL ‘SYSTEM’, do not forget about whitelisting. An example of whitelisting will be like the above but have a list of allowed commands to execute.
If an operating system command call is necessary, the SAPXPG mechanism is the recommended way to do it. This offers increased security due to the following characteristics:
- Abstraction from different operating systems
- Predefined operating system commands
- Stricter handling of parameters
- Allows check modules (such as allow lists) to be defined
- Predefined authorization check
New operating system commands must first be defined using transaction SM69. If possible, exclude input values because these can also cause a security problem. The function module SXPG_CALL_SYSTEM can then be used to make secured OS calls from ABAP custom code.
Summary
Communication between the SAP system and the underlying operating system is a crucial function for proper operations. As this communication leverages a privileged user on OS-level, it maintains a permanent risk for vulnerabilities like the “SAP OS Command Injection”. The typical exploitation of this vulnerability happens through transactions like SM69 or reports like RSBDCOS0 as they allow SAP users to perform OS-calls in the context of a privileged user. However, there are several ways to exploit unpatched OS command vulnerabilities within the SAP application stack. Therefore, it is a must to set up automated monitoring of all relevant data sources such as audit logs and system logs and combine their records to identify the calling vector for such OS-commands. However, for controlling the execution of OS-commands, authorized calls should be configured for transaction SM69. Other call vectors like the ABAP statement ‘CALL SYSTEM’ can be controlled through proper configuration of system parameters and whitelisting of calls. Ideally, necessary OS-command execution should be performed through the SAPXPG mechanisms as it provides the best way to control it.
