CyberWire Daily - Apple Device Enrollment Program vulnerabilities explored. [Research Saturday]

Episode Date: December 22, 2018

Researchers at Duo Security have been looking into Apple's Device Enrollment Program (DEM) and have discovered vulnerabilities that could expose users of the service to potential issues from social engineering and rogue devices. James Barclay is Senior R&D Engineer at Duo Security, and he joins us to share what they've found. The original research can be found here: https://duo.com/blog/weak-apple-dep-authentication-leaves-enterprises-vulnerable-to-social-engineering-attacks-and-rogue-devices   Learn more about your ad choices. Visit megaphone.fm/adchoices

You're listening to the Cyber Wire Network, powered by N2K. data products platform comes in. With Domo, you can channel AI and data into innovative uses that deliver measurable impact. Secure AI agents connect, prepare, and automate your data workflows, helping you gain insights, receive alerts, and act with ease through guided apps tailored to your role. Data is hard. Domo is easy. Learn more at ai.domo.com. That's ai.domo.com. Hello, everyone, and welcome to the CyberWire's Research Saturday. I'm Dave Bittner, and this is our weekly conversation with researchers and analysts tracking down threats and vulnerabilities and solving some of the hard problems of

protecting ourselves in a rapidly evolving cyberspace. Thanks for joining us. And now, a message from our sponsor, Zscaler, the leader in cloud security. Enterprises have spent billions of dollars on firewalls and VPNs, yet breaches continue to rise by an 18% year-over-year increase in ransomware attacks and a $75 million record payout in 2024. These traditional security tools expand your attack surface with public-facing IPs that are exploited by bad actors more easily than ever with AI tools. It's time to rethink your security.

Zscaler Zero Trust plus AI stops attackers by hiding your attack surface, making apps and IPs invisible, eliminating lateral movement, connecting users only to specific apps, not the entire network, continuously verifying every request based on identity and context,

simplifying security management with AI-powered automation, and detecting threats using AI to analyze over 500 billion daily transactions. Hackers can't attack what they can't see. Protect your organization with Zscaler Zero Trust and AI. Learn more at zscaler.com slash security. Mobile device management has become a term to mean any number of things really like it could be

just how devices are managed of course like the mobile moniker can be confusing because it doesn't necessarily need to refer to managing mobile endpoints that's james barclay. He's a senior R&D engineer at Duo Security. The research we're discussing today is titled, Weak Apple DEP Authentication Leaves Enterprises Vulnerable to Social Engineering Attacks and Rogue Devices. But basically, I would just say, you know, it's a way to manage endpoints. So in the case of Apple devices, it refers specifically to clients, which are Apple devices like Macs and iPhones and Apple TVs and servers that implement support for the MDM protocol. And Apple provides documentation on how this works, but it's used by administrators to deploy configuration data to endpoints and just generally manage them. And so it's not limited to iOS devices?

Correct. Gotcha. So how does Apple's device enrollment program work? The device enrollment program is a service provided by Apple that is designed to streamline the mobile device management enrollment process for Apple devices. I guess the best way to describe it would be, as an administrator, if you want to automatically enroll endpoints in MDM and provide a better user experience for your end users, you can sign up for the device enrollment program through either Apple Business Manager or Apple School Manager, and then have devices that you purchase either

directly from Apple or from an Apple authorized service provider automatically enroll into your MDM server when they boot up for the first time. How pre-configured is the device out of the box? So it depends. It depends on what the organization or the administrator is deploying via MDM. So in some cases, it could just be the organization deploys an application or something that requires the user to authenticate separately before receiving any sensitive configuration data. On the other hand, the scope of what MDM can do is quite large. So, you know, out of the box, you can deploy things like, you know, Wi-Fi passwords, VPN configuration data, any number of things that you might, you know, as an administrator want to automatically configure for your end users. I see. So the notion is you provision a user with this device, and when they boot up for the first time, many of the things that they would otherwise have to manually configure, it'll come ready to go right out of the box and

that saves everyone time. Exactly. Yeah. So Apple uses a number of APIs when it comes to these configurations. Can you walk us through what's going on with those? Yeah. Like I mentioned earlier, for the MDM protocol, like the Apple MDM protocol, this is typically not something operated by Apple. You can use a Mac OS server to handle some of these things. But typically, organizations are going to be using either their own implementation or an on-premise or SaaS service that provides MDM support. So this could be something like Jamf, FleetSmith, MobileIron, and so on and so forth. So there's the MDM server, and then there's the DEP service,

which is actually operated by Apple. And this is what I was saying earlier about this is a service that allows for a streamlined mobile device management enrollment process. So there's the MDM protocol, and then there is the DEP service, right? So in the research we published, we went into greater detail on how the DEP APIs work. So there is a service at iProfiles.apple.com. And this is during the device bootstrap process. The device will communicate with this service to determine if it's registered with the device enrollment program.

There's actually, in the paper we discussed, there's actually like seven steps that are involved with the device bootstrapping process. So initially, Apple or the authorized reseller will create a record for a device through a separate DEP API. Then the organization will assign that particular device to their MDM server in Apple Business Manager or Apple School Manager. Then the MDM server itself will retrieve what's called the device record through, again, a different DEP API. And then so step four, which is when the device authenticates to the DEP API to retrieve its activation record, that's primarily where our research focused. There's a few more steps after that that involve the device retrieving its enrollment profile, retrieving a client certificate,

and then authenticating to the MDM server. At step four, which is what we'll call it the DEP check-in process, it's when the device is giving its identity to the DEP service operated by Apple, which the identity in this case is its serial number, and that is not strongly authenticated to the device. So it's the authentication process involving the serial number is where things kind of get a little interesting. So take us through what's going on here. The device, so this could be an iOS or macOS device,

is during this DEP check-in process, provides its serial number to the DEP API. So there is an API at iprofiles.apple.com slash macprofile, for example, where it provides its serial number and a remote action to perform. In our research, we found that modifying the serial number that is presented to this API is what determines which DEP activation record is returned. So the activation record is, it's like a JSON blob of data that contains information about the organization that the device belongs to. For example, the MDM server URL that is associated with that device and organization. Interesting. So let's dig into that. I mean, what does that mean? I can imagine coming at this from a couple of directions. If I know the serial number of a device, I could then go in and see

what sort of information this JSON returns? Yeah, precisely. So part of our research also focused on the feasibility of brute forcing Apple serial numbers. There is enough information in the serial number format such that we could, let's say an attacker knows a given organization is buying newer MacBook Pros. So they can limit the search space of the serial numbers that they're brute forcing to only those models and only those models that were manufactured within a given time frame. So yes, getting back to your question, what an attacker could do is provide a valid serial number to this API. And if it has previously

been registered with DEP, it will return what's called the activation record, which contains the physical address of the organization, support email address, phone numbers, and then also the MDM enrollment URL. So this is how the DEP service tells the device where to go for the next step, like how to enroll with the MDM server. how to enroll with the MDM server. So coming at this from another direction, as you alluded to, if I had a new device that I go out and purchase an iPhone or an iMac

or a MacBook Pro or something like that, if I had enough information, could I register this with a company that I'm really not associated with? It depends. So it depends on how the MDM server is configured and secured. So the Apple MDM protocol supports authentication, but it doesn't require, sorry, user authentication doesn't require the user to authenticate outside of just providing this serial number identifier during

the DEP enrollment process. So depending on the configuration of the MDM server, it's possible that using this method alone, we can enroll a device in an organization's MDM server, like a rogue device, if you will, and retrieve whatever configuration data they're deploying via MDM, be it Wi-Fi passwords, VPN configuration data, proprietary internal application, and so on and so forth. You get the idea. Anything that an IT administrator would want to deploy to their end users. So how do we protect ourselves against this? You've notified Apple. What's their response been so far? So obviously, I can't speak for Apple, but like Apple does provide documentation on the I believe it's the Apple Business Manager help site, which we link to in the paper.

It basically just mirrors the recommendations we have for customers that are using both DEP and MDM, which is that, you know, strongly authenticate your device enrollments. So if you're not requiring users to authenticate as part of the MDM enrollment process, you probably should be. And then the second remediation step that we cover is really think carefully about what you're automatically deploying via MDM. In some cases, like I think I said earlier that maybe enrolling in MDM for a given organization only installs an application or something that requires a user to authenticate separately out of band before receiving any sensitive configuration data. And if that's the case, then it's not a huge deal if an attacker is able to manage enrolling a rogue device because they wouldn't be able to strongly enrolling a rogue device because they wouldn't

be able to strongly authenticate to receive that configuration data. So as far as we know, the specific issue that we found where the identity that is provided to the DEP API, which is the serial number, is not strongly authenticated. As far as we know, that hasn't been addressed yet. But it's one of those things where the severity of it depends greatly on how the organization secures their MDM deployment. Right. Now, one of the points you made in your research here was that despite this vulnerability, using this sort of program is worth it. The upsides exceed the potential problems as long as you handle it correctly. Yeah, yeah, I really think so.

You know, I want to be clear that, like, we're not saying that, like, you shouldn't use DEP or MDM. Like, I think the benefits of securely, you know, configuring endpoints outweigh the drawbacks, you know, in this, like, authentication weakness that we discovered.

But we just want to make sure that people understand some of the limitations with how devices are identified to the DEP API and then take appropriate action, whether that's securing your MDM deployment or limiting the scope of what you're doing with MDM before a user is strongly authenticated. Now, have there been any reports in your research? Did you come across this actually being done in the wild or is it still just theoretical at this point, as far as you know? We don't know if it's being exploited in the wild. It is fairly trivial to do. We wrote proof

of concept code for it, but because the issue has not been fully addressed. We opted not to release that into the wild. The attack is, you know, it's covered in detail in the paper. But yeah, we don't know whether it's being exploited. So if I'm the person at my organization who is responsible for deploying Apple devices and I'm using this MDM enrollment, what are your recommendations? What are the best practices for me to make sure I'm going at this in the most secure way? Make sure that as part of the MDM enrollment process, you are strongly authenticating the user before deploying any sensitive configuration data, or limit the scope of what you're deploying via MDM. It is worth noting that Apple does document

almost verbatim the same thing that we recommended in in the paper which which is kind of funny because like it's kind of varied uh it's in like Apple business manager help documentation and we didn't know that those uh recommendations were documented by Apple until we had given them a copy of the paper but we it was it was good to see that like okay the things that we're recommending are exactly the things that Apple is recommending. So that's good to hear. Yeah, I mean, it's interesting just from Apple's point of view as to whether or not I suppose they consider this to be a problem or just a behavior to be careful about. Yeah, I think for now, it's definitely the latter. I would describe it as an authentication weakness. There are limitations with how a device is identified during the DEP enrollment process. I think all that they're

able to say is, do those two things, or one or the other. Either strongly authenticate users during the MDM enrollment process, or just limit the scope of what you're deploying via MDM. It's worth noting, though, that one of the things that I covered in the paper is that strongly authenticating devices as part of the DEP check-in process would mitigate this issue, but it may take some time for that to become fully realized. One of the ways that that could be done is the certain Mac computers that ship with either the T1 or T2 chip. So like the MacBook Pros that have the Touch Bar, as well as the iMac Pro. Those have security hardware built into them that would allow Apple to perform basically device attestation or strongly authenticate the device prior to allowing it to retrieve a DEP activation record. Of course,

not every Mac computer that is currently shipping has one of these chips, but I think over time, you know, we'll see, we'll see something like that happen. It's possible, or, you know, like at least I would hope for it. Yeah. Things certainly seem to be headed in that direction, I suppose. Yeah. Like we talk, we often talk about like the consumerization of security hardware at Duo. We're big fans of devices that have, you know, builtization of security hardware at Duo. We're big fans of devices that have built-in security hardware like TPMs and secure enclaves and things like that. And we're seeing more and more of that in the industry, and it really does enable a whole lot of applications. So yeah, I think we're hopeful for the future. So, yeah, I think, you know, we're hopeful for the future.

Our thanks to James Barclay from Duo Security for joining us. The research is titled Weak Apple Depth Authentication Leaves Enterprises Vulnerable to Social Engineering Attacks and Rogue Devices. We'll have a link in the show notes. Thank you. approach can keep your company safe and compliant. Thanks for listening. Thank you.