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.