Yesterday, for the first time, I headlined a talk at a major security conference. It was quite the experience, and not nearly as nerve-wracking as I might’ve expected. Actually, it was pretty easy – I took the approach that “this is some cool stuff I found, let me tell you about it” and kept a conversational mindset. Don’t know if that’s what experienced presenters do, but it worked for me, and I think I pulled it off. Achievement: UNLOCKED.

For those who couldn’t make it to Black Hat, I wanted to post a short summary of my talk here, as well as links to the slides and white paper. So here we go!

When iOS 4.0 was released, Apple included some new features for remote management of iOS devices. This Mobile Device Management (MDM) is aimed at enterprises, and provides them with the ability to remotely configure and control all the devices within their organization. MDM includes three key features:

  • Configuration: Install and remove configuration and provisioning profiles
  • Query: Retrieve specific information from devices such as software versions, application lists, etc.
  • Control: Remotely lock, unlock, and wipe devices

When the MDM system was first announced, developers expected documentation to be released – but it never came. Certainly, the protocol was shared with those commercial vendors selling MDM implementations, but it was never publicly released, not even exclusively within the developer program.

It’s certainly Apple’s prerogative to keep these APIs private, but doing so makes it difficult for people in the security firm to answer the simple question: “How secure is it?” And, as consultants supporting the deployment of iOS devices across large enterprises, we get asked that question. It’d be nice to be able to answer it, so we did some poking, prodding, and a whole lot of educated guessing, and now have a (reasonably) complete picture of the MDM protocol.

The attached white paper documents the protocol, as much as is possible. It describes how the server wakes up clients via Push Notification messages, what the device says to the server when it connects, how commands are sent to the devices, and finally, how the responses make their way back to the server. In short, enough information is presented that you can actually create your own MDM server. In fact, it even includes source code to a very simple MDM server you can use for your own research. (But don’t even think of using it as a substitute for a real MDM system – it’s just there to demonstrate the protocol).

So, to answer the first question, “How secure is Apple’s MDM?”, I’d have to say, it’s not too bad. The protocol itself is fairly straightforward and, with one exception, doesn’t appear to have any real security flaws. Unfortunately, the implementation on the iOS devices I tested (4.2.x and 4.3.x on iPhone 3Gs and iPad 1 and 2) has some implementation flaws and/or deficiencies that could lead to denial of service or disclosure of data. I’ll discuss both of these briefly here, but for full details see the attached slides.

The only real protocol problem that I believe exists is that the EraseDevice command (used to remotely wipe a device) doesn’t require any authentication from the server. As long as the device has received the EraseDevice command via the MDM connection, it will honor it. If an attacker is able to get a device to communicate with a rogue MDM server using traditional Man-in-the-Middle (MITM) techniques, then they could cause that device to erase itself the next time it checks in with MDM. It might be nice if this command required, for example, the UnlockToken used to clear the device’s passcode, as evidence that the MDM server issuing the Wipe command is, in fact, authorized to do so. I’d actually been so convinced this would be a requirement, that when I was able to wipe a device without additional authentication it left me stunned for several minutes.

On the other hand, it’s possible that Apple deliberately chose the less strict form of this command. When an organization determines that a device needs to be wiped, it’s likely because it’s been stolen or lost, and the erasure of the data on that device is of paramount importance. So the risk of accidental erasure, or malicious erasure by 3rd parties, might be acceptable given the requirement that in an emergency, nothing stand in the way of wiping the device. And besides, you’re supposed to be backing these things up regularly anyway.

The implementation flaws I discovered center mostly around weak authentication, both for communication with the MDM server itself, and with regards to authentication of server commands. In the former case, it appears that the client on the device will accept any valid certificate. That is, as long as the server it’s speaking with has a certificate which has been signed by an appropriate authority (or signed by a certificate authority which is recognized by the device), the connection will be permitted. This obviously opens the door to MITM attacks against MDM-managed devices.

The other key issue is that the device doesn’t appear to authenticate the commands themselves. A checkbox when creating an MDM enrollment profile offers to “sign messages,” but even when checked, the device happily accepted plain, unsigned commands. Forcing the server to sign commands, and adhering to a strict policy for validating those signatures, would make MITM attacks that get past the transport-layer protections significantly more difficult.

A final interesting issue I uncovered, by chance, was an Evil Maid attack. Briefly, the “traditional” Evil Maid attack describes how an attacker, with physical access to a device secured with full disk encryption (FDE), could boot that device from external media to install malware, such as a key logger, into the boot partition. This malware would enable the attacker to recover the user’s password to unlock the FDE on the device, which would be exploited by the attacker on subsequent accesses to the hardware.

Apparently, sending a copy of the original MDM enrollment profile to an enrolled device will cause that device to re-enroll in MDM. This re-enrollment also causes the device to create a new UnlockToken, and send that to the server. If the attacker has a rogue server set up using MITM, then that token would go to the attacker, and they’d then be able to clear the device’s passcode and access protected information on the device.

This attack is certainly not easy, and relies on some pretty specific boot exploits using DFU mode and tethered access to the locked filesystem. To date, I do not believe this mode is available on iPad 2, so those devices should be protected (at least, from the specific variant of the attack that I’ve experimented with).

Fortunately, this attack can be eliminated with the stronger session- and command-level authentication steps suggested above, along with protection (or elimination) of some key data on the device. Full details, again, are in the slides.

What’s the bottom line, then? Do these weaknesses make MDM a significant risk for enterprises? In my opinion, certainly not. The benefits of MDM far exceed the risks introduced by these vulnerabilities. If, however your organization stores sensitive information on iOS devices, then care should be taken whenever those devices are left unattended, whether in a hotel or even within the office environment. But then, the same care should be applied to any device with sensitive information – mobile, desktop, or laptop.

So in the end, I hope that our work can help you better understand how MDM works, and properly evaluate its risks and benefits to your organization. For those of you who made it to my talk, thanks for coming and I hope you enjoyed it! For those who didn’t, I hope the attached material will prove an acceptable substitute (and, no, I don’t believe that Black Hat makes videos available to the general public). If anyone has any questions about this research, please feel free to contact me.

[Update – slides, whitepaper, and code are now available on Github: https://github.com/intrepidusgroup/imdmtools/]