SAP SDM. 6 letters - many problems
There are many ways to compromise an SAP ERP system. This is not surprising, because the SAP installation is a huge number of different modules written in different programming languages ​​and accessible to the user using a wide variety of protocols: from classic HTTP to proprietary DIAG.
As a result, every month SAP AG issues security patches covering the “holes” in the ERP system, and information security experts receive thanks on the official resource of the developer company (a trifle, but nice).
We will not go into details and find out why and why someone is trying to compromise the ERP system. The times of the site defaces just passed away for the sake of fun, the terms “cyberkraim”, “targeted attacks” and other APT are widely heard in the industry. Why break the website of an online store, whose security the owners probably care about, if you can immediately (under certain conditions, of course) attack an ERP system that is less secure but also stores and processes the most critical data?
And now, finally, after several introductory "blah blah", let's move on to how you can compromise the SAP system.
In today's article we will analyze a slightly exotic way. Let's try to test the strength of the sphere where the attacker is not expected - the application development infrastructure.
')
We will attack SAP NetWeaver Deployment Infrastructure, namely Software Deployment Manager (SDM).
As you can see in the diagram, the application development infrastructure for the SAP system consists of many different services:
Design Time Repository (DTR) - Repository
Component Build Service (CBS) - responsible for JDI configuration and administration of the terrain
Change Management Service (CMS) - used to track the versioning of deployed applications on different servers
Software Landscape Directory (SLD) / NS - The Name Server is responsible for the uniqueness of object names. SLD allows you to manage existing system components.
The Developer Studio - SAP's development environment based on Eclipse
All this is quite ordinary services used for development. However, it is worth mentioning separately the key component for us (and for the attacker), which gives direct access to the ERP system, - Software Deployment Manager (SDM).
SDM is a service with which developers deploy applications and services to a Java Application Server. Actually, it allows you to download and run Java applications on the application server (* .ear, * .war, * sda).
So, the idea for the attack is simple:
1) find the SDM
2) compromise SDM
3) using SDM, deploy the shell
4) having access to the server OS of the SAP system, it is easy to access the data processed in it
Let's start.
Meeting an SDM service in a typical SAP landscape is not so difficult. Just look for the ports:
5NN17 - Admin Port
5NN18 - GUI Port
where NN is the SAP instance number.
We are more interested in port 518, since it provides interfaces for downloading applets, while the administrative port is designed to stop, restart, or start SDM services, for example, by sending the following packet to port 517:
Yes, yes, just like that, without authentication, you can disable the deploing service. But it is boring and unproductive. Let's return to port 518.
Using an SDM client (a standard client written in Java) and connecting to port 5NN18, the attacker will see a dialog box asking for authorization.
What do you think, where is the attacker to get these same login and password?
Actually, everything is simple with login. Username is standard - admin. The problem with the password. Going through is not the best idea, because after 3 unsuccessful attempts to enter the password, the SDM services stop (hello, another DoS).
Let's see: how does authentication work?
And it works as follows:
1) user enters password
2) the client considers the password hash entered
3) client sends password hash to server
4) the server compares the resulting hash with the hash from the config file
5) if everything is OK, then the user gets access to the SDM
It turns out that an attacker does not need to know the password, it’s enough to know the hash and send it to the server. As we know, the hash is stored on the server in the config file:
.. \ SDM \ program \ config \ sdmrepository.sdc
Before an attacker, a new task: read the sdmrepository.sdc config and thus learn the administrator password hash, then use it to authenticate with the SDM server.
Well, vulnerabilities in the SAP system that allow a remote attacker to read a file without authentication data are enough. It might look like this:
1) RCE via the CTC servlet (notes 1467771, 1445998)
2) many different XXE vulnerabilities (note 1619539)
3) directory overlap vulnerabilities (note 1630293)
4) anonymous reading of files using the SAP MMC function (notes 927637, 1439348)
Consider in this article another way to read files from the SAP server (of course, without authentication).
There is a service such as SAP Log Viewer. As the name implies, it is intended for viewing SAP-system log files. Through the Log Viewer you can view the contents of the log file both on the local system and on the remote one - the main thing is to open one of these ports of the Log Viewer server: 26000 (NI), 1099 (RMI), 5465 (Socket).
Well, then everything is simple and clear (except for one thing, why SAP does not authenticate the user on the Log Viewer server):
1) connect to the Log Viewer server
2) register the sdmrepository.sdc file as a log file
3) read it successfully
Having an SDM administrator password hash in your hands, it remains only to use it for authentication. To do this, you can:
1) write your SDM client
2) modify the standard client (the benefit of Java allows you to do this)
3) replace the hash value before sending it to the server using a proxy
I chose the third option as the most simple.
As a result, we get access to the SDM server with administrator rights. SDM server is compromised.
At this stage, the attacker has a wide range of possibilities. The most interesting:
1) modify the existing program by introducing a backdoor, for example, or by changing the logic of its work
2) access the SAP server OS by uploading the simplest JSP shell to the application server
It is usually difficult for an attacker to grasp the company's business processes, so he has a strong desire to gain access to the database and, as a result, to all critical data.
Having access to the operating system on which SAP runs, it is very easy to get access to the database by logging in as user sysdba, for which an attacker needs to execute the command (in the case of using Oracle as a DBMS):
sqlplus / as sysdba
As a result, the attacker gets access to all the critical data used in the company:
It would seem that something else to discuss - the attacker achieved his goal. However, at this stage the most interesting can begin. For example, an attacker may try to compromise neighboring SAP systems, for example, using trusted RFC connections, but this topic is beyond the scope of this article.
To summarize, I want to re-write the well-known phrase: security is a complex thing. It is impossible to protect one system without protecting neighboring ones. The attacker will always try to attack where you least expect it, so be prepared for this.
As a result, every month SAP AG issues security patches covering the “holes” in the ERP system, and information security experts receive thanks on the official resource of the developer company (a trifle, but nice).
We will not go into details and find out why and why someone is trying to compromise the ERP system. The times of the site defaces just passed away for the sake of fun, the terms “cyberkraim”, “targeted attacks” and other APT are widely heard in the industry. Why break the website of an online store, whose security the owners probably care about, if you can immediately (under certain conditions, of course) attack an ERP system that is less secure but also stores and processes the most critical data?
And now, finally, after several introductory "blah blah", let's move on to how you can compromise the SAP system.
In today's article we will analyze a slightly exotic way. Let's try to test the strength of the sphere where the attacker is not expected - the application development infrastructure.
')
We will attack SAP NetWeaver Deployment Infrastructure, namely Software Deployment Manager (SDM).
As you can see in the diagram, the application development infrastructure for the SAP system consists of many different services:
Design Time Repository (DTR) - Repository
Component Build Service (CBS) - responsible for JDI configuration and administration of the terrain
Change Management Service (CMS) - used to track the versioning of deployed applications on different servers
Software Landscape Directory (SLD) / NS - The Name Server is responsible for the uniqueness of object names. SLD allows you to manage existing system components.
The Developer Studio - SAP's development environment based on Eclipse
All this is quite ordinary services used for development. However, it is worth mentioning separately the key component for us (and for the attacker), which gives direct access to the ERP system, - Software Deployment Manager (SDM).
SDM is a service with which developers deploy applications and services to a Java Application Server. Actually, it allows you to download and run Java applications on the application server (* .ear, * .war, * sda).
So, the idea for the attack is simple:
1) find the SDM
2) compromise SDM
3) using SDM, deploy the shell
4) having access to the server OS of the SAP system, it is easy to access the data processed in it
Let's start.
1. Find the SDM service
Meeting an SDM service in a typical SAP landscape is not so difficult. Just look for the ports:
5NN17 - Admin Port
5NN18 - GUI Port
where NN is the SAP instance number.
We are more interested in port 518, since it provides interfaces for downloading applets, while the administrative port is designed to stop, restart, or start SDM services, for example, by sending the following packet to port 517:
[10 spaces]56<?xml version="1.0"?> <ShutDownRequest></ShutDownRequest> Yes, yes, just like that, without authentication, you can disable the deploing service. But it is boring and unproductive. Let's return to port 518.
Using an SDM client (a standard client written in Java) and connecting to port 5NN18, the attacker will see a dialog box asking for authorization.
What do you think, where is the attacker to get these same login and password?
2. We compromise SDM
Actually, everything is simple with login. Username is standard - admin. The problem with the password. Going through is not the best idea, because after 3 unsuccessful attempts to enter the password, the SDM services stop (hello, another DoS).
Let's see: how does authentication work?
And it works as follows:
1) user enters password
2) the client considers the password hash entered
3) client sends password hash to server
4) the server compares the resulting hash with the hash from the config file
5) if everything is OK, then the user gets access to the SDM
It turns out that an attacker does not need to know the password, it’s enough to know the hash and send it to the server. As we know, the hash is stored on the server in the config file:
.. \ SDM \ program \ config \ sdmrepository.sdc
Before an attacker, a new task: read the sdmrepository.sdc config and thus learn the administrator password hash, then use it to authenticate with the SDM server.
Well, vulnerabilities in the SAP system that allow a remote attacker to read a file without authentication data are enough. It might look like this:
1) RCE via the CTC servlet (notes 1467771, 1445998)
2) many different XXE vulnerabilities (note 1619539)
3) directory overlap vulnerabilities (note 1630293)
4) anonymous reading of files using the SAP MMC function (notes 927637, 1439348)
Consider in this article another way to read files from the SAP server (of course, without authentication).
There is a service such as SAP Log Viewer. As the name implies, it is intended for viewing SAP-system log files. Through the Log Viewer you can view the contents of the log file both on the local system and on the remote one - the main thing is to open one of these ports of the Log Viewer server: 26000 (NI), 1099 (RMI), 5465 (Socket).
Well, then everything is simple and clear (except for one thing, why SAP does not authenticate the user on the Log Viewer server):
1) connect to the Log Viewer server
2) register the sdmrepository.sdc file as a log file
3) read it successfully
Having an SDM administrator password hash in your hands, it remains only to use it for authentication. To do this, you can:
1) write your SDM client
2) modify the standard client (the benefit of Java allows you to do this)
3) replace the hash value before sending it to the server using a proxy
I chose the third option as the most simple.
As a result, we get access to the SDM server with administrator rights. SDM server is compromised.
3. Using SDM, deploy the shell
At this stage, the attacker has a wide range of possibilities. The most interesting:
1) modify the existing program by introducing a backdoor, for example, or by changing the logic of its work
2) access the SAP server OS by uploading the simplest JSP shell to the application server
It is usually difficult for an attacker to grasp the company's business processes, so he has a strong desire to gain access to the database and, as a result, to all critical data.
4. We get access to the database
Having access to the operating system on which SAP runs, it is very easy to get access to the database by logging in as user sysdba, for which an attacker needs to execute the command (in the case of using Oracle as a DBMS):
sqlplus / as sysdba
As a result, the attacker gets access to all the critical data used in the company:
findings
It would seem that something else to discuss - the attacker achieved his goal. However, at this stage the most interesting can begin. For example, an attacker may try to compromise neighboring SAP systems, for example, using trusted RFC connections, but this topic is beyond the scope of this article.
To summarize, I want to re-write the well-known phrase: security is a complex thing. It is impossible to protect one system without protecting neighboring ones. The attacker will always try to attack where you least expect it, so be prepared for this.
Source: https://habr.com/ru/post/235203/
All Articles