Intrepidus Group
Insight

iOS MDM: Preventing Disassociation DOS and Potemkin Devices

Posted: February 22, 2012 – 4:10 pm | Author: | Filed under: iOS, Mobile Device Management | Tags: , , ,

I was thinking a couple of weeks ago about additional vulnerabilities in iOS Mobile Device Management, and noticed a couple of problems that I had not considered before.

It may be possible for a malicious individual, whether an outside attacker or inside troublemaker, to forge fake responses to the MDM server. They could, it seems:

  • Send the server fake TokenUpdate commands
  • Send the server fake responses to real commands

In both cases, the attacker would need to know the UDID of the device they’re trying to impersonate.

The first case, a fake TokenUpdate command, could be used to sever the link between the server and the targeted device. By sending the command with a bogus DeviceToken, the MDM server would no longer be associated with the device, as the Push Notification system wouldn’t know where to send messages. Thus, the device whose UDID was used in the attack would no longer be managed by MDM.

An attacker who manages to collect UDIDs for multiple devices could thus mount a denial-of-service attack against the organization’s MDM server. Each and every targeted device would have to be manually re-enrolled with the server in order to resume management. For a large number of devices, this could be a costly effort, especially if the attack is repeated multiple times.

The second case is a bit more sneaky. If a user reconfigures their managed device to point to an MDM server of their own, they could essentially proxy the MDM protocol and send fake responses to the real server. By doing this, they could essentially create a “Potemkin Device” that would appear, to the corporate MDM server, to be properly in compliance with all policies, when in fact the device would simply ignore all MDM commands.

This seemed a little extreme to me. There must, I reasoned, be some way to prevent this from happening. So I dug a little deeper, and remembered the “Sign Messages” flag in the MDM enrollment payload. I’d experimented with this before, but discovered it had no effect on whether the client trusted the commands from the server.

As it turns out, I had it backwards — this flag isn’t for the server to sign messages to the client, but for the client, the remote device, to sign its messages back to the server. Exactly what I was looking for.

The exact mechanics are pretty simple:

  • The client includes an “Mdm-Signature:” header in the HTTP PUT messages it sends to the server
  • This signature is a base-64 encoded, .DER format, SMIME signature
  • The content which is signed is not included in the signature, but is instead the content of the PUT itself — the message being sent to the MDM server
  • Finally, it’s signed using the private Identity key that was sent to the device at MDM enrollment

So to prevent both these attacks, you must:

  • Ensure the “Sign Messages” flag is set by the MDM server when enrolling device, and
  • Ensure the server itself actually checks the validity of the signed messages, and rejects them if the signature is invalid

Note that it may be possible to extract the identity certificate and key from a device and set up the fake MDM proxy even with message signature validation enabled at the server — but I haven’t investigated this yet.

I’ve updated my test server with code that performs this check. You can find it on Github.

david.

Both comments and trackbacks are currently closed.

5 Comments

  1. Alexander
    Posted February 27, 2012 at 8:33 am | Permalink

    Hello!
    My question is not about this topic.
    I’ve seen in some mdm companies apps function to gps-tracking http://www.amtelnet.com/mdm/lost-device-gps-track
    Is it possible to do with just mdm? Or this tracking made by some kind of ip location service?

  2. david_schuetz
    Posted February 27, 2012 at 10:16 am | Permalink

    Apple’s MDM system does not provide geolocation capability. This functionality can be provided by a 3rd party vendor through use of vendor-specific programs on the device, which might be able to periodically poll for position changes and send that information back to a central location, where the MDM console could then display and make use of it.

    The MDM server might also, as you suggest, be able to use an IP geolocation service to infer the device’s location based on the IP it’s checking in from, but that won’t be as accurate as getting an actual GPS fix.

  3. Alexander
    Posted February 27, 2012 at 11:05 am | Permalink

    Thank you for response!
    With third party app installed, from mdm I cant launch this app on user device? and if user disables location service or close app I couldnt trace it? Too bad there is no way in mdm to get just gps coordinates…

  4. david_schuetz
    Posted February 27, 2012 at 12:04 pm | Permalink

    That’s correct — MDM can install an application (which still needs the user’s approval), but it cannot force the app to actually launch. Even the push notification system won’t cause the app to launch (but the app will get the notification directly if it’s in the foreground when the push message arrives).

    I was kind of surprised that coordinates weren’t returned in the generic DeviceInfo command, or that there wasn’t a specific GPS command. It may be that there is some method, and that I simply haven’t found it yet, but I believe that 3rd party vendors also require the use of the external application to collect geolocation information.

  5. Alexander
    Posted February 29, 2012 at 1:02 am | Permalink

    Interesting what command Apple use in Find my iPhone… maybe mitmproxy can help

image

This site is protected with Urban Giraffe's plugin 'HTML Purified' and Edward Z. Yang's Powered by HTML Purifier. 24462 items have been purified.