
• No command authentication
–“Sign message” option not enforced
• SSL authentication
–Appears to accept any cert with ‘trusted’ root
–MITM likely possible
• Configuration not protected on filesystem
• Can’t forge APNS, so need to MITM
• Downgrade security requirements
• Multi-stage malware install
–Push provisioning profile
–Push webclip
–User clicks webclip & installs program
• Combine with social engineering encouragement
–Even easier with new InstallApplication command
• Denial of Service
The profile has the option to “sign messages,” but even when that’s set
the device accepts plain, unsigned commands with no real
authentication.
It also appears that there’s not much authentication for SSL -- it just
checks for a validly rooted cert. So MITM attacks are likely possible.
Finally, the MDM configuration is not protected by the FileProtection
system -- so it’s readable without the passcode. Several techniques
exist whereby a locked device can be booted into a special mode,
providing access to the filesystem, which means that MDM details can
be read, or potentially even changed.
You could downgrade security requirements on the device, such as
reducing passcode complexity requirements.
A multi-step attack could install a profile that includes a signed
provisioning profile, and a webclip placed on the user’s home screen.
When the user taps on the webclip, it installs a custom app, which might
include malware payloads.
Finally, great mayhem: If you can manage to position your MITM server
“just outside” the legitimate MDM server (that is, MITM at the enterprise
level, not just against a single targeted device) ... then you could
conceivably just intercept all the devices doing a daily checkin and
make them all..er...erase themselves.
Comentarios a estos manuales