It is known that the BYOD trend is changing the way enterprises are managed, delivered, and, most importantly, secured. While BYOD has its benefits, such as increased productivity, it poses security risks to the organization because of connections with the corporate network and access to corporate data. To minimize the threats, businesses should adopt BYOD policies and somehow manage devices synced with the enterprise. Turnkey solutions are available both to manage and secure devices in a corporate environment. We call these MDM (Mobile Device Management) solutions.

However, while initially MDM solutions are introduced to enhance the security of the system, sometimes they can put organizations at risk which can be even stricter than without those solutions. But first things first.

SAP Afaria Introduction

SAP Afaria is developed by the German-based software vendor. It is the most common MDM solution and the leader in 2014 Enterprise Mobility Management, Forrester Wave. Managing more than 6300 enterprise customers and more than 130 million mobile devices, Afaria customers include both private sector and government entities, such as the US Census Bureau.

SAP Afaria began in 1997 when they released several solution versions. The first one, called SessionXpress, was released in February 1997; and only Version 3.5 (May 2000) was named Afaria. Then SAP acquired Afaria, and Version 7.0 which was released in April 2012 became SAP Afaria. The last version so far 7.0 SP7 was released in October 2015.

SAP Afaria Architecture

Now, let's define the most important terms. The other details on SAP Afaria you can find in this article.

Afaria Server – This server-based solution supports a single server or a server farm. It communicates with the Afaria database, Administrator, the Over-the-Air (OTA) Deployment center, the relay server, and clients. This is the center of all Afaria activity.

Afaria Administrator – This is a web app to provide a server interface. The Afaria Administrator will define the server administration and access policies for the Afaria Administrator users. It will also create and manage clients, review system activity and communicate with other Afaria servers.

Clients — Afaria Clients are the users' devices. These include a wide range, such as laptops, phablets, and phones that run Afaria Client software. Servers can manage the Clients, deliver Client updates, and collect data from the Client.

Relay server is a secure, load-balance proxy server that relays communication between mobile devices and one or more Sybase server-based products.

Afaria DB server is a database server that contains Afaria database.

SAP Afaria vulnerabilities

SAP Afaria has some publicly known vulnerabilities. While the total number of those vulnerabilities is relatively small, most of the identified vulnerabilities may be used to access the system and perform espionage, sabotage and fraudulent actions. DoS, Buffer Overflow, and Auth Bypass are the most common vulnerabilities in SAP Afaria.

The average CVSS score for SAP Afaria vulnerabilities is 7.2. The highest CVSS base score for an SAP Afaria vulnerability is 9.4.

It was a brief introduction to SAP Afaria security, just to provide the basics. Now let's talk about SAP Afaria vulnerabilities in particular and how to exploit them.

XCListener vulnerabilities in SAP Afaria

There is a service that connects devices to the Afaria server directly. The connection is made via an open port 3005 and 3007. XCListener is responsible for port 3005. Windows Mobile and Windows client's XcListener do not provide proper authorization checks. This can result in undesired behavior.

An attacker can send a packet to this port with value "Run Channel" and there is no authorization check for it. Although this vulnerability is not so dangerous in itself, some versions have a buffer overflow vulnerability in this service in certain landscape configurations. To exploit this vulnerability, you need to send the following packet:

<AfariaNotify version="1.0.0">

<Message type="Command" value="Run Channel" >

<Client name="LOCALHOST" >

<Client name="LOCALHOST" GUID="59146189-1f92-

46d5-85aa-6293631d5d2e">

<Transmitter address="172.16.2.67:4444">

<Channel address="172.16.2.67:4444asd"

name="172.16.2.67:4444(A*1491)">

</Channel>

</Transmitter>

</Client>

</Message>

</AfariaNotify>(A*3678)

This command will result in a Denial of Service attack.

The Windows client enrollment policy allows administrators to enable/disable XCListener with the advanced option "Outbound listener and firewall." If port 3005 is not exposed externally, the vulnerability is only exploitable locally.

XCListener plays a vital role in SAP Afaria Security, as it's a management interface that can execute many critical commands and has some vulnerabilities.

We recommend to Install SAP Notes 2134905 and 2153690 to fix the issue.

XSS vulnerability in SAP Afaria

The administrative part of SAP Afaria is where the basic functionality resides. It is available through a browser. The Web administrative console allows the system administrator to view all the connected devices, create new configurations for mobile devices, download apps, and control the devices.

So, an XSS vulnerability in the administrative console is likely to be critical for the entire system and for the administrator in particular. XSS Vulnerabilities in SAP Applications are the most common issues according to the latest review of 3000 vulnerabilities in SAP Systems, and we have published a detailed guide how to protect SAP from XSS vulnerabilities. It came as no surprise that SAP Afaria is also vulnerable.

Let's examine what will happen if we try to connect a new device to the server without proper rights (and account).

That's what we get (see the screenshot): the server prevents us from connecting to the device. However, notice that the list of devices in the administrative console does show information about the device. See how it is marked as "Not approved." This means that an attacker can inject data into the administrative console while being anonymous. What field, do you think, a JS injection is possible? Notice the server isn't filtering information before displaying the IMEI!

The stored XSS looks normal. However, this exploit is interesting due to the length of the IMEI field. It is restricted to fifteen characters, which makes it harder to inject malicious code. That does not mean, though, that attackers could not send several connections requests with only part of the JS payload and comments.

Let's assume the attackers want to inject this JS code:

1

2 <script>alert('Hello Afaria! U so secure!');</script>

3

To do so, they have to send a request to the server with the following values in the IMEI field:

2. <script>
3. /*zzzzzz
4. */a00="alert";/*
5. */a01="('Hel";/*
6. */a02="lo Af";/*
7. */a03="aria!";/*
8. */a04=" U so";/*
9. */a05=" secu";/*
10. */a06="re!')";/*
11. */a07=";";/*zzzz
12. */zzz=a00+a01+/*
13. */a02+a03+a04+/*
14. */a05+a06+a07+/*
15. */'';/*zzzzzzzzz
16. */eval(zzz);/*zz
17. zzzzz*/
18. </script>

Notice that there are special characters /**/ in every query. They mark comments in JS. This way, unnecessary parts of HTML markup that prevent getting the final result are deleted.

The final result is that the web server will build a web page in the admin panel in which all the little pieces will be brought together into one JS script to be executed during an administrator's session. This permits the attacker to obtain data from the Afaria administrative panel and to control all the devices that are connected to the server.

The screenshot below shows the administrative console's source code with JS code injected into the device IMEI field:

Stored XSS vulnerability: Wrap-up

The Stored XSS vulnerability was closed by SAP, you should install SAP Security Note 2152669 to fix the issue.

This is an extremely critical issue. It is vulnerable to remote exploitation and does not require authentication. There are at least one hundred forty servers available to attackers on the Internet for this purpose.

The attacker can gain complete control over all mobile devices of organization and wipe data, lock all smartphones, force them to install a malicious backdoor. This can control the user's data and send important documents to the Command and Control server. It can also spy on users, read internal messages and record video from connected cameras.

More importantly, if the attacker controls an employee's device, it is not only the MDM solution that is vulnerable. Any business application that is highly-connected (think ERP, CRM, HR, and BI) can allow the attacker to escalate network privileges. Then the attacker has access to private corporate systems where mission-critical data is stored.

Remote control via text message

Now, let's look at another security issue affecting Afaria - Control via text message.

As you remember, 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 can 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 from blocking when one receives a message like «LOCKDEVICE», an authentication is in place. To learn how the authentication 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 the 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:

<LastAdminSessionID>+<ClientID>+<TransmitterID>+$$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 is composed of two of the parameters (client ID twice and server ID). It turns out that you don't need to know the session that 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:

1. 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.
2. Traffic Interception. One can sniff traffic transmitted from third-party applications via insecure protocols.
3. For example, map services send both phone and base station information to the server;
4. Vulnerabilities in Afaria. For instance, an XSS Vulnerability described in the article;
5. A number of different IMEI catchers (http://www.septier.com/368.html) and fake BTS.

This bug was discovered by ERPScan researcher Dimitry Chastuhin. To fix this issue, it is recommended to install SAP Security Note 2155690  https://service.sap.com/sap/support/notes/2155690 provided by SAP.

Securing SAP Afaria from remote Cyber Attacks

You should not rely on security solutions completely and think that they are a panacea because they are supposed to deliver security. Sometimes these products only worsen a situation and provide hackers one more entry point to your system. SAP publishes patches for all reported vulnerabilities; it's necessary for administrators to implement them in time.

Because it is easy to find SAP Afaria servers on the Internet, this exposure can open a door to exploits. Attacks on SAP Afaria can be conducted using the vulnerabilities we have discussed.

In addition to the vulnerabilities described in this article, here are some others you could read about.

• Authorization bypass
• Stored XSS
• Buffer Overflow
• Missing authorization check
• Buffer overflow

References

https://erpscan.com/wp-content/uploads/publications/Securing-SAP-Systems-from-XSS-vulnerabilities.pdf

https://erpscan.com/wp-content/uploads/publications/3000-SAP-notes-Analysis-by-ERPScan.pdf

https://erpscan.com/press-center/blog/sap-afaria-security-stored-xss-vulnerability-detailed-review/

https://erpscan.com/press-center/blog/introduction-to-mdm-solutions-and-sap-afaria/

https://erpscan.com/press-center/news/sap-afaria-vulnerability-one-sms-to-wipe-and-lock-130m-mobile-devices-of-enterprises/