Apple iOS Hardware Assisted Screenlock Bruteforce | Hacker News Reader

Apple iOS Hardware Assisted Screenlock Bruteforce

blog.mdsec.co.uk

214 pointsallending101 comments

"Our initial analysis indicates that the IP Box is able to bypass this restriction by connecting directly to the iPhone’s power source and aggressively cutting the power after each failed PIN attempt, but before the attempt has been synchronized to flash memory"

My guess is that Apple is only synchronizing after the failure animation completes. Should be easy to patch.

I highly doubt it. And I doubt they will patch it.

Why would you doubt they would patch it? Everything indicates that Apple takes this type of security somewhat seriously.

Yeah Apple is pretty serious on security honestly. I expect to see a patch or write up here shortly.

Looks like it might have been patched already. FTA:

>Further research suggests this could be the issue detailed in CVE-2014-4451 but this has yet to be confirmed. We plan to test the same attack on an 8.2 device and will update with our progress.

The article was posted a week ago, but there are no updates about iOS 8.2 as of today and since it shouldn't be too long to just upgrade iOS and see if after 10 attempts the device gets wiped I'm guessing that the fix for CVE-2014-4451 actually patched this but the news wasn't as interesting as it would've been "iOS 8.2 vulnerable too" to update the post with

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-4451

https://www.youtube.com/watch?v=2Bok9Zgas6g

It was fixed in 8.1.1

So it cuts power before the iPhone can store that a failed attempt occurred. It's such a simple, stupid, wonderful idea. I love it. Kudos to whoever came up with it.

This is not a particularly new attack. It's been used for years against simpler devices, especially where you can access the flash chip and force it's write protect on.

It's not really an "attack", but old Pokemon games on Gameboy and Gameboy Colour used the same technique for cloning items and pokemon - you send a pokemon to a friend, and switch off the power before the game has a chance to save successfully afterwards - presto, now both you and your friend have the sent pokemon.

Oh, I remember that. I think I did it by moving the Pokemon to the PC.

Wouldn't you risk corrupting the file if you cut power while saving?

Yep, there was a risk. But with pokemon games they would say "saving game now" but the actual process didn't start until the whole text appeared on the screen - so as soon as the letters started appearing you could kill the power and it was fine.

Even on more modern Pokemon systems (nintendo DS) you could upload a pokemon to the cloud servers and watch the network traffic lights on your router. Shut off your DS as soon as your pokemon had been uploaded and when you start up your game again, the pokemon is still in your party. It's also in the cloud so you connect and pull your clone off the server.

Somehow I doubt the nintendo developers were worried about ACID Pokemon transfers :)

Or just deposit it into a box, change boxes, and turn it off during the saving worked on Gen 2 for cloning.

In high school we found one even better than that. If you unplugged the coke machine after choosing a soda but before it was delivered then it spit out the soda and still remembered your money when you plugged it back in. It's interesting to see that power off events are still mostly untested even on Apple devices.

We used to do the same thing in 9th grade. Eventually teachers had to go and supervise students who used a vending machine and only they had keys that would turn them on. I also used fake change from one of those "my first cash register" toys as a kid to buy pencils in elementary school. Those eventually got removed too haha.

Just because others commented.

When BT Cellnet mobiles came out.

http://i.ebayimg.com/images/i/351317080153-0-1/s-l1000.jpg

If sending an SMS, you pulled out the battery, you'd get it for free, a bit annoying but still a cool trick when you were on PAYG.

This is a legit issue, and you can definitely expect it to be patched quite soon. Not sure how/why someone would think it wouldn't get patched.

Many, many enterprises bet their data on passcodes combined with the 10-guess wipe defense. You can bet that they've already called Apple many times about this.

It'll be patched very soon.

Enterprise can mandate complex pass codes, not the 4 digit pins. The 11 hour number will increase rapidly with complex codes. However I assume they will still want the wipe feature to actually work.

"As such, each PIN entry takes approximately 40 seconds, meaning that it would take up to ~111 hours to bruteforce a 4 digit PIN"

This is where a longer pass-code + TouchID is valuable.

I have a 9-digit PIN. So I guess I'm immune from this type of attack? (In any reasonable time, at least.)

With this particular tool, probably. You're a lot better off using an alphanumeric passcode and Touch ID though.

Strike out the Touch ID.

Without the touch ID, a long password is too inconvenient.

Care to explain why? I know it's possible to clone someone's fingerprint, but that's doable in nearly clinical settings, where you have a very,very clear image of the fingerprint in the first place - a phone stolen out of a pocket or handbag is not going to have them.

The demonstration by starbug, who won the bounty for cracking TouchID, was made using a fingerprint taken from the screen.

https://vimeo.com/75324765

It's not too complicated, see starbugs latest talk:

https://media.ccc.de/browse/congress/2014/31c3_-_6450_-_de_-...

(Download MP4 and use a desktop player, it contains an English translation)

In that talk he even describes, how they got the fingerprint from the German Secretary of Defense from a photograph taken in a distance of 3m at a press conference.

If your fingerprint is your password, it's much easier for authorities to get it. It becomes essentially impossible to refuse to divulge your password.

If you're only concerned about thieves, sure, TouchID is probably fine.

You need the passcode on reboot of the device anyway. I'd rather have a strong passcode and Touch ID than a weak passcode that's easily broken. A strong password and no Touch ID is almost completely unusable.

A nine digit numeric pin would take at most 18 weeks to crack at 40 seconds per attempt.

edit: at most 18 weeks; actual time will probably be shorter

I don't think so. My math says it would be more like 1268 years.

1268 years is correct.

You're right--not sure how I screwed that up.

Can someone explain to me how the power cut off works? The battery can't be removed... And something like this requires precision timing. How can they cut it off then turn it back on without charging the battery? Furthermore, how can it be done every 10 seconds? My iPhone 6 takes longer to boot from scratch.

You have to open the phone and connect the device so it can cut power. The boot time is amortized across the 9 passcode attempts for each cycle.

The obvious fix is to write the attempt count first, before even bothering to check if the PIN is correct. The flash on iOS devices is a bit slow but not slow enough to matter in this case.

But wouldn't there be a write to flash after each attempt? This would mean that you just guess 9 times, cut power, then you can repeat the whole process again?

You don't even need a fancy machine to guess the most common pins if that's the case! Just let the battery run out and start again. Seems like a really poor setup if that's true.

Article mentions brute forcing would take ~111 hrs. That looks like it's (10^4 * 40) / (60*60) which would be the maximum time needed to brute force.

Note for those not good at dividing hours by 24 in your head: 111 hrs is 4.65 days

23.335% of pin codes can be guessed in under 10 attempts.

Source: http://www.datagenetics.com/blog/september32012/

Based on that list, 18.61% of pin codes can be guessed before the 3 attempt lockout, no fancy power tricks required.

Yeah, a lot of people are hung up on the "takes 4 days to brute force" part.

I'd be willing to guess that most phones have a passcode that's like "1234", or between the numbers 1900 and 2100. 300 tries can easily get a vast majority of 4 digit passcodes, let alone 4 days' worth of tries.

You don't have to guess, the post you're replying to showed 11% of users had 1234 as their PIN, and has a detailed analysis of common patterns, such as birth years and PIN pad patterns (2580). You should read it, it's interesting.

From the article:

> Utterly staggering at the lack of imagination ... nearly 11% of the 3.4 million passwords are 1234 !!!

Not so staggering. Those people probably did not want a PIN to begin with. I know someone with the PIN 1234. Why does she have a PIN at all? Because the phone requires it to store Exchange credentials (if I remember correctly). I've suggested it changing it to 1111 because it's even faster to type, but she never got around to it.

I too have a pattern lock, the simplest one I could come up with. Easily broken. Why? It's required to store VPN credentials in Android.

And there is a second advantage: by trying a PIN, even a default one, you are gaining unauthorized access to an automated system. This is illegal by Dutch law, even if the only security was a warning message on the lock screen saying "Do not unlock."

I believe it's up to the Exchange admin to require a PIN or remote wipe capability, so it will vary from site to site.

One workaround is to use IMAP, if available (also up to the admin), but you lose the calendar capability, which is arguably the killer feature of Exchange.

Another workaround is to increase the time your phone will require a password after inactivity to something large, like 30 minutes or an hour. You still have to enter a PIN once in a while, but it's more convenient and will still be effective in some cases when lost or stolen.

For a while I had a my iPhone set to 0000 just so I wouldn't have to enter my strong 16 character Apple ID password every time I entered "find my friends".

Now that I have TouchID I can use a strong password for unlock since I don't have to enter it every 30 seconds

That's right, so realistically the average case is somewhere around 55 hours.

I wonder how much that is reduced by starting off with more likely combinations, e.g. "1111", "1234", "9999".

And that's the benefit of something like TouchID. Since you rarely have to enter your full password (after restart or too many TouchID failures) it's much easier to use a longer or more complex password than 4 digits. Even a simple dictionary attack would take a very long time at one attempt every 40s.

"rarely"?

Well, I'll say I don't have to punch in my 4 digit PIN much, perhaps that's what you meant. But the 'full password' - the Apple ID password - I have to put that in all the time. The touchID verification for apple store downloads seems to only hold for an hour or so, then I gotta punch in the full painful password again... :(

I believe the mechanisms are something like:

1) ask for password on phone reset

2) ask for password if it hasn't been used for an authentication for ~72 hours

something about people forgetting their passwords if they never got asked for them at all

72 hours is crazy - do they expect people to be buying stuff all the time?

What's crappy about it is that they force a moderately complex password strength which is much harder to input on a touch screen keyboard. I'm constantly having to enter that - the 'touch id' for using the apple store, to me, is effectively uselesss. For unlocking the device, it's fine.

That happens if you turn off your device. There might be a setting or option you might need to enable. After I've restarted, I enter the password once in the store, and after that, touch ID works.

In the US you can be compelled by law enforcement to provide your fingerprint. Not so with passwords and passcodes.

> I wonder how much that is reduced by starting off with more likely combinations, e.g. "1111", "1234", "9999".

Doing a graphical integration on

http://www.datagenetics.com/blog/september32012/c.png

(source: http://www.datagenetics.com/blog/september32012/)

I get ~28 hours.

And that's based on phones that don't take 3 minutes to boot up.. Oh hi old phone :)

Why does iOS accept entry of that PIN over the cable and not require it to be "input" on the screen?

Probably for compatibility with peripheral devices.

Including accessibility for blind users, I assume. Touchscreens are not great input devices if you can't see what's on them or whether you got your finger on the right button.

In which case you could still either manually do it (should take no more than a day), or create quite easily a lego-mindstorm or similar device to click on all the combinations "on the screen".

I have a bluetooth keyboard cover for my ipad - I can type the PIN using the keyboard, no need to touch the screen - it's actually very convenient.

It's so iTunes can unlock the device.

iTunes unlock is actually done with a pre shared key during sync.

Accessibility.

Well, one can still remote wipe if the phone is lost. So, while this may still be an issue, it's not as bad as what it would have been if that weren't an option..

Only if the phone has a signal right?

Yep. My dad got his phone stolen at the gym. He called me within 10 minutes of it being stolen and I logged into his account to wipe it. Not only was it "offline" never to be returned online, he had within a day a (thankfully blocked) attempt to login to his gmail from a nearby city. They must turned it off, have removed the SIM card, and then managed to guess his pin and get credentials off it. Scary.

Was the pin hard to guess?

No, unfortunately. And I've told my parents for years to change that. They finally have now.

The reality is most people aren't security conscious until AFTER something bad happens, even if you warn them ahead of time. But this also seems to be human nature. Life is complicated enough that we try to balance things towards convenient until it's clear something has to change. This will happen with global warming, industrial foods, water policy, oil-based economies, all-your-life-online etc just like it has with lead, atomic/chemical weapons, and the lack of regulatory bodies.

Sounds like a targeted attack on your dad in this case.

Although he can't figure out who it would be, especially in that city.

The police, btw, wouldn't do anything. We even have the person's IP address on Comcast, so it's easy for law to find out the address of the actual thief. They won't waste their time on mobile theft, despite the fact that he lives in a small rich town that doesn't really have any crime!

If he owns property or stock - watch his accounts closely. It could be a sophisticated attack paired with identity theft. Location doesn't matter to crooks.

I think "rich" could be the case.

OP here. Devious. Cuts off the power source after failed attempts to get around 10 attempts restriction.

Old smart card hacker's trick, surprised Apple didn't defend against it. Of course, it's not enough to delay reporting success or failure until the counter is updated, you've got to make sure there's no side channel that could leak that information early as well.

couldn't you just use a capacitor to give you a few seconds of power after the supply is cut?

Or just write the attempt count and flush to flash even before checking whether the code is correct? The count can always be updated to zero once it is determined that the code is right.

That would mean a lot of excess writes given the most common use case of the user putting the password in the first time.

How large is the write? A byte? Or 8 bytes for one 64-bit word? I can't imagine that would impact the user in any way, unless I'm not thinking this through...

Flash writes in full blocks, so it would be 4k with most recent flash chips

From a back of the envelope calculation - given a 10,000 write cycle budget for 16 GB of flash memory and a 512 KB block size (all worst case scenarios), you are looking at 300 million writes before the flash memory starts to fail.

I probably unlock my phone 50 times a day (incurring 100 writes under my scheme), and that is negligible in the grand scheme of things.

Let's assume that you're correct, that the most common case is the user putting in the password correctly the first time.

Just to get some other numbers, let's assume I sleep 7 hours a day on average, and look at my phone every 5 minutes the rest of the day.

Then we're looking at 204 extra writes a day (17 * 12), and ~74.5k extra writes a year, and ~150k writes over the lifetime of the phone.

This isn't a negligible change, but seems within the acceptable number of writes for the phone to perform over its lifetime to properly implement a key piece of security.

I'd disagree that it's needed. An explicit sync() before returning a notification that the password is invalid would stop this attack as well, and again wouldn't require any additional writes for the most common case of the user entering in the password correctly.

They don't need to write anything. They just need to impose an increasing delay after every failure when the code is being supplied via USB or bluetooth. First failure, wait two seconds, fifth failure wait 30 seconds, eigth failure wait 90 seconds.

If they really wanted to write it to flash, they could make it so that the first failure isn't written at all, the second has a 50% chance, the third a 100% chance.

Or make it so that if the device has only been running a short period of time, then all failures require a thirty second wait until you can retry.

There are plenty of ways to make it impractical without necessarily reducing the lifetime of the device.

iOS already tracks time since power on IIRC, so if this produces too many writes couldn't you write out to flash first if the phone was last powered on within the last hour (for example)? It wouldn't completely fix the issue, but would vastly increase the time required.

That being said, I can't imagine that flushing to flash each time would substantially reduce its lifetime.

> iOS already tracks time since power on IIRC,

Records it in photo EXIF data, for some reason.

So: don't write before the first check, write before subsequent checks.

In this attack there is no subsequent check.

They also get around the increasing delay enforced after a certain number of failures, to slow down bruteforce attacks.

Can this be used by thieves to unlock iPhones in the Find My iPhone "Lost Mode"?

Perversely, "Lost Mode" incentivize thieves to do whatever necessary to unlock your phone, since they can't just wipe it and resell it. Apparently it's common for thieves to phish the contact phone number displayed on a "Lost Mode" iPhone: http://www.symantec.com/connect/blogs/cybercriminals-phish-i...

A five-letter password is not much harder/slower to type than a 4-digit PIN, but makes this attack entirely impractical.

Even using just lowercase letters, the maximum time expands from 111 hours to about 132,000 hours (15 years) per passcode.

Going to six letters expands it to about 390 years.

Out of curiosity, anybody know the resolution of the fingerprint reader? I'm assuming it's some kind nxm scanner that could also be brute forced if needed, just take longer.

TouchID doesn't work when the phone is first booted. You must sign in with your pin or password (whichever is setup) once first to'unlock' it.

But it also has a lockout. If you mess up too many times (5-10?) then TouchID gets temporarily disabled and you must login once with pin/password as if the phone was reset.

That means their 'reboot the phone' attack is worthless against TouchID. By the time you figure out the password you've already unlocked the phone and TouchID is no longer relevant to you unless you're somehow trying to reverse engineer someone's fingerprint.

> unless you're somehow trying to reverse engineer someone's fingerprint

Well yeah basically. I mean, it's just recognizing some pattern as "the fingerprint" right? So if you can replicate a matching pattern you can beat a fingerprint scanner. I'm just curious what resolution the scanner/recognizer pattern is at.

I'm assuming Apple uses some kind of capacitive sensor. From googling it looks like it's a 500ppi sensor. The sensor isn't even 1"x1", it's maybe 1/2"^2. Which gives us 62,500 "pixels" or whatever the sensing elements are called.

That's 2^62,500 (assuming the sensors are binary) combination. That's a big number, and probably uncrackable.

But maybe there's some fuzziness in the sensor or the software and the effective resolution is more like 100ppi. That's still a huge number (753 digits).

But then maybe you can apply some smart guesses or some reverse engineering and concentrate patterns in the middle of the sensor (where good contact might be made), maybe down to a 1/32" section. Now we're within brute force distance.

All you need now is a tool at that resolution to input fingerprint patterns, or just provide signals to the sensor lines.

After all, this is possible [1], why not fingerprints?

1 - http://gizmodo.com/this-is-what-happens-when-you-reverse-eng...

You missed the important thing though - Touch ID has an attempt limit, so it only works something like five or ten times and then you need to enter the pin/passcode.

The attack in the article does not work to get around this, because Touch ID does not work at startup until you have entered the code.

So brute forcing it is not going to work unless you have the passcode, in which case brute forcing it isn't super useful.

Touch ID stops working after three missed attempts. Not much margin for error.

>unless you're somehow trying to reverse engineer someone's fingerprint

Reverse engineering someone's fingerprint can be done from a simple photo [0], as demonstrated in this talk. [1]

[0] http://m.bbc.com/news/technology-30623611 [1] https://www.youtube.com/watch?v=YE1EoxKV53w&t=1464

Anyone know of such a hack on Android phones?

It takes over 100 hours to brute force a 4 digit PIN.. I'm not impressed. For further security, everyone should use a longer PIN along with Touch ID, that is what I do.

Quick tip: If you turn off Simple Passcode (the 4-digit pin) and your Passcode is all numbers then you will be presented with a number pad. It's not as secure as numbers and letters but I find it much easier to type in a long number.

Good catch! So, if I choose 8 random digits, it could take 132 years to break.

Interesting. I just turned off Simple Passcode as an experiment.

The number pad presented resembles a standard DTMF keypad. Which means that it also has all the letters on it. Some people might prefer using those to numbers. E.g. a long time ago a friend had a phone number of "tinyhat". Much easier for me to remember, even after nearly 40 years, than the 7 digits that translated to.

Reply on news.ycombinator.com