Anatomy of an SAP Vulnerability: Finding and Exploiting CVE-2023-36922
Chapters
Share Article
Posted by
Daniel Peisker (PwC Germany),
Benedikt Schumacher (PwC Germany),
Joris van de Vis (SecurityBridge)
SecurityBridge and PwC Germany actively contribute to enhancing the security of the SAP ecosystem through in-depth SAP Security research and advice. This article is the first of two parts and stems from the combined effort of three SAP Security experts: Daniel Peisker (PwC Germany), Benedikt Schumacher (PwC Germany), and Joris Van De Vis (SecurityBridge).
We provide a detailed analysis of the SAP vulnerability CVE-2023-36922, shedding light on its security risk and the common risks of all vulnerabilities with potential access on the OS layer (either via commands or direct file access). As these vulnerabilities are part of a larger pattern rather than single incidents, we will guide you in the second part of this series on reducing the overall risk, going beyond mere patching.
SAP vulnerabilities we identify during our SAP security research are directly reported to the SAP Security Response team, leading to fixes that are typically shipped on Patch Tuesday. In the Patch Tuesday release of December 2023, SAP Security note 3399691 (Update 1 to 3350297 – [CVE-2023-36922] OS command injection vulnerability in SAP ECC and SAP S/4HANA (IS-OIL) was released as a direct result of research activities. These types of vulnerabilities are often ranked high on the Common Vulnerability Scoring System (CVSS) – in this case, with a score of 9,1 out of 10. This is a serious vulnerability that should prompt a quick implementation of the SAP Security note within vulnerable customers’ systems.
We found the CVE with structured code analysis
Our research activities to find vulnerabilities make use of different techniques and methods. One of them is to review the SAP standard code base for vulnerabilities like missing authorization checks or, for example, missing input validation around dangerous statements. To be efficient, we make use of tooling that automatically indexes the complete ABAP code base of a specific SAP system to make searching afterward faster and easier. By doing so, we focused on the code base of SAP ERP and searched for the statement “CALL SYSTEM”. This is a kernel call that allows for the execution of Operating System (OS) commands through the SAP Kernel, triggered from ABAP code. This command, when not properly protected by authorizations and input validation, might be prone to OS command injection where a user can execute any OS command directly on the SAP underlying Operating System.
While reviewing the ABAP code base for SAP ERP, we discovered that the report ROIB_QCI_CALL_TEST contained this statement and was not properly protected. This occurred despite the implementation of SAP Security Note 3350297, released earlier to prevent similar exploits. Still, the transaction O3D2 report could be exploited since the “CALL SYSTEM” statement could be abused to inject OS commands via the input parameters on the screen. In the below code snippet, you can see the actual place where the system call is made:
The ls_parameter parameter contains input that is coming from the User-Interface and can therefore be used to inject your own custom OS commands.
For remediation, we recommend importing the SAP Security Note 3399691 via transaction SNOTE. This will introduce proper input validation from the selection screen and remove the option to test individual entries.
How this vulnerability could be exploited
To exploit this vulnerability, the industry solution IS-OIL must be active. This is a solution developed for the oil industry, an industry that is targeted a lot for geo-political and financial motives, for obvious reasons.
To exploit this vulnerability, we make use of the transaction O3D2, even though you can also run report ROIB_QCI_CALL_TEST from SA38 for example. To be able to inject your custom commands you need to set the Call Parameters to “CALL SYSTEM”:
Then select the “Test selected Routines” radio button:
The field “Name of Subroutine/Function” contains the value “calcgs” by default, which is already a predefined OS command. Since this field is open for user input you can place a “;” behind it to add your own commands. For example, the value
calcgs ; mkdir ABC
would create the directory ‘ABC’ on the Operating System. Which is probably not desirable, but not necessarily a disruptive or security-relevant action. This changes when for example you would pass the below two lines in two runs to the report:
calcgs ; echo ‘SELECT * from USR02’ > script.sql
calcgs ; hdbsql -n vhcalhdbdb -i 00 -U DEFAULT -o output.txt -I script.sql
The above two lines create a file ‘script.sql’ that contains the text ‘SELECT * from USR02’ that in the second line gets executed specifically for HANA Databases and the output is written to a new file ‘output.txt’, containing all table entries of the USR02 table. See below video for an example of exploiting this scenario.
Risk of OS-accessing vulnerabilities in SAP code
To understand the risk associated with the described and similar scenarios, it is important to consider both the potential probability and consequences (impact).
Probability
The probability of encountering vulnerabilities in SAP standard code or custom code that allows for unauthorized execution of operating system commands or access to directories and files without proper authorization checks or limitations is not uncommon. In the past, there have been cases of such vulnerabilities in SAP standard code, in addition to the CVE case mentioned in this blog – many of them have been addressed and fixed.
It is important to recognize that these vulnerabilities are not limited to SAP standard code alone. Custom code, whether developed by external parties or within your organization, can also contain similar vulnerabilities. These vulnerabilities may arise due to inadequate input validation, insufficient authorization checks, but also the authorization of SAP users to critical SAP transactions or programs without proper restrictions.
Impact
Access to the host system within the SAP application, including command execution and file access, is carried out using the user and group context of the instance binary. By default, this context is set to user <sid>adm and group sapsys, where <sid> represents the system ID.
Without additional protection measures, an SAP user with access to a directory, file, or the ability to execute Operating System commands could thus:
- access, modify, or delete directories and files owned by the user <sid>adm or group sapsys on the host system
- access, modify, or delete directories and files with granted access to others, such as world-readable, world-writable
- execute executable files where <sid>adm und sapsys have access to
Since the SAP binary directory is fully owned by <sid>adm and sapsys, this means that all directories and files within the SAP installation and other SAP systems with the same group can be accessed, modified, or deleted. This includes critical files like the Security Audit Log stored under /usr/sap/<sid>/(…). At the same time, access to the database running on the same host system might become possible.
In many cases, file authorizations on the host system are not adequately managed or controlled. It is common to come across situations where critical files are unintentionally stored in temporary or shared folders with permissions that allow them to be read, written, or executed by anyone (or <sid>adm, sapsys). This could be exemplary backup files like shadow (users and password hashes) or critical keystores. Furthermore, accidental modifications to the authorizations of crucial directories and files can occur during administrative tasks.
Business Risk
In situations where unauthorized access to the host system occurs, the potential consequences extend beyond the immediate impact on the SAP system. Unauthorized access can lead to the acquisition of sensitive information, enabling attackers to exploit vulnerabilities in other SAP or IT systems. This could also be achieved using executable binaries, such as scripts, which can be leveraged to infiltrate and compromise additional systems.
To illustrate potential risks to the business, let’s consider a specific example related to the availability of the financial system at the end of the financial year. As part of a potential attack utilizing the vulnerability, sensitive files, including system files and the database, are deliberately deleted. Consequently, the system becomes inoperable, rendering critical transactional data inaccessible. The resulting damages are substantial, encompassing:
- Financial losses incurred from rebuilding the system, restoring data from backups (if available), and re-entering non-backed-up data result in significant financial losses,
- Compliance issues arising due to the inability to meet timely financial reporting deadlines, potential inaccuracies in recording financial transactions, and the inability to provide evidence of controls or data integrity pose compliance challenges, and
- Reputational damage caused by delays in publishing annual financial statements, limitations on the audit opinion, and disclosure of security incidents to customers and business partners leads to reputational harm.
This example highlights how the risk chain can be specifically analyzed for the business. Such examples can be applied to
- any other systems, even those that are not financially relevant, and
- by not only focusing on availability but also confidentiality or integrity scenarios.
In our next article, we will share with you how to reduce your risk of OS-access vulnerabilities in SAP code. Stay tuned for detailed strategies and best practices to enhance your system’s security!
