SAP Afaria. Small SMS for hacking a large company
My name is Dmitry Chastukhin, and for a long time I have been working on information security of various software solutions for Enterprise. Basically, these are, of course, various SAP products (you can read my previous posts on this topic here , here or here ).
Today, we will look under the hood of SAP Afaria, an MDM solution from a famous German software giant. Sit back and sit back (please be careful if you are sitting on a chair).
It is quite interesting to do SAP security analysis for several reasons:
')
1) In the event of a successful compromise of the system, the attacker gets access to very critical information. Here you will have both personal data (buuee) and financial indicators, and bank data, and also other corporate secrets (who, where and for how many flies on business trips, for example) with links to other systems (“hello, SCADA!” )
2) Technology. Yes, SAP is trying to keep up with the times and use all the basic technologies in its products. Would you like to meet BigData? You are welcome! In memory database interested? Meet HANA ! Side server js? Here is your SAP XSJS . JS framework? Yes, take it .
So, SAP Afaria. Afaria is a Mobile Device Management (MDM) solution. For those who do not know what MDM is, I’ll briefly explain: MDM is a set of services that allows administrators in large companies to control mobile devices (smartphones, tablets and other phablets) of employees of this company, thereby ensuring the security of corporate data that is stored and processed on these devices. A special application is installed on the mobile device - MDM-client, which allows administrators to flexibly configure settings remotely.
MDM can: set up various kinds of policies on portable devices, find a phone (if it was lost by an employee), control the installation of applications, allow the use of the device only during working hours, block and even remotely erase all data. Very useful and interesting functionality, I must say.
Those. We will consider not just another corporate solution, but a solution that should (in theory) improve data security in the company.
Afaria has the typical functionality for MDM solutions, and works with all modern (and not so) mobile platforms:
1) Collects all possible information about the hardware part of the device;
2) Collects information about the activities on the device: calls, geolocation, work with applications, etc .;
3) Allows you to apply various configurations to the device: a password policy, a policy of using wireless networks, permission to access the camera, screenshots, etc.
The screenshot shows the incoming SMS information available to the SAP Afaria administrator
We take a quick look at the SAP Afaria architecture:
The architecture is not tricky: Device -> Relay server -> Afaria server.
A number of services are running on the server: web, DB, and several office services that process incoming connections from devices.
For data transfer, we use our own xnet protocol, as well as some http (s), SMS and push notification via Google Cloud Messaging / Apple Push Notification.
But let's look at the vulnerability .
1. overflow
This is strange, but anyone can easily do a DoS attack on Afaria servers, and lovers collect ROP chains and bypass the ASLR — even execute arbitrary code on the server. And all because one of the main services of Afaria - XcListener - "falls" from incoming packets with incorrect data and size.
A small example for which developers should be ashamed:
We found several places with overflow, all of them are currently covered with this sapnote .
But I must say, all this binary witchcraft in corporate systems is not very interesting, because it is difficult to operate (having to write a working exploit for a different fleet of server operating systems) and is rarely applicable (“dropping” an enterprise system during a penetration test is not a good practice ).
2. Various hardcoded values
SAP likes hardcoding various critical values ​​(proof: SAP Passwords ), and Afaria is no exception. For example, an account from the OS administrator in the configuration file:
Of course, it is encrypted. The encryption algorithm is quite secure, however, guess what's with the key? Bingo, he is also hardcoded in one of the Afaria services.
Thus, an attacker will not have to spend too much time on cryptography, because the keys are sewn and do not change:
The only thing that can confuse the attacker is a variety of secured keys and encryption algorithms.
Some encryption functions looked rather strange:
Such an approach to encrypting the offender, of course, at hand. Patches here .
3. Stored XSS
A little web. The main functionality available from the browser falls on the administrative part of SAP Afaria. Web admin panel is the very place where the system administrator can get a list of all connected devices, create new mobile device configurations, download applications, manage devices, etc.
Thus, the vulnerability in the admin panel is very likely to be critical both for the system as a whole and for the administrator in particular. Simple Afaria users, of course, do not have access to administrator functionality. However, it’s still possible to embed your data. To do this, let's take a look at how Afaria responds if we try to attach a new device to the server, without having the rights (and user account).
The following will turn out: the server, of course, will not allow to connect, however, in the admin panel in the list of devices (and I must say that this is the main administrator workspace), information about our device will appear with the note “Not approved”. Those. an attacker can easily insert some data anonymously directly into the admin area. Guess what field is possible JS-injection? Not? Anyway. The server does not filter before displaying data about the IMEI device.
It would seem a typical stored xss. However, its operation seemed slightly interesting, in view of the fact that the IMEI field has a length limited to 15 characters. However, nothing prevents us / the attacker from sending as many connection requests as the IMEI value, indicating only a part of the JS-payload and comment symbols. Thus, it is possible to assemble a full-featured JS script that would allow an attacker to do an Afaria admin session.
In the screenshot, the source code of the admin page with embedded JS through the IMEI device:
SAP patches are available here .
4. Control via SMS
Perhaps the most interesting part. As mentioned, Afaria allows the system administrator to control the device remotely. And one of the channels for the delivery of commands from the administrator is SMS. This is necessary, for example, in order to block the phone with corporate secrets that the employee left at the bar after corporate parties.
Examples of administrative SMS commands:
As you can see, this is a very evil functional. So that employees' phones are not blocked from any SMS with the text “LOCKDEVICE”, of course, authentication is provided. In order to understand how it works, let us consider the SMS message received by the client in more detail.
This is what an SMS to block a user looks like:
It consists of several parts:
1) @ #! Afaria is a signature that informs the client application that it is a control SMS from the administrator, and not just an SMS from the mother;
2) 64aACAhntVzjTIjhHDMGql8ldvc / 8U6IlIoPU7aAOT8 = - base64 authentication string;
3) $ \ $ CMD: - a signature explaining that the command name follows;
4) USERLOCK is the command that will be executed on the device if successful
authentication.
The most interesting part is, of course, authentication. Inside the base64 sha256 hash from the concatenation of the following parameters:
Today, we will look under the hood of SAP Afaria, an MDM solution from a famous German software giant. Sit back and sit back (please be careful if you are sitting on a chair).
It is quite interesting to do SAP security analysis for several reasons:
')
1) In the event of a successful compromise of the system, the attacker gets access to very critical information. Here you will have both personal data (buuee) and financial indicators, and bank data, and also other corporate secrets (who, where and for how many flies on business trips, for example) with links to other systems (“hello, SCADA!” )
2) Technology. Yes, SAP is trying to keep up with the times and use all the basic technologies in its products. Would you like to meet BigData? You are welcome! In memory database interested? Meet HANA ! Side server js? Here is your SAP XSJS . JS framework? Yes, take it .
So, SAP Afaria. Afaria is a Mobile Device Management (MDM) solution. For those who do not know what MDM is, I’ll briefly explain: MDM is a set of services that allows administrators in large companies to control mobile devices (smartphones, tablets and other phablets) of employees of this company, thereby ensuring the security of corporate data that is stored and processed on these devices. A special application is installed on the mobile device - MDM-client, which allows administrators to flexibly configure settings remotely.
MDM can: set up various kinds of policies on portable devices, find a phone (if it was lost by an employee), control the installation of applications, allow the use of the device only during working hours, block and even remotely erase all data. Very useful and interesting functionality, I must say.
Those. We will consider not just another corporate solution, but a solution that should (in theory) improve data security in the company.
Afaria has the typical functionality for MDM solutions, and works with all modern (and not so) mobile platforms:
1) Collects all possible information about the hardware part of the device;
2) Collects information about the activities on the device: calls, geolocation, work with applications, etc .;
3) Allows you to apply various configurations to the device: a password policy, a policy of using wireless networks, permission to access the camera, screenshots, etc.
The screenshot shows the incoming SMS information available to the SAP Afaria administrator
We take a quick look at the SAP Afaria architecture:
The architecture is not tricky: Device -> Relay server -> Afaria server.
A number of services are running on the server: web, DB, and several office services that process incoming connections from devices.
For data transfer, we use our own xnet protocol, as well as some http (s), SMS and push notification via Google Cloud Messaging / Apple Push Notification.
But let's look at the vulnerability .
1. overflow
This is strange, but anyone can easily do a DoS attack on Afaria servers, and lovers collect ROP chains and bypass the ASLR — even execute arbitrary code on the server. And all because one of the main services of Afaria - XcListener - "falls" from incoming packets with incorrect data and size.
A small example for which developers should be ashamed:
import socket HOST = 'hostname' PORT = 3005 s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.connect((HOST, PORT)) poc = 'A'*4098 s.send(poc) data = s.recv(10000) s.close() print 'Received', (data) We found several places with overflow, all of them are currently covered with this sapnote .
But I must say, all this binary witchcraft in corporate systems is not very interesting, because it is difficult to operate (having to write a working exploit for a different fleet of server operating systems) and is rarely applicable (“dropping” an enterprise system during a penetration test is not a good practice ).
2. Various hardcoded values
SAP likes hardcoding various critical values ​​(proof: SAP Passwords ), and Afaria is no exception. For example, an account from the OS administrator in the configuration file:
Of course, it is encrypted. The encryption algorithm is quite secure, however, guess what's with the key? Bingo, he is also hardcoded in one of the Afaria services.
Thus, an attacker will not have to spend too much time on cryptography, because the keys are sewn and do not change:
The only thing that can confuse the attacker is a variety of secured keys and encryption algorithms.
Some encryption functions looked rather strange:
Such an approach to encrypting the offender, of course, at hand. Patches here .
3. Stored XSS
A little web. The main functionality available from the browser falls on the administrative part of SAP Afaria. Web admin panel is the very place where the system administrator can get a list of all connected devices, create new mobile device configurations, download applications, manage devices, etc.
Thus, the vulnerability in the admin panel is very likely to be critical both for the system as a whole and for the administrator in particular. Simple Afaria users, of course, do not have access to administrator functionality. However, it’s still possible to embed your data. To do this, let's take a look at how Afaria responds if we try to attach a new device to the server, without having the rights (and user account).
The following will turn out: the server, of course, will not allow to connect, however, in the admin panel in the list of devices (and I must say that this is the main administrator workspace), information about our device will appear with the note “Not approved”. Those. an attacker can easily insert some data anonymously directly into the admin area. Guess what field is possible JS-injection? Not? Anyway. The server does not filter before displaying data about the IMEI device.
It would seem a typical stored xss. However, its operation seemed slightly interesting, in view of the fact that the IMEI field has a length limited to 15 characters. However, nothing prevents us / the attacker from sending as many connection requests as the IMEI value, indicating only a part of the JS-payload and comment symbols. Thus, it is possible to assemble a full-featured JS script that would allow an attacker to do an Afaria admin session.
In the screenshot, the source code of the admin page with embedded JS through the IMEI device:
SAP patches are available here .
4. Control via SMS
Perhaps the most interesting part. As mentioned, Afaria allows the system administrator to control the device remotely. And one of the channels for the delivery of commands from the administrator is SMS. This is necessary, for example, in order to block the phone with corporate secrets that the employee left at the bar after corporate parties.
Examples of administrative SMS commands:
WIPEALLDATA WIPENITRODESK WIPENITRODESKSDCARD Lockdevice FETCHLOG UNLOCKDEVICE USERLOCK REMEDIATE NOTIFY etc ...
As you can see, this is a very evil functional. So that employees' phones are not blocked from any SMS with the text “LOCKDEVICE”, of course, authentication is provided. In order to understand how it works, let us consider the SMS message received by the client in more detail.
This is what an SMS to block a user looks like:
@#!Afaria64aACAhntVzjTIjhHDMGql8ldvc/8U6IlIoPU7aAOT8=$\$CMD:USERLOCK
It consists of several parts:
1) @ #! Afaria is a signature that informs the client application that it is a control SMS from the administrator, and not just an SMS from the mother;
2) 64aACAhntVzjTIjhHDMGql8ldvc / 8U6IlIoPU7aAOT8 = - base64 authentication string;
3) $ \ $ CMD: - a signature explaining that the command name follows;
4) USERLOCK is the command that will be executed on the device if successful
authentication.
The most interesting part is, of course, authentication. Inside the base64 sha256 hash from the concatenation of the following parameters:
+++$\$CMD:<CMD_NAME>
$\$CMD: <CMD_NAME> , :
1) -
2) -
3) -
. , . SMS :
@#!Afaria+base64(sha256(+++$\$CMD:+<CMD_NAME>))+$\$CMD:+<CMD_NAME>
:
, , SMS, ! - (ID , ), - (ID ID ). , , .
ClientID TransmitterID. TransmitterID , , Afaria. ClientID.
Afaria , ClientID IMEI . , , , CEO - , IMEI .
IMEI? , , . :
1) . , . , IMEI, ;
2) , . , , . ;
3) Afaria. , XSS;
4) IMEI catcher .
- , , , . "" , .
, . , .
: SAP Afaria Security. One SMS to hack a companySource: https://habr.com/ru/post/267907/
All Articles