Slashdot Mirror
iPhone's PIN-Based Security Transparent To Ubuntu
ndogg writes "Security experts found that the iPhone 3GS has very little security, even with a PIN set up. They plugged one into Ubuntu 10.04, and it was automounted with almost all of the iPhone's data exposed. This has been reported to Apple, but the company seems to be having difficulty reproducing the problem."
From TFA Apple could reproduce the described serious issue and believes to understand why this can happen but cannot provide timing or further details on the release of a fix.
I am Slashdot. Are you Slashdot as well?
Bernd Marienfeldt updated his blog saying Apple is now able to reproduce the problem and believes they know the cause, but no timing on fix release.
They're not a block device, so you can't mount their filesystem as such. Instead, they're effectively network drives: the proprietary AFC file transfer protocol tunneled over a hugely mutilated version of TCP stuffed into USB packets. Which you can mount under Linux, using FUSE and the appropriate apps (usbmuxd, libimobiledevice, and ifuse). I maintain usbmuxd.
Apparently Apple relies on security through obscurity here (only their apps are usually able to talk to an iDevice), and the actual protocols aren't secured.
Incidentally, this is where the term "jailbreaking" comes from: breaking out of the AFC filesystem jail (which is usually limited to the user's data partition). Jailbreaking's original feature was to introduce a secondary AFC share with root privileges on the root directory, and jailbreaks to this day still do. You can use ifuse --root under Linux to mount this secondary share.
But that's exactly how Apple is advertising the 3GS: http://www.apple.com/iphone/business/integration/#securing
I plugged my iPhone 3GS into my Ubuntu box. While it's true that Ubuntu did automount the iPhone, the only thing I can find that was exposed was my music, photos and podcasts.
I wasn't able to access email, contact info, or anything else on the phone. I did see the Application Archives, PublicStaging, Purchases, and Safari folders but they're empty. I have lots of email and contact info on the device - but it appears to be inaccessible via this method.
From Apple:
Apple iPhone Security Overview [1]:
Data Protection:
Protecting data stored on iPhone is important for any environment with a high level of sensitive corporate or customer information. In addition to encrypting data in trans-mission, iPhone 3GS provides hardware encryption for data stored on the device.
Encryption:
iPhone 3GS offers hardware-based encryption. iPhone 3GS hardware encryption uses AES 256 bit encoding to protect all data on the device. Encryption is always enabled, and cannot be disabled by users.
Correct. I wrote most of the usbmuxd implementation that we use on Linux as a clone of Apple's version. In fact, you should (as of yesterday) be able to compile libusbmuxd and libimobiledevice and maybe even ifuse (with macFUSE?) and use them together with Apple's usbmuxd on OSX to pull off this hack there. Heck, I think at least libusbmuxd and libimobiledevice should even build on Windows these days (Apple provides a Windows version of usbmuxd with iTunes).
The iPhone 3GS supposedly uses whole-disk encryption. This does squat when your USB comms protocol doesn't request authentication though, since you can pull the data off through the iPhone kernel's transparent decryption layer.
In other words, this hack has nothing to do with encryption and everything to do with an insecure protocol that makes no attempt to actually request PIN authentication before handing over all your data. Nobody expected your PIN to actually act as key for encryption anyway; that's impossible, as the iPhone has to be able to access your data even while locked.
The filesystem IS encrypted, but the OS happily decrypts everything for you without any form of authentication. That's the story here.
by Mike Buddha -- Someday the mountain might get him, but the law never will.
Here you have gone from saying there is no way to remove the storage (+5 Informative, haha), to saying there is a viable way to remove the storage. Kudos to you, sir. Now, where's my +5 Informative?
OK, upon further testing (I don't use a passcode myself so I never even looked into this) and getting some information from others, it looks like this isn't a total oversight on Apple's part, but it is a real bug that requires a specific sequence to trigger.
Here's how it's supposed to work:
The actual bug is that there's a race condition during boot. There's a window during which the lock code setting hasn't been read, during which the phone will accept pairing requests even though it shouldn't.
If you want to try it on Linux, do this:
Notice how the "slide to unlock" SpringBoard screen will not have yet appeared when this works. Once it does, the passcode has been configured and pairing will no longer work. On the latest version of ubuntu it tries to automount as soon as it sees the device, which makes this bug a lot more obvious.