25C3: Cracks in the iPhone security architecture

At the 25th Chaos Communication Congress (25C3) members of the iPhone Dev hacker team offered a glimpse of their ongoing efforts to get around the SIM lock on Apple's smart-phone. The security experts still have the same basic goals: to remove the provider lock required by the California computer manufacturer and to make it possible to run code and programs of choice on the iPhone. The hackers have remained true to their goal of releasing an easy-to-use software tool for breaking the provider lock by year's end. Their Saturday evening presentation did not, however, fulfil the hope, embraced by the gathering of creative and critical security testers, of being able to test drive a user-friendly application.

The colourful crew, with members from Belgium, Germany, France, the UK, Israel, the US, and other countries, met each other for the first time in real life at the hacker conference. Their usual virtual meeting places are chat channels on the internet. The group was formed in June of 2007, just a few days before the iPhone officially went to market. Only a few months later, the crew had already produced its first open source program for cracking the SIM lock on first generation devices. However, security on the iPhone 3G is harder to crack and the group is still searching for a long-term solution.

Team representative "Planetbeing" described vulnerabilities on the software side of the iPhone. The digital internals of the device are essentially subdivided into system and user partitions. Only the latter can be written to. Third-party applications are permitted to run in the designated partition only if they carry an Apple signature. This checksum is only evaluated when the application is started. A slight problem for Apple was discovered in its somewhat optimistically named "Secure iBoot" device startup procedure. A program called LLB, stored on a flash memory card, was loaded from Secure iBoot. LLB then activated another bootloader, without having its signature checked.

According to Planetbeing, other vulnerabilities in the data transfer interfaces can be used to trigger a memory overflow, creating a hole through which specially crafted LLB code can be injected. Finally, iTunes was used to install a home made version of the firmware on the iPhone. Early versions of the smart-phone blindly trusted Apple's music program. Hackers stumbled upon easy methods of accessing the administrator level, which even allowed them to install Linux on the device.

"MuscleNerd" discussed additional details, including the difficulties associated with the next generation iPhones. True to his nickname, the muscle-shirt clad hacker sat at the podium and explained that in the original version of the smart-phone an interactive service mode for firmware updates was often accessible. With the 3G device the process was significantly more complicated and involved several sub-steps secured with encryption. However, he explained that being able to manipulate the baseband firmware was important, because that was where the SIM lock was ultimately carried out. He said that in an earlier version of the device the crypto implementation had been vulnerable to a "Bleichenbacher attack" which could be used to install a manipulated bootloader.

MuscleNerd said that he'd made use of an application called JerrySIM that allows code to be executed following a memory overflow. Apple had caught wind of this application and patched the vulnerability, but according to MuscleNerd, not before a comprehensive reverse engineering effort targeting second generation firmware was complete. He explained that the second generation had generally required much more hacking than the first. Although some previous custom code can still be used, currently, the hacker believes, that every new baseband version will require a slightly modified version of the software used to exploit the security holes. The announced application yellowsn0w, which MuscleNerd demonstrates on the experiment team's blog, is still not a real long-term solution. A bootrom code is still needed in order to create simple, long-term exploits for cracking the "chain of trust" in the device.

(djwm)