 Fasten your seat belts. From Alibaba Security Lab. For, it looks like their talk is about escaping iOS 11 sandbox. Give them a round of applause. Hello everyone. Can you hear me? Okay. Hello everyone. Today we are going to talk about the security of iOS 11 sandbox. And this talk will be presented by my friend, Min Spark Zheng, and me. We are from Alibaba Security. Firstly, let's kind of look at the iOS system. There are three levels in the iOS system. The first level is sandbox applications. There are quite a few attack surfaces to the kernel in applications. And the second level is user line system services including some services called Mac services. In these system services, we can have more attack surfaces to the kernel. And the third level is the kernel. So in iOS, iOS application is sandboxed. This sandbox was first introduced as seat belt in macOS. And now, there are over 100 operations that are hooked by sandbox policies. And these sandbox policies were first blacklist and now they are now. So with this table, this table is from the OS internals. With this table, we can know that there are over 100 sandbox hooks in iOS 11. And there is a concept called sandbox profiles. Sandbox profiles define what Mac services can be accessed by sandbox applications. In macOS, these profiles are visible in system library. And in iOS, the profiles are hard coded and difficult to be decoded. But we can try to get the list of services that can be accessed by sandbox applications. Also, we can use some tools. For example, the SB2 developed by Jonathan. In order to find the vulnerabilities in a mac service, we need to disassemble and analyze the binary that handles the mac service. There is a directory called system library log demons which contains the configuration of most mac services. From these playlist files, we can know the path to mac services banners. And next, Spark will give more details about the vulnerabilities we found in iOS 11 sandbox. Thank you. Thanks, Xiaolong. Okay, so there are a rich set of IPC mechanism in iOS. And most of them are available to third party applications. In this talk, we will focus on mac service. Mac messages are most common use the IPC mechanism in X and U. In addition, mac messages contains typed data which can include the port writes and the reference to large range of memory. Based on mac message, Apple developed the XPC compared with raw mac message. XPC is safer and easier to be used. But the cost of XPC service maintenance is very high. As XPC message is built on top of XPC message which allow abstraction of XPC connections and remote objects. Slow mac message, sandbox app can communicate with mac services, XPC services and NSXPC services. Consequently, if the server doesn't handle the message in expected ways, they may be corrupted by malicious apps. So in this talk, I will share three old bugs today. The first bug exists in the Gitkeeper XPC service. The related binary is the result. The service receives two parameters. One is test sub dictionary and the second one is source pass. But it doesn't check the validate of the past string. Therefore, if the attacker can use a pass traversal vulnerability to achieve arbitrary file move outside the sandbox with mobile privilege, this bug was used in Pangu 9 for jailbreak. So the second vulnerability is in media library D, NSXPC. It can be exploited to read, write and query arbitrary circulate files outside the sandbox. Since the remote object of the service have mobile privilege and it does not check the input pass of the circulate file, an attacker can achieve arbitrary query of the files on the system. The attacker can use begin transition for database at a path to connect arbitrary files, arbitrary circulate files on the system and then use execute query to execute SQL commands on it. For example, a malicious app can leverage this vulnerability to modify SM messages or emails on the device. In addition, it has another vulnerability because it uses circulate 3. The circulate 3 has a feature that called FTS3 token leiser. It is used for built-in full text search. Developer can use commands to get or set token leiser. However, attackers can leverage this feature to link memory information and even execute arbitrary code. For example, the first commander can help us link the address of the default token leiser which can help us to bypass ASLR. In addition, attacker can register a new token leiser and trigger the callbacks using the following commands, the second commands. Because the callback address is set by us and the process doesn't check it. So it's possible for us to hijack the PC register and control the NSXPC service as we want. This vulnerability was used in our private jailbreak. So here is the third bug. This bug exists in the Bluetooth D mark service. There are 132 functions in the com Apple service, Bluetooth D mark service. Bluetooth D communicate with other sandbox apps and on sandbox processes. For example, through com Apple service, Bluetooth D. A process can use BT session attached to create a session token for the Bluetooth D and then use BT local device at the callbacks to register a callback for event notification. However, it has a vulnerability which are found by Renny. He found that the Bluetooth D only use the session token to identify the process which means we can use a sandbox app to hijack communication between Bluetooth D and on sandbox processes through the session token. The key problem is the session token is too easy to be brute forced. It only have 10000 possible values. Therefore, the, therefore Apple fix this problem by adding a user ID to each session which is a random number. And only the process and the Bluetooth D know the user ID and the Bluetooth D will check the map of SES token with the user ID in the, at the callbacks. So the as we mentioned before, a user ID is a very, very large random number. So if we know the session token, we can still try to hijack the communication through user ID brute force. But when I try it, I found it will take a very, very long time, about 12 hours. So I don't think this is a good bug. So what if we can find some other functions without a user ID verification? Yes, I found one. This function is called BT accessory manager add a callbacks. However, after sending messages to that function, nothing happened. What's wrong? Finally, I found the problem. The callback event can be triggered only when the iOS device connects to a new device, which means we need to trigger the callback by click the Bluetooth D manually. This is not a good bug because we need to do something on the device manually. So the first bug takes a very, very long time. The second bug is very hard to trigger. Can we find the third bug to do, to, to get a callbacks and easy to trigger? Finally, finally, I found it. This, this one is called BT discovery agent create. We can use it to create a callback for the discovery agent. Then we can use BT discovery agent to trigger the callback without manual click. So we find a very good bug. But the goal is not only control the PC register, but the process as well. So the next step is to create a rope chain and do a hip spree for the target process. In this case, we use complex mark message with all our descriptor memories. This is a very useful mark message because if we send the message to the process and don't receive it, the message will stay in the target's memory space persistently. Then we can use a magic address. For example, in this case is 10540000. To set this callback address and the PC can jump to this address, it will point to a rope chain. So after we trigger the vulnerability, we can control the following registers. And the last BR is X4. So now we can do BOP or GOP. But it's hard for us to control the whole program flow because we need a stack pivot to control the stack and change the BOP to ROP. So a good stack pivot gadget can be found in the system platform. This gadget is very useful. If we can control X0, we can control SP. After that, we can do real rope. By using rope, we can still file or open a sandbox, I okay to use a client. But rope is not elegant. We want the task pod to control everything. So what is task pod? Let me briefly introduce what is pod. A pod in X and U provides an endpoint for IPC. Messages can be sent to a pod or received from it. Pods can contain writes and pod writes can be passed in message. The most important pod for the process is the task pod, which can be get from mark task itself. One can control the memory or all the registers for the process through it's task pod. This pod is very useful. For example, we can use mark VM analog to analog memories in a remote process through the task pod. And mark VM write to copy data into a remote process. And thread create a running to create a new thread and control registers in a remote process. So if we can get the task pod, we can control everything of the process. Okay, so let's try to get the task pod of a remote process. Here is the steps. First, we ask a launch D to get the pod name of Bluetooth D. Then we send a lot of pods with the power apps send write to the Bluetooth D and send loops through HIP3. After that, we trigger the vulnerability to control the PC of Bluetooth D. After that, we use the rope chain to send mark messages, which contains the task pod of Bluetooth D back to our power app. After that, we can use the target process, we can control the whole target process through its task pod. There are some tricks learned from much portal, which are developed by beer. We can use insert write to insert a send write to the pod. And the pod can be sent by all our messages with pod description. In most cases, the mark task itself returns 103. So we can just use 103 without the rope to call the mark task itself. In order to get the task pod back to our power app, we need to know the pod number of our power app. However, we can't use launch D to help us. So that's why we send a lot of pods because it can be brute-forced. So we send a lot of pods to the remote server in order to increase the success rate. After that, we can try to remotely malach some memories in the target process or just execute some functions in the target process. However, iOS 11 adds a new mitigation that we cannot easily use the task pod in the user land. So we can easily use the generic parameter. So we have a plan B that the ropes always work in the user mode. So we can use a generic primitive for the function called with arbitrary parameters in the core foundation. This gadget is very useful because we can have unlimited parameters and then call x8 and last return to the program. By using the Bluetooth D vulnerability, we successfully exploit iOS kernel through on Sandbox, I will keep you the client and break Knoll slide and then gain the Knoll read and write ability on the iOS 11. Also, we got a root shell and a jailbreak on the iOS 11. So here is a conclusion. First, we introduce the basic concept of iOS Sandbox and summarize several classic ways to escape the iOS Sandbox. Based on old Bluetooth D vulnerability, we found two new zero day Sandbox escape vulnerabilities on the latest iOS version. And we present a classic way to do heap 3, stack pivot and rope in iOS user land. Then we show how to get and control the task pod of the remote process during the exploit. During the exploit, there is an update that after we submit our talk to DevCon, we also report these two zero day bugs to Apple on July 7. Apple fix them in the latest iOS and as well as iOS 12 beta with CVEs. So please update your device to the latest version in order to defend against the potential task, potential attacks. So here is some reference for this talk. Okay, that's all for our talk. You can follow us on Twitter. Thank you for listening. Thank you.