Why you need to better protect your MDM service (Part 1)

Dominick Hume, Head of Product and Technical Services


  • Security Blog

Type in “securing my MDM” into your preferred internet search engine and you’ll be inundated with articles about the securing Mobile devices, ads for various MDM vendors, discussions around the differences between MDM, MAM and MIM, but you’ll be challenged to find anything about the security of the actual MDM server or the consequences of a compromise to the MDM.

This is slightly surprising because an attacker that successfully compromises an MDM server can then easily geo-locate a device and unlock it with a single command. They would then have access to all of the corporate resources that the phone has access to. It maybe even more of a surprise to some is that such an attack isn’t as difficult as it should be.

Most MDMs are designed as monolithic servers which have complex communication protocols that interact with several internet based services (push notification systems, online app stores….). Usually these communication channels are authenticated and encrypted end-to-end making it very difficult to inspect them for threats. Encrypting these communications would have been seen as essential in the early days of the BYOD revolution, as the emerging MDM vendors fought for market share with Cloud Based multi-tenanted MDM offerings. But the reality is the authentication schemes used are now the only defence against malicious attacks on these solutions. A trusted but compromised mobile device can send malicious content direct to the server. Microsoft’s September 2018 Patch Tuesday release contained 61 vulnerability patches, 17 were critical including a privilege escalation attack that had been exploited in the real world just 2 days after its surreptitious release on twitter (See Dark Reading Article).

Some readers will undoubtedly be wondering why a Web Application Firewall strategically positioned in front of the service can’t solve this problem with ease. Which is a very good question that deserves some analysis, because a WAF can do much to reduce the risks, but some challenges remain.

Firstly a WAF is only as good as its configuration. It must know what good looks like when it comes to the stack of messages that an MDM will exchange with a Mobile Device. In the example of iOS that’s over 30 different .xml message types, some simple such as “IdleStatus”, others can be complex such as “InstallProfile” which can contain encrypted blobs of binary data. Just being able to identify this traffic as Apple iPhone related and verifying some header, footer and basic content types is unlikely to provide meaningful protection from an attacker with a good knowledge of the publically published Apple MDM API. Verification is made even more difficult by the format of the .XML used by Apple for these messages.

Secondly the WAF can only really help for part of the story. Managing an iOS device means integrating the MDM with APNS (Apple Push Notification service), DEP (Apples Device Enrolment Program) and the VPP for business (Apples Volume Purchase Program). An iPhone will not even register with an MDM without APNS. This is an authenticated and encrypted connection between the MDM and the APNS servers which cannot be proxied, and you’ll be needing to open this outbound firewall rule up to the entire 17.x.x.x address space. At which point (and this happened to me) your Firewall administrator might ask if you’d like them to just pick the entire appliance up and just dump it in the bin.

Using DEP is optional. However the advantages over and above manually supervising each device are compelling. The time savings alone are huge, but the ability to prevent users from removing the “supervision” setting on the device is a key feature that the security conscious should not ignore. However, the security conscious Mobile Architect may well be following the NCSC’s guidance on deploying iOS which strongly encourages the use of an Always On VPN configuration. This creates a whole new chicken and egg situation with regards to deployment. A device can’t connect to the VPN until it has enrolled and received its VPN profile. Yes, that’s right, you’ll need to open up the MDM to the internet to allow the registration process to happen. But this time it’s a connection from a device whose certificate you didn’t create.

Using VPP is also an option. Again it’s an option that you should probably exercise. Apple and some MDM vendors have long supported the concept of an Enterprise App Store where the MDM itself stores and delivers the app, but this concept has a risky flaw. The Apps themselves are only signed by the App developer’s certificate, not by Apple themselves. If your App developer accidently (or otherwise) finds themselves persona non grata and their certificate is revoked your Apps will start to irrecoverably fail pretty quickly. Whereas using VPP costs no more than a little effort and time to protect against such a situation and simplifies the central purchasing of standard Apple Store available apps. The downside of this solution is Apples recent decision to deliver Apps via CDN’s (content delivery networks). Now a whole new set of traffic rules needs to be configured on top of the Apples Class A address space. Frightening!

All of this means that the residual risks of hosting your own MDM servers just got even more complicated than just the risk to the data on the phone. A compromised server could also be used for data exfiltration to a wide range of addresses. Unwanted or malicious applications could be deployed silently to devices. Some questions can raised as to the robustness of the DEP enrolment process and the sheer complexity of the iOS management solution makes simple sensible security decisions very difficult to make.

In part 2 of this blog series, I discuss a new MDM architecture designed to mitigate these risks. The architecture has resulted from NCSC’s Advanced Mobility programme.

Dominick Hume

Leave a comment

Comments (5)

  1. vip escort:
    Jul 18, 2019 at 12:38 PM

    An impressive share! I have just forwarded this onto a coworker who
    has been doing a little research on this. And he actually bought me breakfast because I
    found it for him... lol. So let me reword this.... Thank YOU for the meal!!
    But yeah, thanx for spending time to talk about this subject here on your

  2. https://www.pornjk.com/tags/spankbang/:
    Aug 11, 2019 at 06:23 PM

    I've been exploring for a little bit for any high quality articles or weblog posts on this sort
    of area . Exploring in Yahoo I eventually stumbled upon this
    website. Reading this information So i am satisfied to convey that I've a very good uncanny feeling I came
    upon exactly what I needed. I such a lot no doubt will make certain to
    don?t put out of your mind this web site and give
    it a glance regularly.

  3. https://forums.macg.co/threads/separation-personnel-professionnel.1316627/:
    Aug 15, 2019 at 04:04 AM

    Hello There. I discovered your weblog the use of
    msn. This is a very smartly written article. I'll make sure
    to bookmark it and return to
    your useful info. Thank you for the post. I'll definitely return.

  4. How to Heal Hemorrhoids:
    Aug 22, 2019 at 05:31 AM

    We stumbled over here from a different web page and
    thought I might as well check things out. I like what I see so now i am following you.
    Look forward to looking over your web page for a
    second time.

  5. How to Cure Hemorrhoids at Home Fast:
    Aug 22, 2019 at 07:49 AM

    My partner and I stumbled over here by a different web
    page and thought I might as well check things out. I like
    what I see so now i am following you. Look forward to looking into your
    web page for a second time.

Latest News

  • Becrypt continues enthusiastic support of the National Cyber Security Centre’s CyberFirst programme

    Becrypt continues enthusiastic support of the National Cyber Security Centre’s CyberFirst programme ...Read more


  • Zero Trust networks with zero hype - an overview of real world deployments

    An overview of the NCSC CloudClient project in the context of Zero Trust network characteristics ...Read more


  • Measured Boot & Measured Execution for Device Health

    Using Measured Boot & Measured Execution with Remote Attestation to measure Device Health with Paradox OS ...Read more