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 database access.
Modern databases have comprehensive features to restrict the access a logged on user account has to database content and functionality. This is very helpful to e.g. prevent employees from accessing database tables related to administrative tasks.
However, an SAP application server ABAP as well as an S/4HANA, RISE or GROW installation is designed to access the database through a single user account. No matter which user is logged on to the SAP server and no matter what action is to be performed: all SQL commands are executed with the same database account.
What does that mean in the context of ABAP Malware?
If ABAP Malware is executed on any of the aforementioned SAP servers / installations, it automatically gains access to all data in the database to which the SAP server has access. Access means read arbitrary data, create arbitrary data, modify arbitrary data, delete arbitrary data, and modify (part of) the technical configuration of the database itself.
Let's more closely look into the consequences of such access.
Obviously this kind of access would give Malware full access to all business data on the affected server, such as HR data, accounting data, sales data, business partners, production data, bank data and even the company's IP. Not so obviously it would give Malware full access to user accounts and corresponding privileges. To technical logs and change documents. To the list of SAP systems the affected server has access to, including their hostname / IP address as well es information which of these connections can make use of stored credentials. And even less obviously, it would give Malware access to all ABAP code running on the SAP server, because all ABAP code - source code and byte code - is stored in the database.
Since ABAP has the potential to send arbitrary SQL commands to the database, also the technical configuration of the database can be modified by Malware. Commands like DROP TABLE or DROP DATABASE may be used for sabotage and commands like CREATE USER and GRANT may be used to gain additional access to the database.
This design decision from SAP cannot easily be changed. As a consequence, there is no way to restrict the degree of database access an ABAP Malware would gain, once it is executed on an SAP server based on ABAP.
To be continued...
This is the third 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.