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.”
That description might be gilding refined gold (or painting the lily) just a bit.
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?
Maybe.
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.
Notably:
- 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.
I’m an 81 yr old widower, retired and living alone in a single dwelling that is locked when I’m absent. My iMac is only used by me, obviously never leaves the house and is secured by a master password on bootup or if awakened from sleep. I am secure from internet incursion by Sophos Antivirus ver 9.0.8 engine 3.50.1. Would you still advise that I encrypt my HD in view of what I consider a high security situation already?
I think the question is…
…why not? It means that if burglars should ever make off with it, they (or whoever they sell it on to) can’t do anything with the data on it. It also means if you ever want to replace or upgrade the hard disk, you can be more certain, before you retire the old one, that it’s safe to recycle or dispose of.
Your data is clearly at much lower risk than someone with a laptop who is regularly on the road with it, but since FileVault is there for the taking, what’s not to like?
The biggest issue with encryption as always is file corruption. Running a program such as checkdisk (cmd chkdsk) on a non-encrypted machine works wonders with file system and file corruption.
Now, try to run this same command on an encrypted machine. Now if you have a mac you probably also have an Apple TimeCapsule. I could be mistaken here but I do not believe Apple Timemachine and TimeCapsule encrypt their file backups for OSX.
The problem is that you always have to be aware and cognizant of the weakest link in the chain of protecting your information. If your Apple TimeCapsule is stolen, it really does not matter if you encrypted your disk or not….
CHKDSK – which doesn’t exist on the Mac, of course – fixes problems with the regular filing system *inside* the encrypted layer. The encryption is effectively irrelevant (and invisible) to CHKDSK.
If you can’t mount an encrypted partition at all, you probably have problems well beyond what CHKDSK could have fixed, anyway.
As for Time Machine encryption…just tick the “Encrypt backups” option when you choose your backup device. You can’t miss it 🙂
As if I didn’t have enough to worry about!! But good on you!
Is there really no any malware that can attack iOS platform?
According to Naked Security 75% of android devices are compromised so it is really hard to belive that IPad/Iphone owners can enjoy worry free internet surfing. Those malware creators are so smart I just can not belive thay would not try to exploit idevices. Personally I would be much happier to see Sophos app on my iPad?
Apple won’t allow App Store iOS apps to do what’s needed to produce a proper preventative anti-virus, and only App Store apps are allowed on iDevices.
Those limitations reduce the harm regular apps can do – but there are no exemptions for security vendors. So there is no equivalent of our Android anti-virus in the App Store.
Of course, the flip side of this tight control by Apple has been to keep iOS pretty much malware-free, at least so far.
(No malware doesn’t mean “worry free” surfing. Scams, hoaxes, phishing…all of those can propagate via the web alone. So you still need your wits about you, as on any computer!)
Having used Sophos SafeGuard, File Vault and File Vault 2 ~ SafeGuard was the only product that didn’t hose the system.
Even using File Vault 2, after a few months a simple corrupt preference (something small and benign), and you can’t boot into the system… all is lost. Must spend the hours reformatting to factory default.
I’d love to go back to FileVault (as running Mavericks offers little in the way alternatives) ~ yet bit so many times by having to reformat the drive.
What are your thoughts on keeping sensitive information on encrypted DMGs, and using other security measures (sans FileVault)?