September 2, 2014 at 13:11SAP SDM. 6 letters - a lot of 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 available to the user using a variety of protocols: from classic HTTP to proprietary DIAG.
As a result, every month SAP AG issues security patches that cover “holes” in the ERP system, and information security experts receive thanks on the official resource of the developer (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 website deface just for fun have passed; in the industry, everyone has heard the terms cybercrime, targeted attacks, and other APTs. Why break the website of an online store, the owners are surely concerned about their security, if you can immediately (under certain conditions, of course) attack an ERP system that is less secure, but at the same time stores and processes the most critical data?
And now, finally, after a few introductory “blah blah”, let's move on to how you can compromise the SAP system.
In today's article, we’ll take a look at a slightly exotic way. Let's try to check the strength of the area where the attacker is not expected - 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) -
Component Build Service (CBS) repository - responsible for JDI configuration and transport landscape administration
Change Management Service (CMS) - used to tracking versioning of deployed applications on various
Software Landscape Directory (SLD) / NS servers - Name Server is responsible for the uniqueness of object names. SLD allows you to manage existing system components.
The Developer Studio - Eclipse-based SAP's development environment
All these are quite ordinary services used for development. However, it is worth mentioning separately about the key component for us (and for the attacker) that gives direct access to the ERP system - Software Deployment Manager (SDM).
SDM is a service through which developers deploy applications and services to the Java Application Server. Actually, it allows you to download and run Java applications (* .ear, * .war, * sda) on the application server.
So, the idea for the attack is simple:
1) we find SDM
2) we compromise SDM
3) using SDM, deploy shell
4) having access to the server OS of the SAP system, it’s easy to get access to the data processed in it
. Let's start.
Meeting an SDM service in a typical SAP landscape is not so difficult. It is enough to search for the ports:
5NN17 - Admin Port
5NN18 - GUI Port
where NN is the number of the SAP instance.
We are more interested in port 518, since it provides interfaces for loading 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, it’s so simple, without authentication, you can disable the deployment service. But it is boring and unproductive. Let's return to port 518.
Using the SDM client (the standard client is written in Java) and connecting to port 5NN18, the attacker will see a dialog box asking you to log in.
Where do you think the attacker can get these usernames and passwords?
Actually, with login everything is simple. The default username is admin. The problem with the password. Sorting is not a good idea, because after 3 unsuccessful attempts to enter a password, SDM services stop (hi, one more DoS).
Let's see: how does authentication work?
And it works as follows:
1) the user enters the password
2) the client considers the hash of the entered password
3) the client sends the password hash to the server
4) the server compares the received hash with the hash from the config file
5) if everything is OK, the user gets access to the SDM
It turns out that the attacker does not have to know the password, just find 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
The attacker has a new task: read the sdmrepository.sdc config and thus find out the hash of the administrator password, and then use it for authentication in the SDM server.
Well, vulnerabilities in the SAP system that allow a remote attacker to read a file without authentication data are enough. It may look like this:
1) RCE via the CTC servlet (notes 1467771, 1445998)
2) many different XXE vulnerabilities (note 1619539)
3) directory out-of-directory 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 an SAP server (naturally, without authentication).
There is a service like SAP Log Viewer. As the name implies, it is intended for viewing the log files of SAP systems. 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 that one of these ports of the Log Viewer server be opened: 26000 (NI), 1099 (RMI), 5465 (Socket).
Well, then everything is simple and clear (except for one point, why does SAP 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) we read it successfully
Having on hand SDM password hash of the administrator, 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 this)
3) replace the hash value before sending it to the server using a proxy
I chose the third option as the simplest.
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 operation
2) gain access to the OS of the SAP server by downloading the simplest JSP shell to the application server It
is usually difficult for an attacker to penetrate into the company's business processes, therefore 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 is running, it is very easy to access the database by logging in as sysdba, for which the attacker just needs to run the command (if using Oracle as a DBMS):
sqlplus / as sysdba
As a result, the attacker gains access to all critical data used by the company:
It would seem, what else to discuss - the attacker achieved his goal. However, at this stage, the fun part may 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 famous phrase: security is a complex thing. You cannot protect one system without protecting the neighboring ones. An 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 that cover “holes” in the ERP system, and information security experts receive thanks on the official resource of the developer (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 website deface just for fun have passed; in the industry, everyone has heard the terms cybercrime, targeted attacks, and other APTs. Why break the website of an online store, the owners are surely concerned about their security, if you can immediately (under certain conditions, of course) attack an ERP system that is less secure, but at the same time stores and processes the most critical data?
And now, finally, after a few introductory “blah blah”, let's move on to how you can compromise the SAP system.
In today's article, we’ll take a look at a slightly exotic way. Let's try to check the strength of the area where the attacker is not expected - 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) -
Component Build Service (CBS) repository - responsible for JDI configuration and transport landscape administration
Change Management Service (CMS) - used to tracking versioning of deployed applications on various
Software Landscape Directory (SLD) / NS servers - Name Server is responsible for the uniqueness of object names. SLD allows you to manage existing system components.
The Developer Studio - Eclipse-based SAP's development environment
All these are quite ordinary services used for development. However, it is worth mentioning separately about the key component for us (and for the attacker) that gives direct access to the ERP system - Software Deployment Manager (SDM).
SDM is a service through which developers deploy applications and services to the Java Application Server. Actually, it allows you to download and run Java applications (* .ear, * .war, * sda) on the application server.
So, the idea for the attack is simple:
1) we find SDM
2) we compromise SDM
3) using SDM, deploy shell
4) having access to the server OS of the SAP system, it’s easy to get access to 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. It is enough to search for the ports:
5NN17 - Admin Port
5NN18 - GUI Port
where NN is the number of the SAP instance.
We are more interested in port 518, since it provides interfaces for loading 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 Yes, yes, it’s so simple, without authentication, you can disable the deployment service. But it is boring and unproductive. Let's return to port 518.
Using the SDM client (the standard client is written in Java) and connecting to port 5NN18, the attacker will see a dialog box asking you to log in.
Where do you think the attacker can get these usernames and passwords?
2. Compromising SDM
Actually, with login everything is simple. The default username is admin. The problem with the password. Sorting is not a good idea, because after 3 unsuccessful attempts to enter a password, SDM services stop (hi, one more DoS).
Let's see: how does authentication work?
And it works as follows:
1) the user enters the password
2) the client considers the hash of the entered password
3) the client sends the password hash to the server
4) the server compares the received hash with the hash from the config file
5) if everything is OK, the user gets access to the SDM
It turns out that the attacker does not have to know the password, just find 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
The attacker has a new task: read the sdmrepository.sdc config and thus find out the hash of the administrator password, and then use it for authentication in the SDM server.
Well, vulnerabilities in the SAP system that allow a remote attacker to read a file without authentication data are enough. It may look like this:
1) RCE via the CTC servlet (notes 1467771, 1445998)
2) many different XXE vulnerabilities (note 1619539)
3) directory out-of-directory 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 an SAP server (naturally, without authentication).
There is a service like SAP Log Viewer. As the name implies, it is intended for viewing the log files of SAP systems. 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 that one of these ports of the Log Viewer server be opened: 26000 (NI), 1099 (RMI), 5465 (Socket).
Well, then everything is simple and clear (except for one point, why does SAP 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) we read it successfully
Having on hand SDM password hash of the administrator, 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 this)
3) replace the hash value before sending it to the server using a proxy
I chose the third option as the simplest.
As a result, we get access to the SDM server with administrator rights. SDM server is compromised.
3. Using SDM, deploy 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 operation
2) gain access to the OS of the SAP server by downloading the simplest JSP shell to the application server It
is usually difficult for an attacker to penetrate into the company's business processes, therefore he has a strong desire to gain access to the database and, as a result, to all critical data.
4. Get access to the database
Having access to the operating system on which SAP is running, it is very easy to access the database by logging in as sysdba, for which the attacker just needs to run the command (if using Oracle as a DBMS):
sqlplus / as sysdba
As a result, the attacker gains access to all critical data used by the company:
conclusions
It would seem, what else to discuss - the attacker achieved his goal. However, at this stage, the fun part may 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 famous phrase: security is a complex thing. You cannot protect one system without protecting the neighboring ones. An attacker will always try to attack where you least expect it, so be prepared for this.