Onapsis Publishes Advisories for Cross Site Scripting and OS Command Injection Vulnerabilities
Today, the Onapsis Research Labs released 14 advisories for SAP and 6 for Oracle E-Business Suite. All of the SAP advisories pertain to SAP NetWeaver – the technical integration platform on top of which enterprise and business solutions are developed and run. Half of these advisories for SAP NetWeaver relate to remote command execution vulnerabilities, which will be explained later in this post. On the Oracle side, all six advisories relate to cross-site scripting (XSS) attacks on the core business application Oracle E-Business Suite.
What is OS Command Injection?
OS Command Injection (aka OSCI) is one of the most dangerous vulnerabilities that any system can deal with. According to OWASP, It’s a very critical problem for administrators as a successful exploitation of this type of vulnerability could lead to an entire system compromise. This attack vector consists of an attacker controlling the input of a certain field which would later be used as a part of a statement to be executed in the OS.
What is the best way to deal with this type of vulnerability?
All user input fields should always be treated as dangerous, and therefore it is necessary to sanitize them. To avoid an improper utilization, it is recommended to use some kind of whitelist technique before executing the statement. This protection will reduce the attack surface in case the sanitization was bypassed. Using a blacklist technique instead of whitelist is not recommended, as a whitelist technique only requires you to write how the input fields must be used. If you use a blacklist technique, you must write out all of the ways in which the input fields should not be used. This presents a large window of potential error as it is sometimes difficult to define all ways in which input fields shouldn’t be used. Besides the previously mentioned preventative measures, it is necessary to make sure that the user who is executing dangerous statements is correctly authorized. It’s very common to forget to make proper authorizations, causing unauthorized users to be able to execute OS commands. Even if you are using high-level languages such as ABAP or Python, there are statements that can execute OS commands. Is it wrong? Should you avoid those statements? The answer is that sometimes OS command execution is necessary and administrators should be aware of that. To reduce the risk of an OSCI, it is recommended to design the proper threat model for that functionality and implement all possible preventative measures. According to the search of “OS Command Injection” in SAP’s Launchpad, the amount of notes patching these dangerous vulnerabilities is ~25 since 2012, so it is relevant that Onapsis Research Labs reported 9 more (summarized in seven advisories) of this type, helping SAP and its customers to stay protected.
OSCI in SAP Systems and ABAP
ABAP provides several ways to execute OS commands. In this section, I’m going to focus on the command“CALL ‘SYSTEM’ ID ‘COMMAND’ FIELD cmd”. This statement is actually part of a bigger family known as “CALL cfunc”.
This feature allows Kernel functions, more precisely, any function defined in sapactab.h. SAP strongly recommends that this statement should be for internal use and therefore should not be used for custom developments. In particular, using ‘SYSTEM‘ as the cfunc parameter, allows the execution of operating system commands. Below is an example:
Suppose you develop a function that receives a name as parameter and creates a directory with the given name inside /tmp/: 
As we can see in the picture, this code does what we’ve specified before. Thus, if you use ‘foo’ as parameter, ‘/tmp/foo’ directory will be created. But since we aren’t doing any kind of sanitization to the mentioned parameter, or whitelisting the correct usage of CALL ‘SYSTEM’ statement, an attacker for example, could use ‘foo; COMMAND’ (where COMMAND is any arbitrary OS command) to execute whatever he wants. For example, we can call the function with ‘foo; touch $HOME/test’: 
This code will not only create ‘foo’ directory inside /tmp/ but also will create an empty file named ‘test’, inside /home/adm/ path (later we’ll discuss about adm OS user). 
Deactivation
As mentioned above, it is possible to deactivate statements as a defense strategy. SAP provides a feature to disable the aforementioned statement forcing an exception each time a line like this is attempted to be executed. In order to activate it, the value of the profile parameter rdisp/call_system must be 0. At first glance it may seem reasonable, but unfortunately SAP uses this statement in its standard code – disabling it could cause service disruption.
Authorization
Another preventative measure to take into account is one related to user authorizations at the time of executing the statement. SAP provides an authorization object, S_C_FUNCT, whose goal is to assign authorizations for calling Kernel functions. There is a function called “AUTHORITY_CHECK_C_FUNCTION” that is in charge of checking if the user has the aforementioned authorization object. It is strongly recommended to call this function before each “CALL cfunc” statement, as it will be the first step to have a more secure code. 
Privileges
Another critical question to ask is: Which OS user will finally execute these commands? Is it root? When a SAP system is installed, a new OS user is created. The name of this user will depend on the SID (System ID) you’ve defined for your system. It always has the following structure: adm. Although this user does not have root privileges, it will be able to fully control and administrate the SAP system (turn it on/off, change binary files, remove files, access to database, etc). If an ABAP object is vulnerable to OSCI, the command injected will be executed with adm privileges.
SCTC* Vulnerable Function Modules
In March 2016, vulnerable functions cataloged as HOT NEWS were patched with SAP note 2260344 thanks to one of Onapsis’ own security researchers. The rest of this post will focus on explaining why function module SCTC_REFRESH_IMPORT_USR_CLNT is considered to be vulnerable, as detailed in Onapsis Security Advisory: 2016-046.
Vulnerability Introduction
SCTC is a large development package (subpackage of BASIS) intended to hold/maintain technical configurations. In particular, the vulnerability was present in the ABAP Post-Copy Automation framework (PCA) which is part of SAP Landscape Virtualization Management (LVM). PCA’s main goal is to automatize configuration of extensive technical scenarios. After using PCA to copy systems, the official documentation [10] recommends setting the profile parameter ctc/allow_systemcopy_postconfig of your target system to 1 in favor of protecting your source system. In order to successfully exploit this vulnerability, this configuration is needed.
SCTC_REFRESH_IMPORT_USR_CLNT is not a remote-enabled function module, which means that an authenticated user with privileges to execute functions via a SE37 transaction is needed to successfully exploit this vulnerability. In a certain part of the source code of SCTC_REFRESH_IMPORT_USR_CLNT, a ‘CALL SYSTEM’ statement is executed. For some parameters, user inputs aren’t sanitized. This can lead to the execution of any arbitrary OS command with adm privileges.
Vulnerability Patch
In order to fix this issue, SAP has released security note 2260344. Applying this patch will restrict the possibility to execute a CALL ‘SYSTEM’ statement from a SCTC module, raising an assertion error if you are denied, and therefore will avoid an attacker exploiting the aforedescribed vulnerability.
Conclusions
SAP systems, like any other kind of systems, can be vulnerable to the most dangerous types of vulnerabilities: Operating System Command Injections. Although is it not possible to have a 100% secure system, applying different kind of controls will greatly reduce the attack surface, and therefore will improve protection. It is highly important to understand that when you are developing code, this may introduce/expose a vulnerability of this type. It is critical, to focus on specific places in order to avoid it. Additionally, it is highly recommended not to use ‘CALL SYSTEM’ statement in custom applications, unless you are certain that what you are executing is safe. Implementing the proper security notes for these vulnerabilities is the best way to stay safe against this kind of attacks.