Let’s have a look at a sample vulnerability, which was discovered by the well known security researcher Char-lie Miller and published on the 7th of November. CharChar-lie discovered a flaw within the JavaScript engine “Nitro”
which allowed him to download and execute additional code from within a signed app. Nitro has special permis-sions, when run by Safari, that allow it to perform just-in-time (JIT) compilation of JavaScript code to native instructions and then execute them. The vulnerability af-fects all iOS versions, beginning with v4.3, where Nitro was introduced.
As a proof of concept, he developed harmless look-ing app called InstaStock and submitted it to the Apple’s App store review process, which it passed successfully.
Once installed and run on an iPhone, InstaStock down-loaded and executed additional code like playing a vid-eo from Rick Astley or opening a reverse shell, giving him access to the operating system. A video from Mill-er, showing his attack in action is available on Youtube (http://en.wikipedia.org/wiki/IOS_jailbreaking and http://
www.youtube.com/watch?v=ynTtuwQYNmk).
The InstaStock app was meanwhile removed from the AppStore by Apple. Apple also revoked Millers
devel-oper account as a result of his research activities. Be-cause application signing is one of the most important corner stones of iOS security, vulnerabilities like this do have very serious impact to the security of the iPhone platform.
Bypassing hardware Encryption
In the part about Data Security within this article, I de-scribed the encryption mechanisms implemented on the iPhone, which should protect against unauthorized access to the information stored on the device. Unfor-tunately there is a way to access the data stored on an iPhone, even without knowing the passcode. If an at-tacker has physical access to an iPhone, he can start a Boot-ROM attack against it (see box Jailbreak for de-tails) and install a SSH daemon.
Because the key for the hardware based encryption is located in memory and the device is still continuing to decrypt the data on the flash drive transparently, all files on the device are accessible via the SSH login and can be copied from the device.
Bypassing KeyChain encryption
But as we have learned before, the hardware based encryption is only one layer of defense of the iPhone.
Another one is the keychain. While an attacker can ac-cess and copy the KeyChain’s SQLite database file, he can’t simply access its content, because it is en-crypted with a different key than the one used for the drive encryption.
The way that researchers (Heider, Boll (Fraunhofer SIT)) figured out to access the encrypted content of the KeyChain is also based on a precondition given by a jailbreak. To understand the attack, we need a little more background on how access to the KeyChain is granted by the operating system.
Each application on an iOS device contains a unique application-identifier entitlement, which is added and digitally signed, before being submitted to the Apple App store. The keychain service controls the access of an application to the keychain, based on this unique en-titlement, and by default allows each app to only access its own data. In order to allow apps to share information between each other, Apple introduced the keychain-access-groups entitlement. If a developer for example, had developed App-A and App-B and wants both ap-ps to have access to each other’s keychain content, he had to assign App-A and App-B a shared keychain-access-group. When accessing the keychain with one of his apps, the developer had to specify which access group to use.
The way to read and write to keychain elements of other apps, is to figure out, which entitlement is required for access and sign an app with this access group. Un-fortunately, the name of the required entitlement is
stored unencrypted within the KeyChain’s SQLite data-base file and can be extracted easily. As jailbroken de-vices have disabled the verification of digital signatures, the only thing an attacker now need to do, is to sign the app by himself.
A easy to use tool is KeyChainViewer from Jean-Bap-tiste Bédrune and Jean Sigwald, which is running as an app on jailbroken iPhones Figure 7.
Decrypting Files
The last encryption item I want to write about is the en-cryption of files on the iPhone using NSFileProtection-Key from the API. As written before, the file encryption has to be used from the developer of an app, by calling the appropriate API calls. However, if a file is encrypt-ed, the encryption key is based on the passcode. As in most cases, users are using a four digit secret instead of a complex passcode; this is an ideal candidate for a brute force attack. On average, a successful brute force attack against a 4 digit passcode, which tries all 10000 possible combinations, takes only a couple of minutes on an iPhone. This attack by the way will not trigger the local wipe of the device, although the maximum number of failed logins is exceeded. Jean-Baptiste Bédrune and Jean Sigwald do also provide a tool to conduct a brute force attack against iPhones (http://code.google.com/p/
iphone-dataprotection/).
Jailbreak
Jailbreaking is the process of removing the limitations imposed by Apple on devices running the iOS operat-ing system (http://en.wikipedia.org/wiki/IOS_jailbreak-ing). On a jailbroken iPhone, a user has root access of the operating system and can, besides many other tasks, install apps from stores others than the Apple Store. Easy to use tools like redsn0w, Spirit, Pwnage Tool and JailbreakMe are publically available, including videos on how to use them. There are two types of Jail-breaks available, tethered and untethered. A tethered Jailbreak is not persistent and requires the iPhone to be connected to a Computer, each time it reboots, in order to boot into the jailbroken operating system. Untethered Jailbreaks do not have this requirement, and stay
jail-Figure 6. IPhone.Ikee.B Message
DEFENCE
broken after each reboot. One method to jailbreak an iPhone is the Boot-ROM Attack. The boot-ROM is the first piece of code that is running, when starting the iPhone and is a read only memory. Therefore a securi-ty vulnerabilisecuri-ty found within the boot-ROM is something like the holy grail for a vulnerability researcher, as Apple can’t simply fix it by supplying a patch and has to issue a new hardware revision.
Boot-ROM attacks can use the Device Firmware Up-grade (DFU) mode of the iPhone, which is accessible by pressing the home and power button in a certain sequence. Once an iPhone has booted into DFU-mode, an application can send a new firmware image to the device via USB. Hackers are using this mode to smuggle in code that is patching the devices operat-ing system. By design, firmware files have to be digi-tally signed by Apple, in order to be accepted by the iPhone. But hackers already discovered flaws within the boot-ROM, allowing them to circumvent this re-striction.
From a support and security standpoint, a compa-ny wants to avoid users using jailbroken devices. Be-side the fact that Apple understandably does not sup-port jailbroken iPhones, it also dramatically decreases the resilience of the iPhone against mobile security threats. Users can now install apps from even untrust-ed sources, which do not neuntrust-ed to be digitally signuntrust-ed.
This opens new possibilities for malicious apps. In
ad-dition, users could modify the configuration profiles, deployed by the company, thus making this device not policy compliant.
Many MDM solutions have a functionality to detect jailbroken devices. They’re using different approaches, like looking for the Cydia app installed, an app which by default is installed by the jailbreaking tool Redsn0w.
Or they are trying to write data outside of an applica-tions sandbox. Since Cydia is not available on the Apple Store, and writing outside of the sandbox is prohibited by an unhacked iOS, both methods are good indicators for a jailbroken device.
Conclusion
The iOS security model seems to be well designed and thus has far proven largely resistant to attack. It offers strong protection against traditional malware, primarily due to the sandboxing approach and Apple’s rigorous app certification process and their developer certifica-tion process, which vets the identity of each software author and weeds out attackers.
Once an attacker has physical access to an iPhone, he has good chances to access the information on the device. Enforcing the usage of a complex passcode will increase the devices resilience against brute force at-tack, as already the usage of 6 characters instead of 4 digits will extend the time required for a successful at-tack, from 5 minutes to more than a year. Companies developing in house apps should take advantage of the file encryption capabilities which are provided by the iOS API.
In order to avoid data loss by lost or stolen iPhones, it is recommended to avoid confidential information be-ing stored on the device. Therefore ana integration into the corporate’s data loss solution is recommended. Also the activation of the devices kill-switch may be a good idea, allowing the conduction of a remote wipe in case of a lost device.Companies should also make use of the further security features, provided by iOS and configure their devices accordingly. And last but not least, A solid MDM solution will help, to manage a large number of devices, and to keep them secure.
Figure 7. Keychain viewer
OLiVER KAROW
Oliver Karow is working as a Sr. Principal Consultant at Sy-mantec Germany GmbH.
He is in IT Security for more than 10 years and worked for for-tune 500 companies. He has a diploma in information tech-nology and is a CISSP. His current focus is on Data Loss Pre-vention.