Posted by Joris van de Vis, SAP Security researcher and co-founder at Protect4S
Introduction
In this post, we’ll look at CVE-2019-0328, a vulnerability found by the team behind Protect4S that exists in all versions of SAP NetWeaver. The vulnerability allows Operating system Command Injection, that in specific cases leads to local execution of Operating System Commands and for example, escalation of privileges. The number of days between reporting the issue and a fix was 105 days:
25/03/2019: Reported to SAP
08/07/2019: Release of SAP Security note 2774489
SAP has assigned CVE-2019-0328 to the vulnerability with a CVSS 3.0 score of 8.7 and released SAP Security note 2774489 to fix it. 12 months after the release of the fix, we believe this should be more than sufficient for SAP’s customers to have this SAP Security note being installed.
A video of exploitation of this vulnerability can be found here.
Bug Hunting
ABAP Code Indexing
We use different techniques to find vulnerabilities in SAP software, but quite often we rely on a simple but effective way of searching the code by indexing it first. This greatly reduces the time needed to search through the entire codebase of an SAP system. There are different ways of indexing SAP ABAP code. We used an older but reliable way via SOLR (Credits to Martin Ceronio). The setup is easy and indexing a complete SAP NetWeaver stack takes several hours. After that, searching through the ABAP code is really easy and gives you output like below that is clickable and brings you directly to the ABAP program:
We searched in the example above for the “CALL SYSTEM” statement that executes OS commands from the SAP ABAP kernel directly on the Operating System and if it is not properly protected via input validation, it might lead to OS command injection. This is the typical way of doing OS command injection and we reported several such cases to the SAP Security response team. But there are other options for injection OS commands.
The Open Dataset Filter Command
In SAP, if you want to open a file in the Operating System, you can use the Open Dataset command. This is a widely used statement by developers, but it has an obscure bonus; The Filter addition. This addition allows the execution of OS commands when opening a file. See this reference for more information.
When playing a bit with the search strings in our indexer, we found one reference to this filter statement that looked promising:
A quick first check has indeed shown the existence of the statement:
We normally check the results for cases
that exist in a report, function module or class that has so-called selection parameters,
because those fields can be used to inject commands. ABAP objects without
selection parameters are often much harder to abuse, but in our example, we saw that the found include LSXIVERI_ADAPTERF01, which
was used in function module SXIVERI_TECH_ADAPTER_EXECUTE.
From Potential Vulnerability to PoC
After some searching through the code and debugging, we saw that the vulnerable line with the filter command was controlled by the FILE_ADDRESS_OUT input parameter. However, successful exploitation was blocked by the absence of a so-called Logical File:
Logical Files
Logical files in SAP systems are used as a platform-independent way of handling files on different types of Operating systems. In our example, the vulnerable Function Module needs them to operate successfully. What this means in practice is that this exploit will only work for customers that do use the vulnerable functionality, which is in the area of Process Integration /Process Orchestration. This functionality is for integration and interfacing with other SAP or non-SAP systems. This is a widely used functionality, but it is impossible to say how many SAP customers really use this functionality and have those Logical Filenames already created in their systems. Successful exploitation only works when the two needed Logical Filenames exist:
SXIVERI_TECH_ADAPTER_EXECUTE_OUT
SXIVERI_TECH_ADAPTER_EXECUTE_IN
After having created the two Logical Filenames (and) a PoC to inject OS commands works, for example, the command MKDIR, to create a directory!
On the OS the folder now exists:
Keep in mind: This is a blind OS command injection as no output is returned.
Further Exploitation
Just creating folders on the OS is not the most interesting way of exploiting an SAP system. The end goal often is to demonstrate business risks, and this is best done with a user with SAP_ALL rights in the application. This can be achieved by creating a user directly in the database for example, or by brute-forcing the passwords of other users in the system. For illustrative purposes, we will show how to do the latter by using OS command injection to run an SQL select statement to retrieve all the password hashes of the system. This can be done on any type of database; our example demonstrates this on a MaxDB database system. The command to use is shown here:
Since we cannot see the SQL results directly as this is a blind OS command injection, we wrote the output to the file “a.txt” on the remote OS. To retrieve the file, there are options like emailing it out or sending it via NetCat. In this example, we will copy it to a share we created on our local machine with a second call:
From our local machine, we can now open the password hashes retrieved:
Brute force them offline with, for example, Hashcat, for further post-exploitation scenarios.
Conclusion
It is quite rare to find a vulnerability in the Open Dataset Filter statement as it is rarely used within SAP ABAP code. The prerequisite of existing Logical Filenames and the needed authentication limits the usability, but we still believe that this is an interesting finding showing the need for SAP Security research.
Again, credits to Martin Ceronio for his SOLR ABAP indexer and the SAP Security team for fixing this vulnerability.
