2. Agenda
• Introduction iOS
• iOS App Architecture
• iOS App Runtime Protection Features
• Setting up our Environment
• Tools for iOS App Review
• iOS Risks Analysis
3. Introduction iOS
• Apps are among the most critical elements of
a modern mobile security architecture.
• While apps provide amazing productivity
benefits for users, also have the potential to
negatively impact system security, stability,
and user data if they’re not handled properly.
4. Introduction iOS
• Because of this, iOS provides layers of
protection
– Signed and verified
– Sandboxed to protect user data.
– …
• These elements provide a stable, secure
platform for apps without impacting system
integrity.
5. iOS App Architecture
• Typical architecture of an iOS application is shown in the
image below.
9. Non-Executable Memory
• Data pages are marked non-executable
• iOS enforces W^X page protection policy
– Pages that are writeable can not become
executable
• Injected machine code cannot be immediately
executed
21. Insufficient Transport Layer
Protection
• Are all connections properly encrypted?
• Are the SSL certificates up to date and self
signed?
• Will your application accept user accepted
certificates as authorities?
• Is Certificate Pinning present?
22. Insufficient Transport Layer Protection
• Apply SSL/TLS to transport channels that the
mobile app will use to transmit sensitive
information
• Use certificates signed by a trusted CA and
require SSL chain verification.
• Alert through the UI, if the mobile app detects
an invalid cert.
23. Unintended Data Leakage
• The way that the Application stores data,
images, key-presses, logging and buffers.
Storing data securely on a mobile device requires proper
technique. Whenever possible, simply do not store/cache
data. This is the most sure way to avoid data compromise on
the device.
24. Poor Authorization & Authentication
• Insecure Patterns:
– Persistent auth within mobile App should be
implemented as opt-in not by default
– Ensure that all authentication requests are
performed server-side.
• Developers should assume all client-side
authorization & authentication controls can be
bypassed by malicious users.
25. Poor Authorization & Authentication
• Consider the following scenario:
– Only authenticated users will be able to generate
a service request that the mobile app submits to
its backend for processing.
– During the processing of the request, the server
doesn’t verify that the request is associated with a
known user. Then adversaries can submit requests
to server anonymously.
30. Lack of Binary Protections iOS
• Can someone decrypt the app?
• Can someone use a reverse engineering tool
like Hopper ?
• The application must follow secure coding
techniques:
– Jailbreak Detection Controls
– Certificate Pinning Controls
– Debugger Detection Controls
Apps are among the most critical elements of a modern mobile security architecture.
While apps provide amazing productivity benefits for users, also have the potential to negatively impact system security, stability, and user data if they’re not handled properly
Because of this, iOS provides layers of protection
Signed and verified
Sandboxed to protect user data.
…
These elements provide a stable, secure platform for apps without impacting system integrity.
iTunesMetadata.plist to provide information to iTunes about an iOS application
Ituneartwork create the icon app and is used by the iTunes to manage the application.
Embedded: The provisioning profile is a plist file that specifies a handful of permissions for your app–most notably, the devices that it is provisioned to run on (for development or ad-hoc releases
used to randomize data on the RAM to help prevent exploits from taking control of the system.)
Phone randomizes.... Binary Libraries Dynamic loader Heap Stack etc...
is the marking of memory regions as non-executable, such that an attempt to execute machine code in these regions will cause an exception
Windows Data Execution Preventionto enforce a specific policy
which is that a given page can never be writable and executable at the same time.
Unix W^X W^X and "Once-writable, never executable" are both sub-cases of DEP. DEP is about making read accesses, and execution accesses, distinct (a writable page is also a readable page). W^X is about using DEP to enforce a specific policy, Compliance to the W^X policy can be required from the programmer because writing "data" and then executing it reliably entails flushing some caches, which is an explicit and expensive operation. Going through the kernel (with a mprotect() call) is not a hard way to do that. On the other hand, forcing the programmer to do such things explicitly means that it will not happen in other situations, namely when an attacker tries to exploit a buffer overflow. This is a generalization of the "stack is not executable" feature. (The buffer overflow is still there, though; W^X just makes life harder for the attacker.)
Manuel Reference Counting:
Automatic Reference Counting:
Retain/release memory to avoid crash
ARC works by adding code at compile time to ensure that objects live as long as necessary, but no longer. Conceptually, it follows the same memory management conventions as manual reference counting
Code Signing requires apps to be downloaded from the App Store
Publishers’ real-world identities are verified by Apple
Apps are reviewed by Apple before they are available in App Store
Apple acts as an Anti-Virus for iOS
https://developer.apple.com/app-store/review/guidelines/
Over 186 rules
Sandbox limits what applications can do Uses same mechanism as Mac OS X (Seatbelt kext) Limits what files can be read/written Limits what resources can be accessed
More restrictive sandbox Cannot access most of filesystem
Sandboxing using by the compiler
To then meet the program's needs, the developer includes a sandbox rule called an "entitlement," that allows the program to access the needed resource defined in that entitlement. The entitlements are managed by Apple, and thereby allow Apple to centralize how sandboxed programs can access resources in OS X. The developer can add as many entitlements as he wishes to give his program as much system access as is necessary; however, the idea is the developer only enables the entitlements that are needed to allow his program to run.
Never store credentials on the phone file system. Force the user to authenticate using a standard web or API login scheme (over HTTPS) to the application upon each opening and ensure session timeouts are set at the bare minimum to meet the user experience requirements.
Where storage or caching of information is necessary consider using a standard iOS encryption library such as CommonCrypto
If the data is small, using the provided apple keychain API is recommended but, once a phone is jailbroken or exploited the keychain can be easily read. This is in addition to the threat of a bruteforce on the devices PIN, which as stated above is trivial in some cases.
For databases consider using SQLcipher for Sqlite data encryption
For items stored in the keychain leverage the most secure API designation, kSecAttrAccessibleWhenUnlocked (now the default in iOS 5) and for enterprise managed mobile devices ensure a strong PIN is forced, alphanumeric, larger than 4 characters.
For larger or more general types of consumer-grade data, Apple’s File Protection mechanism can safely be used (see NSData Class Reference for protection options).
Avoid using NSUserDefaults to store senstitve pieces of information as it stores data in plist files.
Be aware that all data/entities using NSManagedObects will be stored in an unencrypted database file.
Certificate Pinning is an extra layer of security that is used by applications to ensure that the certificate provided by the remote server is the one which is expected.
By including the remote server’s x509 certificate or public key within the application, it is possible to compare the locally stored certificate or key with the one provided by the remote server.
session tokens, or other sensitive data to a backend API or web service.
Assume that the network layer is not secure and is susceptible to eavesdropping.
Never allow self-signed certificates, and consider certificate pinning for security conscious applications.
Only establish a secure connection after verifying the identity of the endpoint server using trusted certificates in the key chain.
Do not send sensitive data over alternate channels (e.g, SMS, MMS, or notifications).
*and never stored the password in the device
**Upon successful authentication, application data will be loaded onto the mobile device. This will ensure that application data will only be available after successful authentication.
The following scenarios showcase weak authentication or authorization controls in mobile apps:
Developers assume that only authenticated users will be able to generate a service request that the mobile app submits to its backend for processing. During the processing of the request, the server code does not verify that the incoming request is associated with a known user. Hence, adversaries submit service requests to the back-end service and anonymously execute functionality that affects legitimate users of the solution.
Developers assume that only authorized users will be able to see the existance of a particular function on their mobile app. Hence, they expect that only legitimately authorized users will be able to issue the request for the service from their mobile device. Backend code that processes the request does not bother to verify that the identity associated with the request is entitled to execute the service. Hence, adversaries are able to perform remote administrative functionality using fairly low-privilege user accounts.
Due to usability requirements, mobile apps allow for passwords that are 4 digits long. Server code correctly stores a hashed version of the password. However, due to the severely short length of the password, an adversary will be able to quickly deduce the original passwords using rainbow hash tables. If the password file (or data store) on the server is compromised, an adversary will be able to quickly deduce users' passwords.
Hopper disassemble, and decompile
Items within parenthesis indicate examples of tools you can use to test for these vulnerabilities.
