Hacker News Reader

Comment by s_q_b | Hacker News Reader

iOS security is trivial to break if you have physical access to the device. TouchID (and passcodes) should be considered little more than a convenience, not a serious security measure.

View on HN

Really, how do you trivially break a passcode on an iOS device? There is a way that I know about, and it is very much non-trivial.

Just use brute force or dictionary attack over the wire. Given that most users use 4-digit pass codes, this can be done usually in minutes, almost always in less than an hour.

Or, if your target is paranoid and uses a very long passcode, target the charger rather than the device itself. iOS assumes any physical device to which it is connected when unlocked is secure. Replace the usb brick with a small computer (e.g. Raspberry Pi) in a convincing looking Apple-esque case. Then wait until your target plugs in his iDevice and unlocks it. You can then dump the drive, or side load malicious code.

> Just use brute force or dictionary attack over the wire. Given that most users use 4-digit pass codes, this can be done usually in minutes, almost always in less than an hour.

It's clear you've never actually attempted this. The timeout between passcode entries increases with the number of consecutive failures. Get 10 wrong in a row, and the device is wiped (if the user has chosen that option).

> Or, if your target is paranoid and uses a very long passcode, target the charger rather than the device itself. iOS assumes any physical device to which it is connected when unlocked is secure. Replace the usb brick with a small computer (e.g. Raspberry Pi) in a convincing looking Apple-esque case. Then wait until your target plugs in his iDevice and unlocks it. You can then dump the drive, or side load malicious code.

This no longer works on iOS 7. The user has to manually choose to trust the computer they're attached to prior to any communication going across the wire.

I'll ignore the needless snark.

> The timeout between passcode entries increases with the number of consecutive failures. Get 10 wrong in a row, and the device is wiped (if the user has chosen that option).

Only if you're typing in pass codes to the lock screen, which isn't how its done. An attacker would instead image the flash, grab the Dkey from effaceable storage, and decrypt the filesystem. Indeed this is exactly how professional iOS forensic analysis kits work. This will get you access to SMS, photos, and anything else that doesn't fall under Data Protection.

Data Protection, a second level of encryption that uses your passcode to generate keys, is only used on the keychain block and emails by default. To crack Data Protection, use brute force on the copied data, not on the iDevice itself.

>This no longer works on iOS 7. The user has to manually choose to trust the computer they're attached to prior to any communication going across the wire.

Cool, I didn't know that.

EDIT:

Here's a good overview: http://mobappsectriathlon.blogspot.com/2012/09/how-do-you-pr...

"Only if you're typing in pass codes to the lock screen, which isn't how its done. An attacker would instead image the flash, grab the Dkey from effaceable storage, and decrypt the filesystem. Indeed this is exactly how professional iOS forensic analysis kits work. This will get you access to SMS, photos, and anything else that doesn't fall under Data Protection."

Yep, as I suspected, you haven't done this ;) Please don't discuss how "simple" it is if you're getting your info from third parties. You can't image the flash. None of this works how you think it does, because the forensics toolkits left out a crucial detail in their marketing.

The dirty secret? You need a 0day bootrom exploit. The professional kits use the limera1n exploit, which was patched years ago.

I didn't say "simple." I said "trivial" :)

Nope, I've never done this live. For this I'm reliant upon what I've read. Feel free to tell me what's wrong. Stating how it works, or pointing the way to an accurate source, is infinitely more helpful than saying "you're wrong", even if it might feel satisfying.

Here's my understanding of how the initial loading works. BootROM uses a series of RSA validity checks on the chain of software components to load the RAMdisk (which is used for update in DFU mode.) To load your own RAMdisk, you need an exploit in bootROM (which are the same exploits used for jailbreaking, and thus of high value for the community to discover.)

I just told you. You need a bootrom exploit. That's the non-trivial part. Nobody has one, and they haven't since 2010. I mean, the NSA might, but the forensics companies don't, and there aren't any public ones. Hence, it's far from trivial.

Even with the multi-thousand dollar forensics kits, you cannot even begin a brute force PIN attack on any bootrom for any iphone or ipad still on sale. The last devices it worked on was iphone 4 (not 4S) and ipad 2.

You clearly know much more about iOS hacking than I do. It's well outside my area of expertise, and I'm grateful for the corrections. I learned a lot getting up to speed on how this actually works over the past couple days.

Pretending to have knowledge when you don't understand the fundamentals of the problem is both a good way to make yourself look foolish, and is certainly the cardinal sin in engineering. For that, I apologize.

For context, the reason I've been insistent is that there is a particular company that claims to be able to pull data from iPhone 5 and below in spite of the encryption. Whether this is true or not, I don't know, but I've heard it from a person I trust in mobile security.

If you keep up with the jailbreak hacking community (which I'm just now getting into), the Grugq (a fairly reputable source) posted on MuscleNerd's twitter that he's heard a private company has a new 0-day bootrom exploit, which would fit with the information I've heard.

Regardless, I should have just shut the f*ck up and let you teach me some science, instead of letting my competitive instincts lead me down a rabbit hole. I'll work on that.

Which "wire" allows you to brute force the passcode? Have you tried this, or are you repeating claims of others? Because I have a feeling that doesn't work like you think it does.

Your latter attack is an entirely different threat model, and can't be used on a stolen device.

On iOS 7 you have to explicitly trust a computer from the device before data is allowed over USB; before that it is in a charge only mode. To trust a computer you must unlock the device.

> iOS assumes any physical device to which it is connected when unlocked is secure

I thought this was fixed in iOS7?

Reply on news.ycombinator.com