Presented at
VB2019,
Oct. 4, 2019, 9:30 a.m.
(30 minutes)
1. Introduction
As we all know, *Apple*'s *iOS *and *MacOS* systems have gained much popularity with the huge popularity of the *iPhone* and the *MacPro*. More system vulnerabilities in *iOS* and *MacOS* have been developed and been abused by hackers. The more you know about your enemy, the more likely you can defeat him. But, how?
Since *iOS 10*, *Apple* has released the unpacked/decrypted kernelcache, but the system source code, especially the kernel and driver parts, remain closed-sourced. What's more, symbol info in the binary (kernelcache) has been greatly removed, which creates more difficulty for reverse engineering. A challenge means a chance. The truth in security research is that the more attack interface you find, and the more implementation you do, the greater the probability you will find a zero-day vulnerability. The relatively good news is there is always much interface and implementation code change (e.g. external methods exposed in drivers via IOUserClient) in each *iOS*/*MacOS* system update and new hardware introduction. Hence, we plan to expose the typical workflow and thinking to explore and analyse the new attack interface using reverse engineering and dynamic analysis from the point of view of the researcher.
2. Static analysis
In the first part, we will introduce a reverse engineering solution for static analysis of *macOS* and *iOS* systems. The first step is kernel/kexts analysis, which can get all the attack interfaces from a newly released version including User Client vector, external method interfaces vector, syscall/sysctl interfaces vector and traps/MIGs vector.
The second step is to diff the XUN project and kexts between two neighbouring versions, which can get the updated functions' entry list.
The third step is to filter out those entries which cannot be accessed from user space and save those remaining entries which can be accessed directly.
Finally, these interfaces are collected and saved into a fuzzing corpus database.
3. Dynamic analysis
As a necessary complement to static analysis, the key methodology for dynamic analysis is to get the runtime context of the attack interface API so as to help trigger, fuzz or even reproduce the potential vulnerability.
As our best practice, we would choose Frida to control and trace user-mode context and Dtrace to trace the kernel counterpart. As the manual affiliation, debugging (via lldb) both the user and kernel is reasonable.
4. Innovative passive fuzzing based on interface analysis
To verify the attack interface we have analysed and hunted 0-day bugs, and an innovative passive fuzzing method based on code execution interception has been built. As the key methodology for fuzzing, we would like to touch as much of the execution path (code coverage) as possible and also catch the first spot of kernel crash using our fuzzing.
The first step for fuzzing is to generate a fruitful corpus of kernel interface APIs and call to the kernel from the user agent. Besides blind fuzzing, we recommend the use of normal programs which have a greater chance of interacting with the kernel as the agent. For example, playing 3D games towards openGL or graphics drivers, peripheral devices operation (e.g. Wi-Fi, Bluetooth management) and so forth. These kinds of real kernel API calls could eventually touch a "deeper" kernel code execution path because the input parameters have already been approved to bypass most trick kernel checks.
As the second step, the passive fuzzer could intercept the typical APIs in the kernel counterpart as an inline hook for pre and post event handling. By fuzzing the input data of the API parameter (usually the buffer content of the argument or kernel/user shared memory) in special time strategy, you could get plenty of kernel crashes. A kernel sanitizer mechanism (such as KASAN, KMSAN) could be useful to improve the fuzzing quantity and quality. Without a sanitizer mechanism, the crash caused by the memory corruption vulnerability may be handled and dismissed by the kernel code itself. What's more, there would be an instruction sequence disorder between the root cause point and the final instruction pointed by RIP in one crash which will cause more analysis effort for researchers.
5. 0-Day vulnerability
We have hunted dozens of kernel and driver 0-day bugs based on the designed fuzzer. We will select several typical bugs and introduce how we hunt these bugs step by step and how we locate the root cause.
1）CVE-2018-4462 - an Integer overflow vulnerability which can leak kernel information found in AMDFramebuffer driver.
2）NULL PAGE reference issue found in IntelAccelerator.
3）OverFlow issue due to No Boundary Check in IOUSBFamliy extension.
4）OOB read issue found in AMDRadeonX4000\_AMDAccelResource class.
5）Divide Zero issue found in IOAccelCommandQueue class.
We would not only open-source the relative tool chain to explore the attack interfaces but also make public the kernel vulnerability hunting system based on enhanced passive fuzzing.
Presenters:
-
Moony Li
- Trend Micro
Moony Li Moony Li is security researcher leader at Trend Micro. He mainly focuses on Windows, OSX, Android, iOS security sandbox solutions and vulnerability/exploit hunting. He has participated at many conferences including HITCON 2016, Code Blue 2016, Pacsec 2016, BlackHat Europe 2016, Code Blue 2017, Black Hat Asia 2018, Black Hat USA 2018 and Blackhat Europe 2018. @Flyic
-
Lilang Wu
- Trend Micro
Lilang Wu Lilang Wu is a senior engineer at Trend Micro and has four years' security experience. He focuses on iOS, MacOS and Android kernel vulnerability discovery and malware hunting. He disclosed the masque attack named "IOS_Landmine.A". He has spoken at many conferences including BlackHat USA 2018, BlackHat Europe 2018 and CodeBlue 2018. @Lilang_Wu
Links:
Similar Presentations: