src: http://blog.thireus.com/tag/kernelcache

Before going further it is important to enumerate some of the main security features available on iOS. The same goes for the architecture security features, particularly the boot process and partitioning system.

iOS partitioning system and its biggest security feature

All iDevices have the particularity to contains a 8GB to 64GB flash memory split in two distinct partitions. The first one in read only contains the operating system iOS while the other one is dedicated to user data and have read and write permissions. The data partition contains user documents, applications, pictures, and other various user files. This flash memory is hardware encrypted using an AES-256 crypto-processor soldered on the iDevice motherboard right on the path between flash memory and RAM. Meaning that anything that comes from the flash memory to go in RAM is decrypted and anything that comes from RAM to go in the flash memory is encrypted. Nothing can transit without being encrypted/decrypted by the crypto-processor, thus you cannot manually extract the flash memory and read data from it, because anything is encrypted with AES-256.

UID (Unique ID) and GID (Group ID) are two keys soldered inside the crypto-processor and used to encrypt or decrypt. These keys are only accessible by the crypto-processor itself, they cannot be software requested or dumped (hypothetically a covert channel attack could do the trick). The UID key is unique for any iDevice and is not registered in Apple Databases (but we do not have proof for that), the GID key is the same for iDevices of the same class, meaning for example that any iPhone 3GS will have  the same GID key but each one will have a unique UID key. On top of that, these keys can be combined in addition to the passcode key (derived from the user passcode to unlock the iDevice) or any other external key, which creates various protection classes.

These protection classes are then used to encrypt some user data on top of the already hardware encrypted flash memory. Thus, if you successfully access the data partition, some files will remain encrypted with either the passcode key or other external keys combined to the UID key, which is the case for emails for example. So once the iDevice is locked, files are completely secured due to the missing passcode key. And brute-forcing the passcode key can only be achieved on the iDevice, because the decrypt function is called inside the crypto-processor which combine the given key with the UID key.

According to iOS Hacker’s Handbook it takes about 18 minutes in the worst case scenario to bruteforce a 4 digits passcode (iOS default scheme), which is even worse if the user change his passcode for a alphanumerical passcode (in that case it can take years to bruteforce  ). There are no time limitations in case you bruteforce the passcode directly by calling the decrypt function of the crypto-processor. But in the case you attempt to manually bruteforce the passcode directly from the iOS unlock screen you will face these limitations that exponentially increase when a wrong passcode is entered.

Fortunately for attackers, only a few amount of data files are encrypted using the passcode key. Most of the files remain unencrypted, and some protections I talked about here were implemented during the iOS development. Meaning that old iOS versions are less protected that the newest ones, unfortunately the ones I presented here are all integrated to iOS 5.

Various exploits but only one goal

There are three categories of exploits on iOS, each one refers to a particular boot module of iOS.

  • Bootrom (also called SecureROM by Apple) Exploits
  • iBoot Exploits
  • Userland Exploits


Bootrom
 exploits are the most powerful, because the bootrom is the first piece of code executed on the iDevice boot process. This bootrom is read only and cannot be updated nor modified, it is soldered on the iDevice. Thus a bootrom vulnerability cannot be fixed by Apple on existing and already sold devices. Actually there are only one bootrom exploit, which is called limera1n and created by George Hotz. This bootrom vulnerability has not been patched by Apple until the next hardware revision with Apple A5 processors and upper (meaning iPhone 4S, iPad 2, etc.) only  iPhone 3GS/4, iPod Touch 3G/4G and iPad are vulnerable. The limera1n exploit breaks the signature check for any elements of the boot process, meaning you can boot with an alternated or custom boot chain. In addition to that a bootrom exploit can be used to decrypt Apple GID encrypted files contained in IPSW archives (used to restore or upgrade iDevices). IPSW contains iOS and various GID encrypted data, that can be decrypted using with such an exploit by calling the crypto-processor function that uses the GID key. Attackers can then patch and alter these decrypted files for their own purpose, inject and boot with these files by the use of limera1n.

iBoot is the boot process part that launches the iOS kernel. These kind of vulnerabilities can lead to an untethered Jailbreak. Finding a vulnerability at this level is as powerful as a bootrom vulnerability in term of functionalities. Unfortunately such a vulnerability can be quickly patched by Apple in a next iOS update. iBoot vulnerabilities are not used in ironha1l, but it is important to have in mind the entire boot process for the next part of this article.

Finally, userland vulnerabilities are at the top level of iOS at the same level of running iOS applications. Exploiting such a vulnerability is very hard, and only allows the attacker to access mobile (or root) privileges. But yet, the attacker needs first to get out of the sandboxed application where the vulnerability was exploited. I will not talk more about this kind of exploit here.

DFU mode

The DFU mode (Device Firmware Update) is a special mode in which the device loads a specific code from the bootrom. This mode is also available in the Nintendo DS for example, and is not Apple property. This executed code allows the device to accept boot elements from the sync port of the iDevice (I prefer calling it the USB port). This DFU mode is mainly used when the device is software bricked, and even if the classic restore mode of the iDevice is broken. The DFU mode once detected by iTunes will receive boot elements from it. Those elements are from the IPSW archive, and are composed of iBSS, iBEC, DeviceTree, KernelCache and Ramdisk. The ramdisk file is a container which contains a very basic version of iOS only used to flash the device with a new iOS version sent by iTunes. This ramdisk is a very good basis for an attacker to access the iDevice partitions. 

To put your iDevice in DFU mode, you first need to connect it to a USB host device, to boot the iDevice while maintaining the HOME and POWER button pressed during 8 seconds, then release the POWER button only while maintaining the HOME button still pressed. After some seconds, the iDevice should be in DFU mode. This mode is visually indistinguishable, only the host device knows if the connected iDevice is in DFU mode as it receives a DFU notification.

In 2012, George Hotz publish his limera1n exploit which allows the use of unsigned boot elements on vulnerable iDevices. This vulnerability is a memory overflow in the bootrom. With such an exploit, jailbreakers are able to modify the iOS ramdisk used in DFU mode, for example by editing the /sbin/launchdbinary which is used to launch other binaries and scripts at boot, such as mounting partitions in read and write mode. This launchd binary will be used for example to execute sshd on our ramdisk. 

Tumbling down the rabbit hole

 This part is dedicated to the development and creation of the ironha1l and DFOwn tools. Those tools were created to inject and execute a custom ramdisk containing a SSH server on a targeted iDevice using an Android device.

USB reverse

As previously described, what is interesting for us is to exploit the bootrom vulnerability with limera1n in order to inject a custom boot chain on the targeted iDevice. Actually, jailbreak software such as Redsn0w can do that, but our aim here is quite different as we intend to do it with an Android phone, and there are no such existing tools for this operating system.

We have two choices. The first one is to modify existing and open source jailbreak tools and port them for Android platform. The second choice is to create a totally new tool optimized for Android. Given the aim to have a mastered full tool suite, and because I had time to learn and I love challenges, I decided to give a try to the second alternative. Consequently, USB reverse engineering in DFU mode was required to establish how data is sent to the iDevice and what are the USB transfer modes, headers and commands used for all the steps of the boot chain.

It is first necessary to create an USB debug environment or as I like to call it, a Man In The Middle USB. There are several ways to do this, either you can directly reverse each element of the boot chain to understand how the following elements must be injected, or you can modify the Mac OS or Windows USB driver to activate the USB debug mode, you can also use a sniffer device between attached to your USB cable, or you can even directly use a Windows Virtual Machine on your Linux system. In this last case the use of Wireshark running on Linux will do the trick, as it can sniff USB communications, especially in our case the USB communications between iTunes running in the Windows VM with our attached USB iDevice. This last method is quite buggy, but allows us to see the USB communication protocol quite easily.

The full description of the DFU mode is in the meantime available in the Universal Serial Bus Device Class Specification for Device Firmware Upgradepublication. With the help of this documentation and various USB headers and requests sniffed with Wireshark, the exact iTunes behavior for data transfer in DFU mode has been established. It is important to note that all communications are in clear text, same apply for commands sent to the iDevice which are associated to each part of the boot process. Another observation, is that header values are specific to Apple and not documented.

Development of libironha1l and ironha1l

The biggest step in this project was to create the ironha1l tool and its library libironha1l. This library provides functions to inject data to the iDevice in DFU mode and is strictly based on libusb. The principal advantage of this last point is the portability of libusb, and its compatibility with Android. ironha1l is the application that coordinates all the various injections of our custom boot chain, based on the DFU protocol reverse established previously. Meaning the injection of iBSS, iBEC, DeviceTree, KernelCache and Ramdisk modified files. These custom files can be extracted and automatically created using theiPhone-dataprotection tool suite of Sogeti.

The development of ironha1l and libironha1l lasted 3 months and contains more than 1000 lines of code. ironha1l and libironha1l are written in C. The ironha1l tool also comes with the limera1n exploit and payload (sources available on the Jailbreak community Wiki).

During the development, a number of difficulties came to light. The first one and the most difficult was the ramdisk size. During the first attempts to inject a custom ramdisk it has been established that a ramdisk size higher than ~10 MB could not be executed on the iDevice, unfortunately a ramdisk containing a SSH server cannot handle such a limited size.  The solution was in fact, to alter a bit in the control transfer header specific to the ramdisk. This solution was established after many days by testing ramdom and various header values.  Unfortunately it is still unknown why does this bit value bypass the size limitation.

Two more issues, this time related to limera1n, came to light during the libironha1l development. The first one is that limera1n consists of two elements, the source code and the payload. The limera1n payload is unfortunately not documented and is not open source, but it is easily extractable from Jailbreak tools such as RedSn0w. To extract this payload you need to apply the same reverse process as describer in the USB reverse part of this article. Meaning using Redsn0w in a Windows Virtual Machine on your Linux platform and dump all USB transmissions with Wireshark in Man In The Middle. Once the payload dumped, it has been tested and once again came another problem.

The limera1n exploit is based on the principal buffer overflow vulnerability of the bootrom, but unfortunately a USB control command must be sent to the iDevice during the injection process of the payload, so that the payload can be executed. If the control command reaches the iDevice too late, the payload is not executed. Le biggest problem is that generally the USB commands cannot overlap with one another with libusb, and this it is not possible to send the specific USB control command without interrupting the previous injection. The trick and the solution is to play with reception timeouts (acknowledgment replies), the payload is sent to the iDevice with a big timeout and due to its big size the iDevice will take a certain amount of time to deal with it. During this short amount of time (1 to 10 milliseconds), the control command that executes the payload must be sent, this time with a timeout lower than 10 milliseconds to match the iDevice process timing (ideally 1 millisecond).

Here is the prototype of ironha1l:

usage: ./ironha1l -h (help)
    [-v verbose_level{0,1,2,3}] [-d libusb_debug_level{0,1,2,3}]
    [-l limera1n_file] [-i iBSS_file] [-b iBEC_file]
    [-t DeviceTree_file] [-r Ramdisk_file] [-k KernelCache_file]
    [-c iBSS_command]
    [-z idBus]

Once our tool working and injecting correctly all elements of our customized boot chain, the iDevice boots on our ramdisk containing a SSH server. Meanwhile, on the client side we need to find a way to connect to this SSH server via USB. Fortunately this task is not a real big deal. The MobileDeviceframework of Apple (included in iTunes for Windows) contains a daemon called usbmuxd. This daemon is typically what we need as it creates a TCP tunnel over USB to communicate with the iDevice services (in our case the ssh server). Of course, the usbmuxd used by Apple is not open source, but a bunch of great developers have created a usbmuxd version open source that comes with iproxy which is used for port forwarding. So combining usbmuxd with iproxy creates a local port that communicate through USB directly with the SSH socket in listening mode on the iDevice. It was not a big deal to port usbmuxd and iproxy for Android, as these tools are working under Linux. It should also be noted that this open source project is not maintained by Apple, thus each time a new device comes out usbmuxd must be updated by developers and apparently this is not an easy task.  In our case our targeted iDevices are all working and supported by the latest version of usbmuxd.

The application portability is a very important aspect, it has been decided to directly integrate libusb and usbmuxd in ironha1l. Before compiling, a script downloads, patches and configures the latest libusb and usbmuxd version. The ironha1l tool suite is compatible with Linux, UNIX, BSD, Mac OS and Android.

[转]Bypassing iOS security的更多相关文章

  1. Cisco IOS Security command Guide

    copy system:running-config nvram:startup-config : to save your configuration changes to the startup ...

  2. Types of Security Vulnerabilities

    1)内存空间安全.2)参量级别数据安全:3)通信级别数据安全:4)数据访问控制:5)通信对象身份确认. https://developer.apple.com/library/content/docu ...

  3. Summary of Critical and Exploitable iOS Vulnerabilities in 2016

    Summary of Critical and Exploitable iOS Vulnerabilities in 2016 Author:Min (Spark) Zheng, Cererdlong ...

  4. fir.im Weekly - 让 iOS 应用更加安全

    攻易防难,关于 iOS 应用安全看起来有些神秘.iOS Security , 源于@吴发伟_则平博客翻译的关于iOS安全的一系列文章,现在站点已经系统收集了大量关于 iOS 逆向.安全.反编译.静动态 ...

  5. iOS homekit使用说明

    本文由CocoaChina翻译组成员iBenjamin_Go和浅夏@旧时光翻译自苹果开发文档:HomeKit Developer Guide,敬请勘误. 本文档内容包括 第一部分:简介 第二部分:启用 ...

  6. [转]iOS hacking resource collection

    Link:http://www.securitylearn.net/tag/apple-ios-hacking-slides/ A collection of iOS research present ...

  7. 第18月第2天 ios博客

    1. github https://githuber.cn/search?language=Objective-C https://www.jianshu.com/u/815d10a4bdce htt ...

  8. 苹果系统iOS、macOS应用管理机制

    iOS.macOS系统应用管理机制 苹果系统包括:iOS.macOS.watchOS.tvOS.应用软件的生命周期为:开发.上线.安装.使用.卸载.这篇文档将从应用生命周期的各个环节介绍苹果系统对应用 ...

  9. Django : Security in Django

    Security in Django https://docs.djangoproject.com/en/1.10/topics/security/ 1 Cross site scripting (X ...

随机推荐

  1. Linux入门介绍

    Linux入门介绍 一.Linux 初步介绍 Linux的优点 免费的,开源的 支持多线程,多用户 安全性好 对内存和文件管理优越 系统稳定 消耗资源少 Linux的缺点 操作相对困难 一些专业软件以 ...

  2. unity脚本运行顺序具体的解释

    unity脚本自带函数执行顺序例如以下:将以下脚本挂在随意物体执行就可以得到 Awake ->OnEable-> Start ->-> FixedUpdate-> Upd ...

  3. Alice's Chance

    id=1698" style="background-color:rgb(51,255,51)">主题链接 意甲冠军: 爱丽丝要拍电影.有n部电影,规定爱丽丝第i部 ...

  4. hdu Color the ball

    题目链接:http://acm.hdu.edu.cn/showproblem.php?pid=1556 树状数组的  update的应用,逆序更新 代码: #include <stdio.h&g ...

  5. C#关于HttpClient的应用(一):获取IP所在的地理位置信息

    public class IpHttpClient:BaseHttpClient { private String appKey; private const string HOST_PATH = & ...

  6. crawler_浅谈网络爬虫

    题记: 1024,今天是个程序猿的节日 ,哈哈,转为正题,从事了一线网络爬虫开发有近1000天.简单阐述下个人对网络爬虫的理解. 提纲: 1:是什么 2:能做什么 3:怎么做 4:综述 1:是什么 w ...

  7. 【MongoDB数据库】Java MongoDB CRUD Example

    上一页告诉我们MongoDB 命令入门初探,本篇blog将基于上一篇blog所建立的数据库和表完毕一个简单的Java MongoDB CRUD Example.利用Java连接MongoDB数据库,并 ...

  8. 私人定制javascript中对象小知识点(Only For Me)

    废话不多讲,先上笑话,然后再,.看懂这个的说明你的节操已经不再了. 晚饭后去理发店理发...割了吧...老板问我怎么剪,我悠悠的来一句往帅了剪...高潮往往令人想不到....旁边一在焗油烫头发的大妈说 ...

  9. java传值和通过引用传递

    第一次使用int实验: public class TTEST { private static List<UserEntity> mList = new LinkedList<Use ...

  10. PHP-微信公众平台开发-接收用户输入消息类型并响应

    原文:PHP-微信公众平台开发-接收用户输入消息类型并响应 <?php // 该代码块用于接收用户消息,根据用户输入的消息类型进行判断,文本,图片,视频,位置,链接,语音等,并取得值,处理后给予 ...