In the previous blog entry, we described how to exploit an XSS vulnerability in SAP Afaria. Today’s post is dedicated to another security issue affecting Afaria.
( Read More: Checklist On Skillset Required For An Incident Management Person )
Control via SMS
As you know, Afaria allows a system administrator to control a device remotely. One of the ways how the administrator can manage devices is a text message. This feature is rather useful. Just imagine, an employee has left his mobile phone with all trade secrets in a bar after a corporate party. To prevent a data leakage, the administrator will send a special command to block the lost device.
Examples of administrative SMS commands:
WIPEALLDATA
WIPENITRODESK
WIPENITRODESKSDCARD
LOCKDEVICE
FETCHLOG
UNLOCKDEVICE
USERLOCK
REMEDIATE
NOTIFY
etc…
Obviously, this functionality is very powerful. To prevent the stuff’s mobile phones blocking when one receives a message like «LOCKDEVICE», an authentication is in place. To learn how it works, let’s look at the message used in SAP Afaria.
For example, a text message to block a user looks like this:
@#!Afaria64aACAhntVzjTIjhHDMGql8ldvc/8U6IlIoPU7aAOT8=$\$CMD:USERLOCK
It consists of several parts:
1) @#!Afaria — a signature that indicates that it is not just a message from his mom, but an administrative command;
2) 64aACAhntVzjTIjhHDMGql8ldvc/8U6IlIoPU7aAOT8= — a base64-encoded authentication string;
3) $\$CMD: — a signature that indicates that a command name comes next;
4) USERLOCK — a command that will run on the device if the authentication succeeds.
The authentication is the most interesting part for hackers. The signature uses an SHA256 hash composed from the following values:
+++$\$CMD:<cmd_name>
At first sight, it looks rather secure. To authenticate, one needs to know session, client, and server. So, the text message looks like this:
@#!Afaria+base64(sha256(<LastAdminSessionID>+<ClientID>+<TransmitterID>+$\$CMD:+<CMD_NAME>))+$\$CMD:+<CMD_NAME>
But don’t give up too soon. Here is how the client works:
If you look closer, you will notice that the client tries to compare two hashes, not one. The first one consists of all three parameters (IDs of session, client, and server), and the second one that is composed of two parameters (client ID twice and server ID). It turns out that you don’t need to know the session, and It facilitates an authentication bypass.
So, what about ClientID and TransmitterID? As for TransmitterID, we can obtain it anonymously by sending a connection request to the Afaria server, as the server retrieves the value as a response. Hackers only need to obtain ClientID to perform the attack.
Analysis of Afaria binary files showed that ClientID is generated on the basis of IMEI (International Mobile Equipment Identity). The only thing the hacker needs to direct the attack is someone’s phone number and IMEI.
How can one obtain IMEI? It is another task. Here are several ways to resolve it:
- Bruteforce attack. It makes sense as corporations often purchase phones in bulk, so IMEI numbers are sequential. it’s pretty easy to guess all IMEIs for phones belonging to a company if you know one.
- Traffic Interception. One can sniff traffic transmitted from third-party applications via insecure protocols. For example, map services send both phone and base station information to the server;
- Vulnerabilities in Afaria. For instance, an XSS described in the previous blog post;
- A number of different IMEI catchers and fake BTS.
It is recommended to install SAP Note 2155690 to fix this issue.
( Read More: 10 Questions To Ask Before You Start Your Bug Bounty Program… )
Wrap-up
You should not rely on security solutions completely and think that they are a panacea because they are supposed to have been written by more skilled programmers. Sometimes these products only worsen a situation and provide hackers one more entry point to your system.
Comments