Last time we explored how an incorrect time setting could expose your pictures on a locked iPhone.  Today we’ll have a bit more fun.

Often when doing security work, you’re happy if you manage to leak just a single bit (yes, one binary digit) of encrypted material.  That one bit could be the tip of the iceberg, so to speak, which might lead to more secrets underneath.

Lets see how many bits of personal information we can gather from a locked, passcode-protected iPhone 4, without jailbreaking or using any special tools?

Below is a screenshot of my iPhone’s lock setup screen.  The settings are rather conservative: a long passcode is required immediately; and Voice Dial is DISABLED (when the screen is locked).

Passcode Lock setup screen

Note: I’m using an iPhone 4 (not 4s) with vanilla iOS 5.0.1 (the latest at this time).  I do not have Siri on this phone.

When the iPhone 3GS first came out, many were surprised that Voice Dial was enabled by default on their locked iPhones (and similarly, with Siri on the 4s).  So for our exercise today, we made sure Voice Dial is turned off.

Voice dialing is accessed by long-pressing the phone’s home button.  Again I’ve disabled voice dialing, but a fine print on the setup screen above notes that “iPod Voice Control is always enabled” so it can still be used to play songs, etc.

Can we trick this restricted Voice Control to leak some private info, and perhaps trick it to make calls for us?  (Yes, we can!)

First let’s see how the Voice Dial restriction works.  I lock my phone, then long-press the home button until Voice Control appears.  I command it, “call <Alice>”.  The phone responds with “Voice Dialing is disabled“.   As it should.  All good, right?

Voice Control screen

Now “slide to unlock” but instead of entering the passcode, hit the “Emergency Call” button (bottom-left).  We get this special emergency call screen:

Emergency Call screen

With this screen showing, I again bring up Voice Control, and repeat, “call <Alice>”.  This time the phone responds with “No match found“.  Hmm, different!!

Actually, that response in itself, my friends, is already a leak.  Voice Control reveals that I don’t have a contact named “Alice” in my Contacts.  One leaked privacy bit.

Just to test, let’s try with someone who’s actually in my address book, my friend Wayland.  I bring up Voice Control again from the Emergency Call screen and say “call <Wayland>”.

(Locked) Voice Control calling Wayland

Wow, it tries to dial out!  Although the call fails to actually connect, the screen reveals Wayland’s full name and that I have his mobile number.  Not a huge deal, but more leaked bits!

At this point, it’s easy for anyone to enumerate through the Contacts by simply trying common first names like Adam, Bob, Charles, etc.  Let’s see how far we can go.

Here’s an example when I say, “call <Lisa>”:

Multiple matches shown for the name Lisa

Voice Control leaks that I have two Lisas in my contact list, one Lisa Atkins and one Lisa Klein**.  Repeating with “call <Lisa Klein>” yields further information:

Multiple numbers listed for Lisa Klein

Now Voice Control leaks that I have two numbers for Lisa Klein: her “mobile” and another number at the “love shack“.  Had this been my jealous girlfriend probing my locked phone, I would’ve been totally busted!

Remember, we’re getting all this info from a locked phone with Voice Dial explicitly disabled.

So far we’ve only enumerated through the Contacts.  Can we actually complete a call from the locked phone?  With FaceTime, the answer is yes!

Again starting from the Emergency Call screen, this time I say, “FaceTime <Lisa Klein>”.  And Voice Control dutifully connects, to the love shack, with full two-way video live streaming.  Yikes!  Not what I’d expect from my locked phone!

Lisa please don’t answer…

During testing, the FaceTime calls from my locked iPhone successfully connected and I was able to see + converse with the other party.  The test calls disconnected after a few minutes, but those disconnections might be due to the spotty internet service here at my hotel in Medellín, Colombia.

Bottom line:  We’re able to trick Voice Control to enumerate through the private address book and make live FaceTime video calls on a locked iPhone 4, even with Voice Dial specifically disabled in the settings.

**Some names faked to protect the innocent.

Special thanks to Wayland Chan for helping me test FaceTime.

p.s. I have not tested this issue on the iPhone 3GS, which has Voice Control but lacks FaceTime.

UPDATE: Feb 8, 2012:  While the iPhone attempts to connect the FaceTime call, it will show the contact’s profile picture if any.  So a stranger using your iPhone could possibly see pictures of your contacts even if they do not have FaceTime enabled.

UPDATE: Feb 9, 2012: CNET also tested the bug on the iPhone 3GS and the iPhone 4S.

Recently I took advantage of great wi-fi in Costa Rica to finally upgrade my iPhone 4 to iOS 5.   Double-clicking the home button now allows one to quickly access the Camera app even from a locked phone:

The camera icon (bottom-right) is now accessible from a locked iPhone

Since the camera is locked, Camera app has a smart feature barring access to the iPhone’s album.  You can only see pictures taken from the current (locked) session.

As an aside, I thought I noticed a glitch whereby I could completely bypass the passcode lock, but turns out it’s just poor UI from Apple.  (There’s a state where the phone is locked but a passcode is not yet required, and the UI during this period can be misleading.)   I changed the passcode setting to “immediate” after that.

UI barring access to album pictures from locked phone

While researching the above “glitch”, I was intrigued at how the Camera app’s album manager was able to segregate your “protected” images vs. the ones from the current session.  It’s like a “jail” for images.  I wondered if I could break out of this image jail.

Turns out Apple’s restriction is just a simple filter based on the timestamp when the Camera app was invoked.  You’re allowed to see all images with a timestamp greater than this invocation time.  Yet that leads to an immediate hole: if your iPhone’s clock ever rolls back, then all images with timestamps newer than your iPhone’s clock will be viewable from your locked phone.

But time always moves forward, right? Why would your phone’s clock ever roll backwards?

• It could be due to user error.  E.g., maybe while traveling across timezones you accidentally set the iPhone’s date or time incorrectly (rather than simply resetting the timezone).   If you set the clock ahead of what it’s supposed to be, then this vulnerability will appear when you reset to the correct time.  If you accidentally set the clock to the past, then your images will immediately become unprotected.
• It could be an iPhone glitch.  E.g., a software or hardware issue could reset your iPhone’s clock to epoch time — iPhone’s “zero” time at midnight January 1, 2001.  In this case all your images are exposed.
• It could be an infrastructure error.  E.g., if you automatically sync from a erroneous external time source (cell phone company, etc.)

I don’t think normal (non-Apple) apps can change the iPhone’s clock, but if it can then that could be another possible source of rollback.

This vulnerability is simple to test.  Just set your iPhone’s clock to a time in the past (say, in 2010).  Then access the Camera while your phone is still locked.  Lo-and-behold, you’ll be able to see all your “protected” images.

The point to all this is that Apple should not rely on a simple timestamp to restrict image access.  Changing the iPhone’s clock — forwards or backwards — should not affect its security.  We can’t guarantee the clock will always monotonically more forward, and when it doesn’t, the system should fail-secure.

In the big picture, if real “bad guys” have physical access to your phone, then the game is over already.  However, as I wrote previously, defense-in-depth is a basic concept which should always be applied.

In various occasions I’ve advised clients to secure their time servers, etc., in the context of esoteric cryptographic attacks, audit logging, and other protocols which depend on accurate timekeeping.  I’m a bit amused that the iPhone is vulnerable to a simple time change.

The ICU APIs are in C/C++ however, not Objective-C.   Fear not, RegexKitLite to the rescue.   This small library has done all the hard work of adding regex methods to NSString.  RegexKitLite is small, thread-safe, and quite fast.  It simply links to ICU –  unlike its bigger brother, RegexKit, which must be compiled against PCRE.

RegexKitLite is also easy to use:

#import "RegexKitLite.h"
NSString * foo = @"some string to search on";
NSString * regex = @"^(.+?)\s";
NSLog(@"Match: %@", [foo stringByMatching:regex capture:1]);

Then just link with -licucore and that’s it!!

Note: In Xcode I simply added -licucore to the “Other Linker Flags” in my project’s build configuration.  Maybe there’s a “better” way of doing this but this method works for me.