As a penetration tester who specialises in mobile apps, I get good visibility of how the enterprise is adopting/using/misusing various iOS capabilities and MDM features. One trend I’ve seen increasingly, is the use of ‘Guided Access Mode‘ to lock down devices.
Guided-Access Mode (GAM), for the unfamiliar, locks the device into a single app. It’s typically considered a handy feature for parental guidance, but the official documentation also suggests its effectively the same as the more enterprisey ‘Single App Mode‘; which is true. ‘Single App Mode’ (SAM) does exactly the same thing, but can only be enabled via MDM on a device which is in ‘Supervised’ mode. So it makes sense that organisations which cant easily manage devices use GAM instead. Although many just don’t know that Single App Mode exists.
I’ve seen GAM in the medical, financial, industrial, and retail sectors now. I know that it’s being used to protect highly sensitive data from prying eyes and, in certain scenarios (industrial), I would not be surprised to hear that GAM is defending against life-threatening incidents. That’s a lot of pressure for a parental guidance feature.
I recently performed a penetration test for a prototype self-checkout kiosk/POS solution which used an iPad as the kiosk’s display. Long story short, the solution used Guided Access Mode and, yet again, I was foiled in my attempts to get around it. The test finished a few weeks ago and, not one to give up, i’ve been testing Guided Access mode in my own time. Here’s the bypass 😉:
So Guided Access Mode is enabled in Settings > General > Accessibility > Guided Access. You then tripple-click the home button within any app to start it.
It has several options:
- The touch screen can be disabled, or certain areas of the screen can be disabled with a tool that resembles Photoshop’s lasso (you know what i’m talking about)
- The virtual keyboard can be disabled
- The volume and sleep/wake hardware buttons can be disabled
- Motion detection can be disabled (Accelerometer/Gyroscope)
- Timers can be enabled to restrict app usage for up to 24hours
- TouchID, or a passcode (not the device’s passcode) can be used to disable Guided Access mode
The attack surface is quite small. But there were a few things I found that were interesting:
- If you enable use of the sleep/wake buttons, then when you are in Guided Access mode, putting the device to sleep and waking it does not require a passcode to be input again. I can imagine this being a useful trick for law enforcement (or thieves) to carry a device around without worrying about it locking. I suppose the rationale is that this prevents kids from racking up years of wait time on the lockscreen as they try and guess your password. But personally I see it as an issue. Guided Access mode could just use the device passcode.
- If you quickly alternate the device between sleep and wake, you will occasionally glitch to the homescreen. Nothing can be interacted with… you can just see some of the installed apps, and after a few seconds you end up jumping back to the guided app. This behaviour made me think that Guided Access has some sort of timed interval it checks that you are still in the correct app… and if you are not, will throw you back into it. So even if we found a bypass, we would likely need to bypass that too (spoiler alert: we do… sort of).
My strategy was basically to do everything possible to an iOS device while in GAM and, at the same time, fuzz the crap out of every possible input and output… a solid plan.
1. Initially I looked at how responding to device events and their animations might get me out of GAM. I thought maybe one of the more obscure features might have been missed:
- push/local notifications
- battery notifications
- temperature warnings
- emergency/government alerts
2. I tried to find a reliable way to crash any app or GAM:
3. I tried looking at the network messages the device receives that ‘do stuff’:
- from iCloud (like enabling Lost Mode)
- from MDM providers (pushed policies)
4. Then I turned to hardware…
- I tried using third-party charging cables to force the ‘Unsupported accessory’ UI
- I tried outputting the device image to a screen via lightning to VGA and HDMI adapters
and finally I read THIS…
“After you connect the Lightning to USB 3 Camera Adapter, your iPad Pro automatically opens the Photos app” – Apple
I smell a bug 👃🏻🐛!!!
A trip to the apple store later, it turns out that statement isn’t quite right. For Photos to open, the USB3 camera adapter can’t just be plugged in by itself, and needs to be connected to a DCF-conforming device. This could be an SD card, USB drive, digital camera, or even another iOS device! If this device isn’t self-powered, it’s unlikely that an iPhone/iPad can power it, so you have to plug it into a powered USB hub, then plug the hub into the USB3 camera adapter, and then that into the iPad/iPhone. Very elegant.
But when you do this, even inside of GAM, for a brief moment the Photos app opens. And, just like with the homescreen, we are shuffled back to the guided app pretty quickly. BUT, unlike the homescreen, if you repeat this enough times you will notice that, in this brief period, the Photos app can be interacted with!!! We have a race-condition 🏎
What’s great is that, if Photos is already open, re-inserting the adapter wont send you back to the main viewcontroller. So any actions you managed to snipe into the Photos app, or text you managed to type… will persist. So it is possible to, incredibly slowly and unreliably, use the Photos app! The Photos app has the power to show/edit contacts, view/send iMessages, post tweets and facebook posts, and do all manner of things with third party apps like Whatsapp. So, although technically not a complete break-out of GAM, it’s a good level of device compromise… and possibly enough to deliver jailbreak code to a device, which is the ultimate win really.
To keep the device in the Photos app for longer, and make the race condition far more usable, we can do something incredibly hacky… slow the device down! If the app you get stuck in has some form of unrestricted text input, or the ability to add anything new that consumes RAM or CPU cycles, then you just need to keep adding things to the app until the device becomes incredibly unresponsive. At this point, you’ll find that it takes far longer for the device to transition to the Photos app when the adapter is plugged in, but that when it does, the Photos app is usable for minutes, rather than the usual split-second. The difference is very substantial.
A pretty simple fix here, the logic to open the Photos app (when appropriate accessories are inserted) should first check if GAM is on. Weirdly, this logic is in place for Single-App mode, which is actually built on Guided Access mode. Bizarre.
Apple were notified of the vulnerability via email. Their response:
“Features like Guided Access are designed to provide parents and system administrators with the tools to discourage violations of policy by legitimate users. These features are not intended to protect a device against manipulation by a malicious person”
The young chap assigned to this case, who gave that response, is rather misguided in my opinion, but I don’t have time to argue the toss via email. At least we can say to our clients that, categorically, GAM is not a substitute for SAM – that’s a win in my book!
- As pointed out by @op_nomad, iOS is actually a DCF-compatible device, so you can break out of GAM mode using a second iDevice. Post updated.
- The other Camera adapters from Apple, and third-parties, also work.