The document provides an overview of iOS security architecture and testing techniques for iOS applications. It discusses iOS security features like hardware security, secure boot, code signing, sandboxing and encryption. It also covers the iOS application structure, permissions, and potential attack surfaces like URL schemes, web views, and network communication. Testing tools like ZAP and Charles Proxy are introduced for analyzing network traffic of iOS apps.

1. OWASP for iOS
Phineas Huang
1

2. iOS Platform Overview
1.iOS security architecture
2.iOS application structure
3.Inter-process Communication (IPC)
4.iOS application publishing
5.iOS Application Attack Surface
2

3. iOS Security
Architecture
3

4. iOS Security Architecture
• Hardware Security
• Secure Boot
• Code Signing
• Sandbox
• Encryption and Data Protection
• General Exploit Mitigations
4

5. Hardware Security
The iOS security architecture makes good use of hardware-based security
features that enhance overall performance. Each iOS device comes with
two built-in Advanced Encryption Standard (AES) 256-bit keys. The
device’s unique IDs (UIDs) and a device group IDs (GIDs) are AES 256-bit
keys fused (UID) or compiled (GID) into the Application Processor (AP) and
Secure Enclave Processor (SEP) during manufacturing. There's no direct
way to read these keys with software or debugging interfaces such as
JTAG. Encryption and decryption operations are performed by
hardware AES crypto-engines that have exclusive access to these
keys.
The GID is a value shared by all processors in a class of devices used to
prevent tampering with firmware files and other cryptographic tasks not
directly related to the user's private data.
UIDs, which are unique to each device, are used to protect the key
hierarchy that's used for device-level file system encryption.
5

6. Secure Boot
https://varunsavy.wordpress.com/ios-platform/
The Boot ROM contains immutable
code and the Apple Root CA
If any of these steps fail, the boot
process will terminate immediately and
the device will enter recovery mode and
display the "Connect to iTunes" screen.
6

7. EPIC JAILBREAK:
Introducing checkm8
7
https://twitter.com/axi0mX/status/1177542201670168576?s=20
https://github.com/axi0mX/ipwndfu

8. Code Signing
Apple has implemented an elaborate DRM (Digital Rights
Management) system to make sure that only Apple-approved
code runs on their devices, that is, code signed by Apple. In
other words, you won't be able to run any code on an iOS
device that hasn't been jailbroken unless Apple explicitly
allows it.
8

9. Sandbox
https://developer.apple.com/library/archive/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/FileSystemOverview/FileSystemOverview.html
Sandboxing has been a core
security feature since the first
release of iOS. All third-party apps
run under the same user (mobile),
and only a few system applications
and services run as root (or other
specific system users). Regular
iOS apps are confined to a
container that restricts access to
the app's own files and a very
limited number of system APIs.
Access to all resources (such as
files, network sockets, IPCs, and
shared memory) are controlled by
the sandbox.
9

10. General Exploit Mitigations
iOS implements address space layout randomization (ASLR) and eXecute Never (XN) bit to
mitigate code execution attacks.
ASLR randomizes the memory location of the program's executable file, data, heap, and
stack every time the program is executed. Because the shared libraries must be static to be
accessed by multiple processes, the addresses of shared libraries are randomized every time
the OS boots instead of every time the program is invoked. This makes specific function and
library memory addresses hard to predict, thereby preventing attacks such as the return-to-
libc attack, which involves the memory addresses of basic libc functions.
The XN mechanism allows iOS to mark selected memory segments of a process as non-
executable. On iOS, the process stack and heap of user-mode processes is marked non-
executable. Pages that are writable cannot be marked executable at the same time. This
prevents attackers to execute machine code injected into the stack or heap.
10

11. iOS Application
Structure
11

12. Apps on iOS
iOS apps are distributed in IPA (iOS App Store Package) archives. The IPA file is a ZIP-compressed archive that
contains all the code and resources required to execute the app.
IPA files have a built-in directory structure. The example below shows this structure at a high level:
• /Payload/ folder contains all the application data. We will come back to the contents of this folder in more detail.
• /Payload/Application.app contains the application data itself (ARM-compiled code) and associated static
resources.
• /iTunesArtwork is a 512x512 pixel PNG image used as the application's icon.
• /iTunesMetadata.plist contains various bits of information, including the developer's name and ID, the bundle
identifier, copyright information, genre, the name of the app, release date, purchase date, etc.
• /WatchKitSupport/WK is an example of an extension bundle. This specific bundle contains the extension delegate
and the controllers for managing the interfaces and responding to user interactions on an Apple Watch.
12

13. IPA Payloads
• MyApp: The executable file containing the compiled (unreadable) application source code.
• Application: Application icons.
• Info.plist: Configuration information, such as bundle ID, version number, and application
display name.
• Launch images: Images showing the initial application interface in a specific orientation.
The system uses one of the provided launch images as a temporary background until the
application is fully loaded.
• MainWindow.nib: Default interface objects that are loaded when the application is launched.
Other interface objects are then either loaded from other nib files or created
programmatically by the application.
• Settings.bundle: Application-specific preferences to be displayed in the Settings app.
• Custom resource files: Non-localized resources are placed in the top-level directory and
localized resources are placed in language-specific subdirectories of the application bundle.
Resources include nib files, images, sound files, configuration files, strings files, and any
other custom data files the application uses.
13

14. App Permissions
Starting with iOS 10.0, apps must include usage description keys for the types of permissions
they request and data they need to access
Contacts
Microphone
Calendars
Camera
Reminders
HomeKit
Photos
Health
Motion activity and fitness
Speech recognition
Location Services
Bluetooth sharing
Media Library
Social media accounts
14

15. iOS Application
Attack Surface
15

16. iOS Application Attack
surface
Validate all input by means of IPC communication or URL schemes, see also:
Testing Custom URL Schemes
Validate all input by the user in input fields.
Validate the content loaded inside a WebView, see also:
Testing iOS WebViews
Determining Whether Native Methods Are Exposed Through WebViews
Securely communicate with backend servers or is susceptible to man-in-the-middle (MITM)
attacks between the server and the mobile application, see also:
Testing Network Communication
iOS Network APIs
Securely stores all local data, or loads untrusted data from storage, see also:
Data Storage on iOS
Protect itself against compromised environments, repackaging or other local attacks, see also:
iOS Anti-Reversing Defenses
16

17. Testing Custom URL
Schemes
URL schemes offer a potential attack vector into your app, so
make sure to validate all URL parameters and discard any malformed
URLs. In addition, limit the available actions to those that do not risk
the user’s data.
For example, do not allow other apps to directly delete content or
access sensitive information about the user. When testing your
URL-handling code, make sure your test cases include improperly
formatted URLs.
17

18. Testing iOS WebViews
https://forums.developer.apple.com/thread/122114
18

19. Testing iOS WebViews
WebViews are in-app browser components for displaying interactive web content. They can
be used to embed web content directly into an app's user interface. iOS WebViews support
JavaScript execution by default, so script injection and Cross-Site Scripting attacks can affect
them.
19

20. Determining Whether Native Methods
Are Exposed Through WebViews
20
Since iOS 7, Apple introduced APIs that allow communication
between the JavaScript runtime in the WebView and the native
Swift or Objective-C objects. If these APIs are used carelessly,
important functionality might be exposed to attackers who
manage to inject malicious scripts into the WebView (e.g.,
through a successful Cross-Site Scripting attack).
https://github.com/OWASP/owasp-mstg/blob/master/Document/0x06h-Testing-Platform-Interaction.md#determining-whether-native-methods-are-exposed-through-webviews-mstg-platform-7

21. Testing Network
Communication
21
https://github.com/OWASP/owasp-mstg/blob/master/Document/0x04f-Testing-Network-Communication.md#testing-network-communication
Practically every network-connected mobile app uses the Hypertext Transfer Protocol (HTTP)
or HTTP over Transport Layer Security (TLS), HTTPS, to send and receive data to and from
remote endpoints. Consequently, network-based attacks (such as packet sniffing and man-in-
the-middle-attacks) are a problem. In this chapter we discuss potential vulnerabilities, testing
techniques, and best practices concerning the network communication between mobile
apps and their endpoints.
App(iPhone) MIMA Tool Server

22. OWASP ZAP
22

23. ZAP Setup(1)
23
https://github.com/zaproxy/zaproxy/wiki/Downloads
Install the App

24. ZAP Setup(2)
24
Generate the certificate file

25. ZAP Setup(3)
25
Share the cer file to your iPhone device
Settings -> General -> Profiles & Device Management

26. ZAP Setup(4)
26
Settings -> General -> About -> Certificate Trust Settings

27. ZAP Setup(5)
27
Set up your Address & Port on ZAP

28. ZAP Setup(6)
28
Settings -> Wi-Fi -> Wi-Fi Settings -> HTTP PROXY

29. ZAP Setup(7)
29
Internet Search ZAP

30. Charles
30

31. Charles Setup(1)
31
https://www.charlesproxy.com/documentation/
Install the App

32. Charles Setup(2)
32
https://www.charlesproxy.com/documentation/
Setup the port

33. Charles Setup(3)
33
https://www.charlesproxy.com/documentation/
Setup the Certificate

34. Charles Setup(4)
34
https://www.charlesproxy.com/documentation/

35. Charles Setup(5)
35
https://www.charlesproxy.com/documentation/
Setup the certificate for the mobile

36. Charles Setup(7)
36
https://www.charlesproxy.com/documentation/
Switch to iPhone & Set up the Wi-fi at the same SSID

37. Charles Setup(8)
37
https://www.charlesproxy.com/documentation/
Settings -> Profiles & Device Management

38. Charles Setup(9)
38
https://www.charlesproxy.com/documentation/
Settings -> About -> Certificate True Settings

39. Other
39

40. Apple extends deadline for new HTML5
App Store guidelines to March 2020
https://developer.apple.com/app-store/review/guidelines/#third-party-software
https://9to5mac.com/2019/09/06/apple-extends-deadline-for-new-html5-app-store-guidelines-to-march-2020/
40

41. CNCopyCurrentnetworkInfo(1)
41

42. CNCopyCurrentnetworkInfo(2)
https://developer.apple.com/videos/play/wwdc2019/713/
42

43. Reference
https://www.apple.com/business/docs/site/iOS_Security_Guide.pdf
https://github.com/OWASP/owasp-mstg/blob/master/Document/0x06a-Platform-Overview.md
https://kevin.net.nz/post/using-owasp-zap-with-ios/
43