
• Wait for another chance at device
• DFU boot, force MDM poll
• Evil server sends ClearPasscode
• Now device fully unlocked
–Browse everything
–Better yet, backup entire device and run
• But now there’s no passcode!
–The victim will suspect
• Replay TokenUpdate to real MDM
–Now the corporate server can talk to it again
–Most importantly, it can unlock the device again
• Set a bogus passcode
–User returns to device, can’t unlock it
–Eventually calls for help
–They unlock it remotely
–Everyone forgets this ever happened
Now the attacker has the unlock token for the device. They need only to
wait until the device is left unattended again. Then they get back into the
device (through the DFU tethering magic), force the MDM server poll,
and send the ClearPasscode command with the Unlock Token. At this
point, the device is unlocked, and all protected data (email, account
passwords, etc.) are available to the attacker.
Looking ahead at what happens next, one might realize “But wait!
There’s no passcode left on the device. Won’t the victim know
something’s wrong?” So you set a bogus password, and replay the
TokenUpdate command to the device’s legitimate, real MDM server.
Now the MDM server has the current push and unlock tokens, and
when the user can’t get in, they simply call the help desk and get it
unlocked remotely. Chances are pretty good nobody will ever remember
this even happened....
Comentarios a estos manuales