The world awoke this morning to the news that the iPhone had been hacked.  Besides the fact that I hate the term “hacked”…it is used, incorrectly, ad nauseum.  But, I digress.  The annual Pwn2Own contest is one of the central focuses of the CanSecWest conference that is currently underway.  Up for grabs is a prize purse of $100,000, tempting hackers to pull out their tools and tricks to come up with the latest and greatest attacks against the world’s most popular electronic devices.

This conference is just one of a few places during the year where you’ll find some of the best and brightest minds, where it pertains to technology, all in the same room.  Many of these individuals should be considered reputable security researchers  that, while working tirelessly to undermine security mechanisms, do so in responsible ways that disclose their findings to the vendors before releasing them to the public.  Some of the participants are not quite as responsible.  Nevertheless, each and every participant of the Pwn2Own competition has worked, likely, months and months to uncover tiny little vulnerabilities that they may be able to leverage in front of the CanSecWest crowds in their bids to win the cash and notoriety.

The same story holds true for these two young fellows that “hacked” the iPhone in under 20 seconds.  What I would assume to be months and months of fuzzing, testing, sniffing, scripting, exploiting, then likely scrapping it all and starting over, led to the finding of a browser vulnerability in the iPhone that allowed them to jump outside of the browser’s application “sandbox” and access data that they shouldn’t otherwise be able to access.

I can already hear the moaning and sniffling from myiPhone-using friends.  I’ve also already heard too many say that it is more theoretical that this attack could ever work than not, because it still involves user intervention for it to be successful (check out some of the comments from the first link I provided).   That’s fine.  I understand where it comes from.  However, if someone were to ask me if I was surprised by this finding, I would say, definitively; “NO!”

Of course I’m not surprised that a browser exploit was successful and that it allowed the attacker to gain access to sensitive information.  This happens each and every single day in the PC world.  It has also already happened to BlackBerry, Android, Symbian and every other browser that has ever been used to access the Internet.  Browser exploits will always be a viable attack vector, as long as users continue to accept and follow unsolicited links.

In my opinion, the real problem for Apple and the iPhone is the fact that this particular browser exploit allowed the attackers to break out of the “application sandbox“, where they were able to then access and upload data from other areas of the device.  In this particular instance, once the attackers pointed the iPhone browser to their specially crafted web site, the attack forwards the contents of “the local SMS database of the phone to the server we control”.  The purpose of the “application sandbox” is to explicitly restrict one application from accessing data and resources that belong to another application without first requesting permission to do so, in the form of an API (application programming interface).

The other interesting piece of information that came out of this finding was that when the local SMS database had been obtained, SMS messages that a user would assume to have been deleted were still present in the database file.  If you’ll think back to last summer, the SMobile Global Threat Center published a lengthy whitepaper discussing the possibility of bypassing the backup encryption functionality built-in to iTunes.  One interesting piece of information that we found, through a series of tests to document and illustrate our process, was that deleted contacts still existed in raw format in the SQLite database file that functioned as the device’s address book.

What we were able to determine is that for some reason, the SQLite database that the iPhone uses has the ability to track changes to the database file.  In tracking those changes, the raw file “remembers” the data that was deleted.  Even though the deleted data is no longer visible in the database tables, as they are viewed with a SQLite database viewer, the data is still visible when viewing the raw file with a ‘cat’ or ‘grep’ command.   Check out the whitepaper for more information about this.

The two gentlemen that developed this attack went on to state that if the exploit were written to do so, it could also capture the full address book, any photos that exist on the device, music, and email.  Since I have not tested this functionality, I would venture a guess to say that since we know deleted SMS and deleted contacts could be obtained, that deleted emails can be obtained as well.   At least, I would think your deleted sexting pics and Rick Astley songs are safe for now.