In the past, SAP made some decisions in the architecture of its solutions that may be important for reliably running them, but that have severe adverse impact on security. In this episode we focus on access to the operating system of an SAP server.
An SAP server (AS ABAP, S/4HANA, RISE or GROW installation) is composed of multiple binaries that run on the operating system and provide the runtime environment for all ABAP programs. These binaries bestow ABAP with the ability to interact with the operating system. In order to perform these interactions, SAP decided that the binaries run with the privileges of a special user account, called SIDADM. No matter which user is logged on to the SAP server and no matter what action is to be performed on the operating system and/or file system: all commands are executed with the same user account on the operating system. This is similar to the design of SAP's database access (see episode 1 ).
This means that all actions that need to be performed on the operating system and/or file system will be executed over a single user account. As a result, any ABAP Malware running on the SAP server can perform all the OS interactions as the SAP standard installation.
In order to assess the criticality of this feature, we need to take a closer look at the extent of this access.
First of all, ABAP has built-in commands to read and write files on the SAP server. While there are typically SAP transports (code packages), configuration files and SAP log entries on the file system, many companies additionally use their file system in order to (temporarily) store/exchange business documents from external (non-SAP) sources. Malware could access all of these.
However, this is just a minor cause of concern, since ABAP also has the technical capability of executing arbitrary commands on the operating system. This feature will allow ABAP Malware to e.g. download files from the Internet, create and execute binary files on the operating system, create a reverse shell, and to destroy critical files or directories. With these built-in capabilities, an ABAP Malware could easily spread to the operating systems of all affected SAP servers.
While SAP has built several mechanisms to restrict file access and OS command execution from ABAP, these measures are by far not solid enough to prevent a skilled attacker from bypassing them. As a consequence, there is effectively no way to restrict the degree of OS access an ABAP Malware would gain, once it is executed on an SAP server based on ABAP.
To be continued...
This is the fourth article in our malware series that provides you with insights into ABAP malware research, ABAP malware capabilities and ABAP malware defensive strategies.
If you'd like to know more about ABAP malware risks, please contact us.