Mobile Systems and Smartphone Security�(MOBISEC 2020)

Prof: Yanick Fratantonio / EURECOM�With huge thanks to Ivan Rodriguez @ivRodriguezCA

1

iOS Security

iOS Security

• Quick overview on iOS and iOS security

​

• We don't have time to dig into very low-level details, but we have enough time to cover major differences and interesting points

​

• Disclaimer: I'm NOT a super-expert on iOS security!
• But: I asked some "actual expert" to check these slides :-)

2

iOS apps

• Written in Objective C, now also in Swift

​

• Code is compiled directly to assembly (ARM)
• There is no bytecode!
• Much more difficult to reverse engineer

​

• But it gets worse...

3

iOS apps

• Every "method invocation" is transformed to a call to objc_msgSend(self, "method selector")
• "method selector" is a pointer to a string!
• The string specifies which method should be actually invoked
• backward dataflow + string analysis just to determine which method is called??
• First big difference: disassembling an app is not as trivial as with Dalvik bytecode
• But: in Swift the methods are mangled, so it's less bad

4

iOS apps

• In the general case: apps need to be published on the Apple Store before they can be installed on devices
• Details later
• The app is shipped/installed encrypted
• It is decrypted at run-time when the app starts
• Note: only a portion of the binary is encrypted, all the embedded files and resources are not
• Many devs add secrets in config files thinking these are encrypted!
• iOS apps are developed with macOS' Xcode IDE
• Developing iOS apps on Windows/Linux is a mess...

5

iOS modern security features

• Code signing
• Only "signed code" will be executed by the kernel
• It needs to be signed by Apple itself
• Only pages in memory that come from signed sources will be executed
• Apps can't change their behavior & update themselves
• Apps can't download+execute arbitrary code

​

• The code is signed when Apple "approves" the app to the Apple store

​

• *Very* big difference wrt Android!

6

Code signing exceptions

• The fact that Apple needs to sign ALL code that needs to be executed is very constraining; there are exceptions
• Enterprise / universities: they want to deploy their own apps, without having Apple in the loop
• They need to register for an Enterprise account, and then Apple provide certificates (signed by Apple) to sign the Enterprise apps
• Ad-hoc, modified devices that can provision the code they want
• Developers also have a way to bypass code signing
• They are still signed with a Dev cert (that lasts only 7 days)
• Details later, see "provisioning system"

7

Code signing exceptions

• Code signing, in theory, affects all code + libraries

​

• But browsers need to JIT javascript!
• JIT: Javascript is Just-In-Time-compiled to assembly and executed
• Javascript is served from within web pages, Apple can't preemptively sign them all

​

• One exception: "browsers" can create a WX area + JIT
• But, to prevent abuse, only ONE such area can be created

8

Data Execution Prevention

• Code and data sections
• Code sections are not writable
• Data sections are not executable

​

• We have the same protection in Linux...
• Common bypass: code reuse / ROP to create WX memory ⇒ stage two

​

• ... but in iOS is trickier: you can't create WX memory
• The entire payload needs to be via ROP

​

9

Apple store app reviews

• Developers develop an iOS app, then they submit it to the store for approval

​

• The review process seems more thorough wrt Google's
• I have friends whose app got rejected because "the UI was not nice enough"

​

• If Apple approves, the app/code is signed and can be executed on Apple devices

10

Code Signing Bypass

• Is there any way to bypass Apple's code signing?
• Bypass ⇔ developer can execute additional code after the approval

​

• People have found bugs in the code signature verification process... but is there something deeper?

​

• "Jekyll on iOS: When Benign Apps Become Evil"
• Write app so that it contains a hidden memory corruption vuln
• Hope that Apple doesn't find it (that's a fair assumption!)
• After approval, exploit the vuln to gain arbitrary code execution

11

Provisioning System

• Individual developers need to test their apps!

​

• Steps for developer
• She creates a dev account with Apple (and pay an annual fee)
• She generates crypto keys
• She generates a "provision file" + specify
• WHICH device she wants to use
• Entitlements (which are special capabilities required by apps, like CloudKit/Keychain/VPN access)
• She can now run her app on that device

12

Provisioning System

• Modern versions of Xcode/iOS allow developers/users to install apps outside the Apple store, but only if the source code is available

​

• This is one of the many reasons why doing research on iOS is a pain...

13

Security Mechanisms

• Apple toolchain supports the classic protection mechanisms

​

• ASLR, stack canaries, ...

14

App sandbox

• Privilege separation: apps have users/groups, they run in different processes with different users

​

• Sandbox is stricter than Android's
• Apps can only read/write their own files
• Apps can read "external files" only via user interaction / input
• Example
• To transfer a file from an app to another one, the app needs to show a UI picker to the user -- the user needs to be involved, she can't be left outside the loop

15

Permissions

• In the past
• All apps run in the same type of sandbox
• If it's ok for third-party app to have access to capability X, then all third-party apps have access to it
• There was no permission system, and apps were able to access address book, GPS info, wifi AP names by using public APIs
• BUT: in early versions of iOS, only system apps could be installed!
• There was no Apple store for third-party apps!
• Modern versions
• Permission system like Android's run-time permission model
• But: third-party apps can't ask for "draw on top", a11y, ...

16

Public vs. Private APIs

• Public APIs: APIs described in Apple's documentation
• Apps can use these without problems

​

• Private APIs
• There are a number of APIs that are "private"
• They are not discussed in the documentation
• "Interesting" design: private APIs ARE available within the memory space of every app -- they are just "hidden"
• But there are of course many tricks to "discover them" at run-time...
• ... and to invoke them

17

Public vs. Private APIs

• Apple's Term of Service:
• "Apps should NOT use private APIs"
• This is ground for rejection

​

• But apps can technically do so... and it's not simple to analyze them...

​

• "iRiS: Vetting Private API Abuse in iOS Applications"
• 7% of apps on the Apple store made use of private APIs...

18

Additional Hardening

• There is no "shell" in iOS
• You either run stuff in the context of the exploited device, or you need to bring all the code you need with you

​

• iOS is based on BSD, but some calls are disabled
• system(), fork(), exec() are disabled
• An app CANNOT start a new app or launch a binary tool to process data
• An app CAN start a new thread, but it will be inside the main app

19

Additional Hardening

• Secure boot (similar to Android's)

​

• Data encryption (similar to Android's)
• UID key (embedded in hw, not accessible via sw) ⇒ device key
• User-provided passcode (unlock) + UID key ⇒ passcode key
• Four protection classes
• Complete: file is protected and can be accessed only when device is unlocked
• Complete unless open: file can be open only when unlocked, but then it's accessible
• Protection until first user auth: file is protected until device boot + unlock first time
• No protection

20

Additional Hardening

• Kernel Integrity Protection (KIP)
• After the iOS kernel completes initialization, the memory controller deniers writes to the protected physical memory region

​

• Touch ID / Face ID
• Touch ID: nothing special (wrt to what you can imagine from a touch ID)
• Face ID: high-tech stuff, "invisible grid of dots projected towards your face to build a 3D model"
• Claim from a company: "it has been hacked" (news article)
• But the news is quite old and I didn't see follow ups. They may have overclaimed.

21

Secure Enclave

• The Secure Enclave is a separate, high-security processor
• The analogous of ARM TrustZone

​

• The Secure Enclave checks that its own software is signed by Apple before booting

​

• Many security-related APIs rely on it
• Encryption-related material, Touch ID, Face ID, Apple Pay

22

Pointer Authentication Codes

• Pointer Authentication Codes (PAC)
• PAC-protected pointers contain the address + crypto/auth tag
• An attacker can't arbitrarily alter a pointer to make it point somewhere else -- even if she has full write capabilities!

​

• Goal: mitigate memory corruption vulns, making them more difficult to exploit
• But not impossible; some bypass techniques are known
• SLOP technique (*very recent*)

​

• More info by Qualcomm: link

23

Jailbreak

• iOS devices are very "closed down"

​

• Users want to do more stuff with their devices

​

• Jailbreak: the process of getting "root" on these devices

24

Why Jailbreak?

• Disable iOS security checks

​

• Install arbitrary apps (even third-party closed-source)

​

• Gain root access

​

• Load arbitrary customization
• Custom UI, custom kernel, ...

25

Cydia

• Cydia is a package manager for iOS mobile apps

​

• Used on jailbroken iPhones to install third-party apps

​

• Cydia Substrate: framework to modify iOS with extensions

26

Jailbreak: history and current status

• First jailbreak for iPhone 1.0 in 2007
• Several jailbreaks for other versions follow
• "jailbreakme.com" remote jailbreak (2011)
• aka "jailbreakme 3.0"
• Jailbreak by just visiting a URL
• People were trolling Apple by going to Apple stores and visiting this website with the "free to use" devices there

27

Jailbreak: history and current status

• Current status:
• There is a big community of people that PRETEND jailbreaks
• People that find these bugs/exploit them got pissed, stopped releasing
• Apple would fix them immediately anyways...

​

• Most recent news
• checkm8 bootrom exploit
• unpatchable!
• Based on that: checkrain jailbreak https://checkra.in/
• Note difference between bug / exploit / full jailbreak!

28

Reversing iOS apps

• Run the app in a jailbroken device and dump memory to get the decrypted app's content
• Tool: Clutch (load, set breakpoint, dump, ...)

​

• Analyze it in IDA

​

• Tools like frida work on iOS as well...

​

• Use cydia / other "environments" to install openssh / other tools to have a decent debugging/devel environment

29

Jump back to the past...

30

Modern devices are very secure...

• ... but how did it all start?

​

• iOS 1 was the first smartphone ever

​

• How secure was it?

31

iOS 1 -- OMG

• No privilege separation, all processes run as root!

​

• No code-signing enforcement

​

• No DEP, no ASLR, no sandboxing

​

• It was embedding libraries with known vulnerabilities

​

• (Note: you could not install third-party apps!)

32

libtiff exploit

• Exploit for a known libtiff bug (iOS 1)

​

• Malicious link ⇒ Instant root

33

SMS exploit

• Affected iOS 2
• DEP + sandboxing, but no ASLR

​

• Target: SMS component, running as root

​

• Bug in SMS handling
• Remote root
• There was no way to disable SMS functionality...

34

The Ikee worm

• People were jailbreaking iOS 2 to install custom apps...

​

• ... they were also installing SSH servers...
• ... running as root (not sandboxed)...
• ... with the default username/password...

​

• Worm! Computer malware that spread itself attacking other computers around
• Rick Rolling victims, locking phone for ransom, stealing content, botnet
• Check here for the demo (Note: I'll ask about this at the final!)

35

More resources

• https://www.owasp.org/images/b/b9/OWASP_Mobile_App_Hacking_%28AppSecUSA_2014%29_Workshop_Content.pdf

​

• iOS Hacker's Handbook

​

• New: Reverse Engineering iOS apps

36