Anatomy of an Apple theft protection bypass – and how to avoid it
A tiny but intriguing open source project entitled iCloudHacker attracted interest over the weekend.
The brashly-named project, which fits into just 79 lines of C code, boldly advertises that its purpose is to “bypass Apple’s theft protection.”
The code doesn’t really “hack iCloud” in any general sense: it targets Apple’s Lost Mode feature, intended to help you locate a lost iOS device or Mac by using iCloud as a message broker to tell the missing computer to call home.
But, as we shall see, there are nevertheless some interesting lessons we can learn here.
Apple’s Lost Mode
We’d love to present a screenshot sequence showing the Lost Mode process from “Go” to “Whoa,” using OS X in a virtual machine so that locking ourselves out would be an incidental inconvenience.
But that turned out to be tricky, because it seems that iCloud and virtual machines don’t mix:
Fortunately, both the purpose and function of Lost Mode are explained fairly clearly in Apple’s support knowledgebase.
From another iDevice, Mac or web browser, you can login to iCloud with your Apple ID, click on the device you’ve misplaced, and activate Lost Mode:
If the lost device is a Mac, then if is it still turned on and has internet access, iCloud will tell it to reboot. (If it is offline, it will lock up next time it comes online; if it never comes online again, you are unavoidably out of luck.)
Before rebooting, however, your Mac will reconfigure its boot-time firmware so that instead of loading OS X directly, you’ll start at a pre-boot prompt asking for a four-digit code:
The code is a so-called “system lock PIN,” and you choose it when you activate Lost Mode.
While you’re at the Lost Mode lock screen, you can’t activate the usual boot-time options to access your Mac via other means.
So you can’t reboot from USB, or mount the disk in Target Mode from another Mac over a FireWire or Thunderbolt connector.
Is a four-digit PIN enough?
A four-digit passcode is just about enough if you have a reliable way of locking up the protected content after a few failures.
ATMs (bank machines, cashpoints), for example, give you three goes at your PIN; then they eat your bank card, so you don’t get the chance to loop through the remaining 9997 codes until you hit pay dirt.
SIM cards in mobile phones lock up after three PIN errors, switching into PUK mode and giving you a further ten tries at an eight-digit code; then they block the SIM forever.
Lost Mode on your Mac doesn’t do that sort of lockout – it is just about feasible, if not exactly practicable, to sit there typing in every code in turn, trying to get a match.
→ You’d get there with patience, but it would be a frustrating and error-prone exercise for a human. Try typing 0000-[return]-0001-[return]-0002 and so on for a while. See how long you last before you make a mistake and type a wrong code, lose track of where you are, give up in frustration, or all of these.
Replacing the human element
To frustrate a brute force attack further, the Lost Mode lock screen makes you wait 60 seconds after five failures.
And if you fail at the sixth attempt, it makes you wait for five minutes before you can have your seventh try.
Then you’re back to the start of a seven-guess cycle.
In theory, then, assuming you can reliably try one passcode per second, plus six minutes of timeout in every seven tries, you should be able to get from 0000 to 9999 in just over 140 hours.
That’s six days, assuming you don’t stop to eat or sleep and make zero mistakes. (You can sleep if you work in a relay. But the attack can’t be parallelised, because you can only enter one passcode at a time.)
Get rid of the human element
What iCloudHacker does is to convert a tiny Arduino computer into an automated USB mouse and keyboard.
You then plug this electronic typist into a locked Mac, and let it tirelessly and unerringly plug away at typing typing typing 0000-[return]-0001-[return]-0002, so you don’t have to.
The coder made one significant optimisation, noticing that Apple’s pre-boot code doesn’t record that it is in the middle of a five-minute lockout.
If you take a short-cut by rebooting, you don’t end up back in a five-minute lockout; you return to the passcode prompt right away.
So iCloudHacker simply reboots the Mac after six failures, which brings it back to its seventh unlock prompt with much less than five minutes’ delay.
→ Ironically, iCloudHacker can’t reboot too soon, as it has no way of telling whether the previous guess actually worked or not. The compromise is to wait 45 seconds before trying to reboot, assuming that if the previous guess was successful, the [Reboot] button will no longer exist when the code tries to trigger it. There is a further 75 second delay to ensure that the reboot has time to complete, but the elapsed time between guesses is still well under five minutes.
With iCloudHacker, you can break in much faster than you could by hand; you don’t have to risk labouring all the way to 9999 to realise you mistyped one or more of the passcodes; and you can go to the beach while the cracking proceeds without you.
For what it’s worth, the author claims a maximum runtime of 60 hours, though my calculations put it at just under 90 hours, or close to four days:
Apple should fix this!
One online article has roundly taken Apple to task over this attack, suggesting that “it comes at a very bad time…, as just over a week ago there was a disastrous vulnerability in iOS and OSX regarding SSL.”
The authors go on to suggest that Apple should make a number of changes to the Lost Mode pre-boot screen on the Mac, such as:
- increasing the minimum number of digits to six;
- requiring the use of symbols and letters; and
- introducing a persistent record of previous unsuccessful attempts.
Actually, there’s a much better way to defend your lost Mac than by waiting for, or even asking, Apple to make these changes.
That’s because a Mac protected only by the Lost Mode screen can be taken over by an attacker in far less than four days anyway.
Unless your Mac is fully encrypted, which typically means using OS X’s built-in FileVault full-disk encryption (FDE) system, someone who has access to your Mac can simply put your hard disk into another computer (or a suitable drive enclosure) and read everything off it.
For a determined attacker, removing your hard disk and imaging it to process offline later has several criminal advantages:
- He needs minutes to remove the disk, rather than hours or days to guess the PIN.
- He doesn’t need to rely on the CPU in your Mac to have a try at “mining” the data stored on it.
- He can arrange for your Mac to be returned apparently still locked.
The third point is a tricky one: if you have Lost Moded your Mac, but it wasn’t encrypted, then if you get it back apparently safe and sound….
…you simply won’t know whether someone else has your data or not, and you may be inclined to assume they don’t, because the lock will still be in place.
→ Take at look at this article for a fascinating approach to tamper detection, using glitter nail polish and some tricks from astronomy to help you spot when your “safe and sound” computer hardware isn’t.
FDE – don’t leave home without it
The solution is simple.
Don’t leave home without full-disk encryption (FDE) activated.
If your disk is encrypted, then getting past the Lost Mode bootup lock screen only gets an attacker to the next stage, where he needs to enter your full OS X password to go any further.
In our opinion, many of the fears that people seem to have of FDE are misguided.
- On a modern Mac, we don’t think you’ll be able to come up with an objective measurement that your computer is slower due to the overhead of encryption.
- We don’t think you’ll forget your password very often, in the same way that you very rarely lock your car keys in the boot (trunk).
- We don’t think you’ll find it terribly hard to write down the 24-character recovery key on piece of paper and lock it up at home, just in case.
In a corporate environment, Apple’s FileVault component can be managed, along with its Windows counterpart, Microsoft’s Bitlocker, by tools such as Sophos’s own SafeGuard.
That gives IT departments confidence that forgetful users can be safely assisted to get back into their Macs, and that employees who depart in a hurry can’t leave the company locked out from its own data.
Incidentally, recovery-type access using FileVault and products like Sophos SafeGuard does not rely on any kind of backdoor, but rather on a set of managable and auditable front doors.
That’s because FileVault allows each encrypted Mac to be setup up so it can be unlocked by one or more of:
- Users who supply their regular OS X password.
- Users entering their personal 24-character recovery key.
- Authorised IT staffers with access to the appropriate corporate recovery key.
You can even store your recovery key with Apple, if that sort of thing sits comfortably with you.
But you don’t need to trust Apple with the keys to your castle: we suggest simply writing down the recovery key on a piece of paper.
Then keep the paper under lock-and-key, old style.
Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/NA7LcVbbNtU/