Upgrade to Pro — share decks privately, control downloads, hide ads and more …

2PAC 2Furious: Envisioning an iOS Compromise in 2019

2PAC 2Furious: Envisioning an iOS Compromise in 2019

Infiltrate 2019 talk slides

Marco Grassi

May 02, 2019
Tweet

More Decks by Marco Grassi

Other Decks in Research

Transcript

  1. 2PAC 2Furious: Envisioning an iOS
    compromise in 2019
    Marco Grassi - @marcograss
    Liang Chen - @chenliang0817

    View full-size slide

  2. About Us
    • Members of Tencent KEEN Security Lab (formerly known as KeenTeam)
    • Marco (@marcograss):
    • My main focus is iOS/Android/macOS and sandboxes. But recently shifted to hypervisors, basebands, firmwares etc.
    • pwn2own 2016 Mac OS X Team
    • Mobile pwn2own 2016 iOS team
    • pwn2own 2017 VMWare escape team
    • Mobile pwn2own 2017 iOS Wifi + baseband team
    • Liang (@chenliang0817):
    • Lead Pwn2Own team in KeenLab (Co-founder of KeenTeam/KeenLab)
    • Browser exploiting, iOS/MacOS sandbox bypassing and privilege escalation
    • Winner of Mobile Pwn2Own 2013 iOS category
    • Winner of Pwn2Own 2014 OSX category

    View full-size slide

  3. About Tencent Keen Security Lab
    • Previously known as KeenTeam
    • White Hat Security Researchers
    • Several times pwn2own winners
    • We are based in Shanghai, China
    • Our blog is
    https://keenlab.tencent.com/en/
    • Twitter @keen_lab

    View full-size slide

  4. Agenda
    • Introduction of ARMv8.3 pointer authentication
    • PAC on iOS 12 A12
    • Possible attacks on PAC
    • When PAC is combined with APRR
    • Baseband
    • Baseband <=> Application Processor
    • Conclusions

    View full-size slide

  5. ARMv8.3 pointer authentication
    • Principle: in ARM64, the pointer uses less than 64bit, the unused bits
    can be used as additional information to authenticate the pointer(PAC)
    PAC part Address part
    64bit pointer 47 0

    View full-size slide

  6. ARMv8.3 pointer authentication
    • Three factors to generate PAC: value (address), context , key
    Value(address) Context PAC
    =
    + Key + Algorithm
    in CPU

    View full-size slide

  7. ARMv8.3 pointer authentication
    • Context
    • A 64bit value used to strengthen PAC
    • Isolate different types of pointers used with the same key
    • Avoid pointer replacement attack (If all pointers use 0 context)
    • Key
    • 4 keys (combination of instruction/data and A/B keys), plus a G key (general
    key) for data hash purpose
    • Stored in system registry, inaccessible at userland
    • Keys are per process and per exception level (or weakness is introduced)
    • Algorithm
    • QARMA

    View full-size slide

  8. ARMv8.3 pointer authentication
    • Instructions relating to PAC
    Instruction set Examples Comment
    PAC* PACIAZ, PACDB, etc… Generate PAC using specific key +
    context
    AUT* AUTIAZ, AUTDB, etc… Authenticate PAC using specific
    key + context
    Combined RETAA, BRAA,
    LDRAA…
    Authenticate PAC first, and do the
    original instruction

    View full-size slide

  9. ARMv8.3 pointer authentication
    • PAC generation and authentication
    • What if the authentication fails?
    • Place an error code on specific bits of the address, making address invalid
    (53rd and 54th bit for EL0 address)
    • Process crash? Or not?
    Raw pointer PAC*
    instruction
    PACed pointer
    PACed pointer AUT*
    instruction Crash/Exit
    Continue exec
    Pass
    Fail

    View full-size slide

  10. ARMv8.3 pointer authentication
    • What should be protected?
    • All pointers?
    • Of course not! Too expensive
    • Most important and sensitive content should be protected
    • Function pointers: using instruction keys
    • Important data pointers: using data keys
    • Important contents: using G key
    • Can be used to implement CFI

    View full-size slide

  11. ARMv8.3 pointer authentication
    • How effective at preventing exploitation?
    • Keys are inaccessible in userland
    • Keys can not obtained by kernel R/W in EL1
    • Algorithms might be public and know
    • So with arbitrary R/W, cannot compute PAC
    • To obtain arbitrary code execution you must compute PAC of function
    pointer first
    • To compute PAC of function pointer you must obtain arbitrary code
    execution
    • Chicken-egg problem!

    View full-size slide

  12. The design is quite good, any real
    world phones using PAC?

    View full-size slide

  13. PAC on iOS 12 A12
    • iPhone XS, XS Max, XR are facilitated with A12 chip
    • First phones adopting ARMv8.3 in the world
    • The whole iOS kernel, and all system Apps/binaries have PAC enforced

    View full-size slide

  14. Key initialization in iOS 12
    • Kernel A key, B key, G key initialized during boot & cpu start (after idle)
    • Kernel IA IB DA DB G keys all initialized as constant value.

    View full-size slide

  15. Key initialization in iOS 12
    • iOS doesn’t change A key in any situation
    • B key is per-process initialized at process creation time, IB is enabled
    by default
    • In task_create_internal
    • Switched during context switch

    View full-size slide

  16. Key initialization in iOS 12
    • A key and DB key are enabled by default for platform binary
    • Such as Webcontent
    • But disabled for our own App, why?
    • According to ARMv8.3 document, system register SCTLR_EL1
    responsible for key status control
    • EnIA, EnIB, EnDA, EnDB

    View full-size slide

  17. Key initialization in iOS 12
    • In exception_return:
    • For non-arm64e binary, EnIA EnDA and EnDB bit are masked

    View full-size slide

  18. Key initialization in iOS 12
    • How to enable IA DA DB keys for our own App?
    • Compile the binary as arm64e

    View full-size slide

  19. What we can conclude so far
    • We can conclude:
    • B key is per-process
    • A key is the same for all processes
    • Non-arm64e apps have A key and DB key disabled, IB key and G key enabled
    • Questions?
    • A key and G key are constant value, same pointer same PAC upon each reboot?
    • That will cause big issue for sure
    • A key and G key are same for both EL0 and EL1, can use userland App to
    compute kernel pointer PAC?
    • Seems crazy idea

    View full-size slide

  20. How PAC is used in iOS 12?

    View full-size slide

  21. Enhanced stack protection
    • Previously stack is protected by adding a cookie value
    between return address and local variable data
    • Cookie value is unique in the same process
    • Attackers can obtain the value via arbitrary memory read,
    defeating the stack protection
    • With PAC, the return address is authenticated(Using
    B key) with SP as context
    • The value is unique per pointer + stack frame
    • And, B key is per-process

    View full-size slide

  22. CFI in iOS 12
    • No BLR and BR any more
    • Indirect function pointers are authenticated
    • C++ vptr is authenticated via data A key
    • Functions in vtable are authenticated via instruction
    A key plus specific context (entry location + a static
    value)
    • GOT function pointers are authenticated via A
    key plus their address(ASLR) as context

    View full-size slide

  23. Objective C pointers
    • Objective-c vptr(isa) is not protected by
    PAC
    • But the method function pointer is IB key
    protected
    • B key is per-process
    • But before reaching object-c selector
    cache, there is chance to reach A key
    call
    • E.g __xpc_file_transfer_dispose, pointed
    out by Ian Beer

    View full-size slide

  24. Use of G key
    • Exception, trap, interrupt involve PC
    register change
    • Previous state needs to be stored and restored
    frequently
    • Hackers can change those states to control
    the execution flow
    • LR PC and CPSR are the most critical registers
    • iOS uses G key to compute the hash of
    those critical registers, and ensure the
    values are not modified before restore
    • Validate the hash during restore, panic the
    system if validation failed

    View full-size slide

  25. PAC makes exploitation harder
    • Modern exploitation aims to achieve arbitrary memory read/write as
    prerequisite
    • With PAC, achieving arbitrary memory read/write becomes harder
    • Especially vptr object involved UAF
    • Heap-overflow, or non vptr UAF are still likely to achieve R/W
    • Final goal of exploitation is to achieve arbitrary code execution
    • Sadly
    • This is what PAC aims to prevent
    • R/W -> code execution becomes super hard

    View full-size slide

  26. R/W -> code execution? How?

    View full-size slide

  27. Possible attacks
    • Real chicken-egg problem?
    • Key is there! Even B key can be read via R/W, other keys are constant value
    • Any ways to compute PAC without calling CPU PAC instruction?
    • QARMA https://github.com/dkales/qarma64-
    python/blob/master/qarma.py
    • Result: fail
    • Apple might redesign/tweak the algorithm , and never publish

    View full-size slide

  28. Possible attacks
    • Same key, same address, EL0 and EL1 PAC same?
    • Constant key, on each reboot, same address same PAC?
    • Result: all different. Why?
    • Guess: some customization / randomization set to the CPU during iBoot phase
    • And, Apple’s design cannot be that weak.

    View full-size slide

  29. Possible attacks
    • Brute force guess
    • Some daemons are user-friendly when crashing
    • Some function pointers use context as 0
    • Can replace between each other
    • Neither of the above is very practical or enough to achieve code
    execution

    View full-size slide

  30. I believe, good design always has not so
    good implementation, in early version

    View full-size slide

  31. Possible attacks
    • A key is the same for all processes
    • App can compute PAC for other processes
    • Case of userland privilege escalation or sandbox bypass
    • A great example was posted by Ian Beer recently:
    • https://googleprojectzero.blogspot.com/2019/04/splitting-atoms-in-xnu.html

    View full-size slide

  32. Possible attacks – Signing gadgets
    • Signing gadgets, e.g ”PACIA x0, x1; ret”:
    • Without arbitrary code execution, just by calling API + R/W
    • And of course, obvious signing gadgets do not exist in iOS
    • But how about indirect signing gadgets?

    View full-size slide

  33. Possible attacks – Signing gadgets
    • Found by Azad Brandon: in sysctl_unregister_oid, a converted 0-context
    pointer is stored and can be read out
    • X10 can be controlled
    • But AUTIA will fail as we cannot get PACed function pointer with specific
    context

    View full-size slide

  34. Possible attacks – Signing gadgets
    • Failed != panic, after AUT*, a fixed error bit will be appended
    to the pointer
    • So we can always get the correct PACIZAed value of any
    function pointer
    • Which means we can control the PC
    • But how about code execution, ROP? Or JOP?
    • ROP is hard to achieve, as return address is PACed by B key. JOP
    should also be hard, but thanks to Apple’s obfuscated kernel
    extension, quite some non-PAC indirect branching instruction

    View full-size slide

  35. Possible attacks – Signing gadgets
    • Apple’s fix:

    View full-size slide

  36. Is it effective?
    • Of course, it is helpful to prevent R/W -> code
    execution
    • But, why we need code execution?
    • In previous jailbreaks, only rootfs rw remount needs
    code execution
    • With R/W, you can do almost everything.
    • So, Apple must make sure critical operations
    cannot be achieved by pure R/W
    • Then, APRR(possibly Apple Page Read-only
    Region) is introduced
    Post jailbreak steps(in the
    past)
    Can be achieved by data-only
    attack
    Disable Sandbox Yes
    Disable code
    signing(Critical)
    Yes
    Rootfs rw remount(since
    iOS 11.3)
    Practically no(In theory yes)
    Install system app(e.g
    Cydia)
    Yes but needs rootfs rw remount
    as prerequisite

    View full-size slide

  37. APRR protection
    • In iPhone 7, KTRR(Kernel Text Read-only Region) is introduced
    • A memory range in kernel is marked as rx and the only rx memory in kernel
    • Everything else can be read-write
    • Some critical memory region should be modified frequently after iOS boot,
    which should have been protected also
    • APRR was introduced
    • Protect critical operations such as: AMFI trust cache management, pmap
    management

    View full-size slide

  38. APRR protection: implementation
    • Introduce a function dispatch table:
    • Function pointers in “__PPLTEXT:__text”
    segment
    • __PPLTEXT:__text is not executable by default
    • And special system register: “#4, c15, c2, #1”
    • “__PPLTEXT:__text” can be executed if the
    system register is set to 0x44554455646667
    • Only ppl_enter will set the register
    • APRR protected memory is only modified in
    __PPLTEXT:__text code

    View full-size slide

  39. APRR protection: implementation
    • How virtual memory pages are marked as APRR protected pages
    • By setting flags in APRR attribute table
    • And specify some bits in page table TTE
    • Page table and APRR attribute table are APRR protected also
    • It means, to modify APRR protected memory, only three ways:
    • By modifying APRR attribute table and change page table TTE (both protected by
    APRR)
    • By setting system register “#4, c15, c2, #1” to 0x44554455646667, but you need to
    get code execution first, and also no good gadget to set this register, because of PAC
    • By executing code in __PPLTEXT:__text , but need to set system register first…

    View full-size slide

  40. When PAC is combined with APRR
    • PAC
    • Makes exploitation harder
    • Makes kernel RW -> code execution super hard
    • But in previous jailbreak, code execution is useless, data-only attack is enough
    • APRR provides better memory protection
    • KTRR can only protect kernel text and const area, cannot change after iommu
    is initialized
    • APRR can protect memory on demand after iommu initialization, at hardware
    level
    • Apple moves critical memory into APRR protected area
    • E.g AMFI trust cache, pmap, cs_valid feature etc.
    • And it is certain that Apple will move more stuff into APRR protect area
    • Future jailbreak needs code execution
    • PAC + APRR = effective mitigation!

    View full-size slide

  41. An alternative story
    • The AP side of the iPhone is getting more and more mitigations and
    security scrutiny.
    • Recently, PAC, and more and more auditing.
    • There are several other paths of least resistance.
    • The Baseband is one of them
    • Can become a 0 clicks entry point
    •Complexity is an enemy of the vendor, but a friend of
    the attacker.
    • Basebands are VERY complex.

    View full-size slide

  42. The Intel Baseband: Intro
    • We will not cover the baseband basics for time constraints, you can
    find them in other talks, most notably:
    • Amat Cama, A walk With Shannon
    • Comsecuris, Breaking Band
    • Keen Lab, Exploitation of a Modern Smartphone Baseband
    • Charles Nitay Anna, The Baseband Basics
    • Guy – From Zero to Infinity
    • Comsecuris - There's Life in the Old Dog Yet (blogpost on iphone intel
    baseband)
    • The iPhone XR has the Intel (x-gold) XMM7560 model

    View full-size slide

  43. Attacking the baseband in one slide
    + =
    Modified Base station software stack
    to trigger the exploit
    OpenBSC
    OpenBTS
    srsLTE

    Software defined Radio, or
    equivalent hardware
    USRP
    BladeRF
    CMU200 (Testing
    hardware)
    Over the air
    exploit RCE inside the
    phone
    baseband

    View full-size slide

  44. Getting the baseband
    • Grab the ipsw link of your choice, for example iPhone XR
    • Shameless plug, save time by grabbing
    https://github.com/marcograss/partialzip
    • You can download single files from inside the huge ipsw, saving
    time/bandwidth
    • Use “list” command to find the baseband firmware, for example
    “Firmware/ICE18-1.03.08.Release.bbfw”
    • Use the download command to get just that file (~40mb instead of 3-
    4gb)
    • You are welcome.

    View full-size slide

  45. The bbfw
    • The bbfw is just a zip file
    • Extract and it’s composed of several ELFs
    • SYS_SW.elf is where the main os/stack is located
    • It says ELF for ARM… but it’s Intel.. (from iPhone XS and XR, before it
    was ARM)
    • Patch the elf header to make it Intel arch (010 Editor with the ELF
    template is a good choice), load into IDA Pro

    View full-size slide

  46. Reversing the firmware
    • I prefer to use the ARM version of the firmware because IDA Pro
    handles it better
    • It has several disadvantages compared to the x86 ones,
    • It’s the older baseband model
    • Lack of some network support such as CDMA
    • Baseband reversing is not straightforward… You can check the talk
    “Breaking Band” by Comsecuris, it’s basically a continuous wash and
    rinse, until you have a usable IDB
    • More challenging on Intel IMO since less strings than Samsung
    Shannon

    View full-size slide

  47. Reversing the firmware
    • Around 120k functions
    • First thing to do is to find alloc /
    free variants, and Rtos APIs
    • Not too hard to find
    • You can then find init functions
    of the tasks. And the handler
    functions of the threads
    • Hint: UtaOsThreadCreate

    View full-size slide

  48. “Important” threads
    • There are descriptions in
    memory for the threads
    that handle the juicy radio
    stuff where you want to find
    the RCEs.
    • Stuff like GMM, GRR,
    mobility management,
    EMM etc are there.
    • You need a good knowledge
    of the specs to choose what
    to go after..

    View full-size slide

  49. Threads
    • Like most of the
    basebands/rtos they
    constantly wait for some
    messages, dequeue them
    and then handle them
    (including the radio
    messages)
    • Lot of messages are intra
    tasks, not all are relevant for
    over the air content

    View full-size slide

  50. Memcpy_s
    • Like Qualcomm and Huawei,
    they have some “secure”
    version of memcpy, checking
    bounds on destinations and
    source (if properly specified)

    View full-size slide

  51. Message
    handling
    Messages between tasks and over the air are usually described
    programmatically in arrays with id and handlers

    View full-size slide

  52. Message
    handling
    The task routine will find the
    correct handler and invoke it

    View full-size slide

  53. How to get more debugging info from
    baseband
    • Go to https://developer.apple.com/bug-reporting/profiles-and-logs/
    • Download and install the “Baseband.mobileconfig” profile for iOS
    • Reboot the device
    • You can trigger also a sysdiagnose by holding both volume and the
    top button
    • Get some (very) basics information on baseband crash. (task, address
    of abort, …)

    View full-size slide

  54. Escaping the baseband (example)
    Target 2:
    CommCenter
    Target 1:
    Kernel
    Baseband where you
    have code exec
    PCI-E
    UserClient
    etc.
    You have several places where you can trigger a second bug on the Application Processor from the baseband
    Kernel
    CommCenter
    Others
    (Keep in mind that at this point you will still have to face PAC, since we will go on the
    Application Processor)
    Application Processor

    View full-size slide

  55. Intel Baseband Application Processor
    interface on iPhone XS/XR (Kernel)
    • Relevant IOKIT classes and components that we can gather from ioreg:
    • Connected over pci-e (baseband-pcie) is a IOPCIDevice
    • Has 2 IODeviceMemory, one of 0x1000 and one of 0x100
    • AppleBasebandPCI
    • Baseband (IOPlatformDevice)
    • Has a interesting “function-coredump”
    • AppleBasebandD101
    • AppleBasebandPCIICEControl
    • AppleBasebandPCIRTIDevice
    • AppleBasebandPCIRTIInterface
    • AppleBasebandPCIPDPADAMSkywalk
    • Others… Not enough space… But you can see there is a lot of «meat»

    View full-size slide

  56. Intel Baseband Application Processor
    interface on iPhone XS/XR (Usermode)
    • AppleBasebandUserClient
    • Used by «CommCenter» but also by «locationd» to communicate
    with the kernel

    View full-size slide

  57. CommCenter
    • Usermode launchdeamon related to the modem
    • Huge binary, 24mb plus libraries
    • Runs as “_wireless” user
    • It has a couple of “helpers” CommCenterMobileHelper,
    CommCenterRootHelper
    • “CommCenter is a 30 mb binary, even with PAC I bet you can find the
    right primitives” - qwerty

    View full-size slide

  58. How to make your research easier
    • Researching on iPhone often
    requires a jailbreak on the latest
    version…
    • You can do some of the research on
    older models, or wait in 2019 for
    Intel to push some new Android
    models with the new XMM
    • Asus Zenfone 2 (Android,old as fuck)
    • Some Sierra Wireless Modules

    View full-size slide

  59. The future (guesses)
    • ASLR will soon come to all mainstream basebands, making the bar for
    RCE higher, and this could be in theory implemented right now
    • Intel CET or ARM64 PAC in the future when new SoC come out?
    • True opt out option for unauthenticated networks for the paranoid
    users? They cannot just remove the unauthenticated networks since
    they are still widespread worldwide. But it will reduce the attack
    surface.

    View full-size slide