Securing the modern mobile OS

The idea for this blog post came to me during a discussion around some recent research performed by Cisco’s Talos threat research group.

The post “Advanced Mobile Malware Campaign in India uses Malicious MDM” authored by Warren Mercer, Paul Rascagneres and Andrew Williams and the follow-up post containing additional research found in Part 2.

In this beautiful piece of research, these guys identified and analyzed an attacker with malicious intent, that used a modified open source Mobile Device Manager (MDM) to control multiple mobile devices; and to install modified versions of well-known apps like WhatsApp and Telegram in order to gain access to what would otherwise be private data.

”What would you say you [an MDM] do[es] here?”

You’re welcome for the Office Space reference 🙂 

Mobile Device Management (MDM), also sometimes referred to as Enterprise Mobility Management (EMM), is a more than just tooling. It is the technique of managing endpoints from a central location, and it is a critical aspect of a secure endpoint strategy.

A long, long time ago, Microsoft created something called group policies which are capable of controlling every aspect of a computer running Windows. You could lock down everything about that endpoint from what is displayed on the desktop and start menu, to the ability to prevent users from right clicking. The level of control is amazing.

Fast forward to this mobile device that comes out, called the Blackberry. The product takes the world by storm, and there was even a slang term created, “crackberry,” because of how addicting it was to be able to work from these mobile devices; having access to email, web, documents, etc. – all at ones’ fingertips.

Crackberrys were very popular with Enterprises, because they offered the Blackberry Enterprise Server (BES); which gave the Enterprise complete and total control over the Blackberry endpoint, much like group policy did for Windows. In fact, the Blackberry OS was built from the ground up with that level of control in mind.

We won’t dive into the reasons why I feel that Blackberry lost market share to Apple’s iOS and Google’s Android mobile OSs, although I could probably write an entire blog on that. The point is that iOS and Android make up the vast majority of the mobile handheld market (phones & tablets) and most of us do not even see Blackberry around anymore. A quick internet search showed me that researchers only really track Android and iOS nowadays.

MDM is how the technology industry is attempting to bring that total control of a mobile device to Android and iOS today. In other words, using 3rd party products/solutions to give the Enterprise organization as much control over the security posture of their mobile devices as possible.

Think about it. How else can you trust that the endpoint is configured in a secure way, before you let the end-user access private/work-related data?

So, MDM is important, but what can it really do?

The short answer to that question is: an awful lot!

The long answer gets to be rather complicated. I’ll dive into this a bit more, further in this blog, and even compare and contrast iOS and Android a bit.

Yet, before I dive into the longer answer to this question, let’s ask another more pressing question – especially when you put this conversation into the context of Talos’ published research on the malicious MDM.

What can can’t the MDM do?

MDM does not access the data on your device. It can protect the data, be enforcing encryption or by creating isolated “work” containers that an Enterprise can wipe if the device is ever lost or stolen. But it is not providing the enterprise with access to the data on the endpoint itself. An MDM could install malicious apps that are designed to access that data & ship it off to a nefarious location, sure. But the MDM capabilities that are provided by Android & iOS do not directly provide access to the pictures, messages, or other data stored on your phone.

An MDM can and does provide access to a lot of metadata. Call logs, network logs, location, and data surrounding device usage could be accessed by the managing enterprise – for example.

Let’s dive into that longer answer, shall we?

iOS and Android are both very popular mobile operating systems, both of which provide the end-user with a very cool interactive experience with multi-touch screens and some other amazing human-interface design work.

However, under the covers, they are very, very different. This can be evidenced in the way each OS works with MDMs.

iOS device management framework

iOS is built with a framework of APIs that Apple will expose as they choose to. When iOS was first released, it was locked down to an extreme extent, and Apple has been slowly exposing more and more to the Enterprise; in a very secure and controlled way. Back in iOS version 5, Apple released a new state for endpoints, known as “supervised mode”. This mode of operation was designed for corporate purchased & corporate provided devices, not for Bring Your Own Devices (BYOD).

My thoughts on this are that while iOS was designed for the consumer first, Enterprises were obviously buying many of them for use in the corporation. Just take the coffee shop that I am writing this blog from, which is using a point of sale (PoS) system that leverages 2 different iPads per system. One iPad faces the customer and is used to display the order & even take the customer signature; while the second iPad is facing the cashier and is used for inputting the order, etc.

In this scenario, one “register” (PoS system) is two iOS devices that are not being used by the consumer – but are dedicated to the corporation. This is also very common in healthcare, automotive dealerships, manufacturing, you name the industry and chances are there are iOS or Android devices being purchased by the company for use within the company.

An MDM can have more control over an iOS endpoint in Supervised mode than non-supervised mode. There are settings that may impact an end-users’ privacy (such as Proxy Servers, always-on VPN, and Cisco Security Connector’s “Clarity” function) – and Apple ensures that only a device in Supervised mode can have those functions enabled.

If you are ever curious enough and want to see exactly what an MDM “could” configure on an iOS device, just download the Apple Configurator 2 app on a computer running macOS & create a new profile (known as a configuration profile). Each section (I believe they are called payloads) of the profile is a function that Apple has chosen to expose to device managers. Some will only take effect on supervised devices and some will work on all devices.

The resulting configuration profile (a “mobilconfig” file) is an XML-based file that can be installed into an iOS device by an MDM, or manually by the end-user. iOS has a built-in capability known as Over the Air (OTA) provisioning, that allows configuration profiles to be sent to to the endpoint. OTA is how Cisco ISE’s BYOD provisioning occurs, for example. The configuration could be airdropped to the endpoint; heck, I’ve seen configurations emailed to end users.

What you need to keep in mind is: installing these profiles requires end-user interaction. Someone has to be interacting with the endpoint and clicking “Yes” to install these profiles. There is even more security built into the function, as all MDM’s must be registered with the Apple Push Notification Service (APNS). Apple issues a certificate to that MDM that is signed by Apple’s own CA and only MDMs with a VALID signed APNS certificate will be allowed to use the framework and manage the device.

One interesting thing about this iOS framework is that MDMs do not need an app in order to manage the endpoint. An app may provide additional functionality (such as being able to provide a constant GPS tracking to the MDM), but the app is not required at all. This is another stark contrast to the way Android works (but we’ll cover that later, in the Android section).

We could write a book just on what you can manage on iOS with device profiles. One of the key things that you should understand is that a device manager is designed to make the lives of both the end-user and the endpoint management IT team easier and more secure (in most cases) such as:

Installing apps

So, an MDM is able to install applications onto a device when the screen is unlocked (that’s right, even an MDM is not permitted to do very many things to an iOS device when the screen is locked).

Most of the time, the apps are installed from the official Apple app store, in which case the MDM is simply telling the endpoint to grab that app from the store, leveraging the end-users’ Apple ID and requiring the end-user to approve the download and installation in many cases. The MDM maintains an inventory of which apps and which versions are installed on managed devices as well.

In addition to the “normal” way that apps can be installed, there is another mechanism that Apple calls the volume purchase program (VPP). You see, every public app that can be installed onto iOS requires a license. That license may not have a cost associated with it, but it is still a license nonetheless. In the “normal” way of installing apps on iOS, the license is tied to the end-user’s Apple ID. With VPP, however, the license is owned by the organization and there is a centralized tracking of how many licenses the org owns, and what devices those licenses have been assigned to. This allows organizations more control over installing apps without bothering the end-user.

The third way to have apps installed into iOS is to use an “enterprise app” where the IPA (iPhone application archive), which is the app itself is uploaded into the MDM to be distributed to the managed endpoints. The app will still need to be signed with a certificate that Apple has signed for software developers, or the iOS endpoint will have to manually configured to trust the signing certificate.

And… here comes how our malicious actor installed modified versions of the messaging apps onto the compromised endpoints. You see, once the attacker’s MDM was in control of the victim iOS endpoints, the attacker was able to push down the certificate they used to sign the apps and force the iOS device to trust that certificate without the end user having any idea.

Keep in mind, this is a VERY important function for an MDM. Many organizations have home-grown apps for their employees to use, or even dedicating the iPad / iPod Touch / iPhone for use with those custom apps. Those custom apps will not be available in the public app-store; and those “enterprise apps” will be signed by a certificate.

The same is true for the MDM’s ability to push WiFi profiles, and other trusted configurations. By pushing a WiFi profile into any endpoint, you can get that endpoint to trust a rogue server & rogue SSID, thereby joining a malicious network and sending your credentials to a malicious actor.

When Apple learns of a malicious actor using an MDM; they revoke that malicious actors APNS certificate – immediately rendering that particular system unusable to manage any more iOS devices. When Apple learns of a malicious app, they revoke the certificate (if one was issued), rendering the apps useless & they remove those apps from the app store (if they were public apps).

So what do we learn from all of this, as it relates to iOS?

Simple. iOS is a very secure operating system, indeed. It has a very powerful framework for device management that is needed for enterprises today. IF your organization uses iOS and allows those devices to connect to work data, even just email, then the #1 lesson is: use an MDM yourself.

That’s right. Get those devices under control of a legitimate MDM, so your organization may have centralized visibility into the devices, what software is installed on them, and also: protect that MDM profile with a password to prevent removal (lesson #1). The end-user will not be able to “accidentally” accept a malicious actor’s control of the endpoint, because iOS only allows for one device manager at a time.

Android’s DPC Architecture

Android works differently than iOS in many ways, and yet has a lot of similarities too. One of the major differences between iOS and Android is the way Android requires an app for an MDM to control the device, while iOS used a mobile configuration for the built-in framework.

With Android, the app with device admin capabilities is called a Device Policy Controller (DPC), and there can be multiple DPCs installed on a single Android endpoint; while with iOS it’s like the Highlander: “there can be only one” device manager.

While Android can have many DPCs, there is a very special role, known as the “device owner” role that only one DPC may have on the device. That device owner has access to a few extra items that the other DPCs do not. The Network-Logs are a perfect example of a function or capability within Android that can only be accessed by the device owner DPC app.

This is important, especially when you analyze the Talos blog post and see that the malicious actor was using a modified open-source MDM server to manage the iOS and Android endpoints. If there was an existing MDM DPC app installed on the endpoint in device owner role, then the malicious actor would not have been able to take over the device owner role on the device. This would not stop that actor from installing the modified versions of Signal or WhatsApp; but it would prevent that actor from accessing the Network-Logs and tracking all the end-user’s activity.

The device owner DPC is also able to control what apps can be & cannot be installed onto the Android device, including the capability of providing a white-list of applications, just like iOS does (but only with supervised iOS devices). Beyond application white-listing and black-listing, the device owner DPC is able to create an Android@work container.

It is really more of a partition than a container in many ways but is another part of the Android solution that differs greatly from iOS. When the DPC’s container is created, everything is kept separate. All the data and metadata for work is kept within that container. If the DPC is removed, so is the container and all the data within it.

Not only is the data kept separate, but the MDM installed apps are installed into that container. So, there will be two completely different copies of the same app. One in the container, and one in the main Android partition. Everything is kept completely separate. However, if the actor gets the end-user to use the maliciously modified versions of the apps – they can get anything they want from those apps gift wrapped and sent straight to their front door.

And that’s a wrap

I think if you have read this far, you deserve an award of some sort. This was a very long blog post, or at least it felt like it while I wrote it.

There are some very important takeaways that I want to leave you with.

For iOS: if the endpoint accesses information that needs to stay protected, make sure the organization is protecting those iOS endpoints with an MDM; along with a password protected configuration profile. If the device is corporate owned – make sure it is in supervised mode for extra security and protection.

For Android: make sure the device is protected by an MDM in device owner mode; and that an Android@work profile is being used. If you are really security conscious, use app whitelists to prevent the install of untrusted apps.

NEVER install anything from unknown sources, and most importantly: NEVER click accept to when presented with a warning about trusting an app or installing a profile on iOS from an untrusted source!

They love to say that email is the no. 1 attack vector (unless you’re Craig Williams); but truthfully the no. 1 vulnerability is the human, not the device.

That’s it for this post. I’ll be back again soon with something else to bore you with.