AusCERT - Developing Secure iOS Applications

Developing Secure iOS
Applications
Michael Gianarakis
AusCERT 2017

whoami
@mgianarakis
Director, Trustwave SpiderLabs
SecTalks Brisbane
Flat Duck Justice Warrior

This Presentation
• Aims to give a good overview of how to design secure iOS
applications
• Focuses on the key security issues commonly found in iOS
applications
• Not a guide to hacking iOS applications

Topics
• Overview of the iOS attack surface
• Common iOS security issues
• Secure iOS application design principles
• Secure development approaches for key security iOS issues

iOS Application Attack Surface

Your App
Other
Apps
Network
iOS
Device
Your
Backend
3rd Party
Services
IPC,
Extensions
WiFi, LTE

Your App
Other
Apps
Network
iOS
Device
Your
Backend
3rd Party
Services
Man in the
middle attacks

Your App
Other
Apps
Network
iOS
Device
Your
Backend
3rd Party
Services
Man in the
middle attacks
Server
compromise and
web attacks

Your App
Other
Apps
Network
iOS
Device
Your
Backend
3rd Party
Services
Man in the
middle attacks
Server
compromise and
web attacks
Jailbroken or
compromised
device

Your App
Other
Apps
Network
iOS
Device
Your
Backend
3rd Party
Services
Malicious
apps
Man in the
middle attacks
Server
compromise and
web attacks
Jailbroken or
compromised
device

Understanding the Risk Proﬁle of Your App
• Important ﬁrst step that is often overlooked.
• Drives the security design of your application
• Key considerations:
• What information is in the app and how sensitive/valuable is it?
• Who are the likely threat actors? How capable are they?
• What are the likely attack scenarios for each threat actor?
• What is your tolerance for risk?
• Regulatory requirements?

Common iOS Application
Security Issues

Common Issues
• Based on working with a range of companies and a variety of applications including:
• Mobile banking and trading apps
• Board paper apps
• Internal business apps
• Retail apps
• Social networking apps
• Games

Binary and runtime security
issues

Transport layer security issues

Get these right and you are
ahead of the pack

Don’t trust the client or the
runtime environment

Users will connect to untrusted
networks

Don’t store anything sensitive
on the device

Binary and Runtime Security
• As a reﬂective language, Objective-C can observe and modify it’s
own behaviour at runtime.
• Can be great from a development perspective
• Not so much from a security perspective

Binary and Runtime Security
• The ability to create and call ad hoc classes and methods on the ﬂy allows attackers to
manipulate and abuse the runtime of the application:
• Bypass security locks
• Break logic checks
• Escalate privilege
• Steal information from memory.
• Implementing runtime security checks signiﬁcantly increases the security of your application
• You should always assume that your application will run on a compromised device

What about Swift?
• Less dynamic than Objective-C
• Less ﬂexible than Objective-C in some areas
• Harder to perform the dynamic techniques described previously in
the same way but still possible - particularly in mixed runtime apps
• Greater dynamism planned for future versions of Swift

Myths Surrounding Jailbreaking
• Generally speaking, iOS is one of the most secure operating
systems available
• One of the deﬁning security features of iOS is the chain of trust.
Every bit of code is signed and approved by Apple.
• Break that trust and all bets are off

Myths Surrounding Jailbreaking
• Some of the security issues discussed in this presentation will
require a compromised device
• This is usually the cause of a lot of misunderstanding when it comes
to assessing the impact of these issue

Myth 1 - Public jailbreaks are
the only jailbreaks

Myth 1 - Public jailbreaks are the only jailbreaks
• I often hear “but there is no jailbreak for version x.x.x so we are
safe”
• FACT: Public jailbreaks for every version of iOS released so far
• FACT: Not all users update to the latest ﬁrmware
• FACT: iOS vulnerabilities are extremely valuable, there are many
more exploits than just those that people give out for free on the
internet

Myth 2 - Jailbreaks require
physical access to the device

Myth 2 - Jailbreaks require physical access to the device
• I often hear “well someone would need to steal the device to compromise it”
• FACT: Not all exploits require physical access.
• jailbreakme.com TIF image processing vulnerability and PDF processing vulnerability required
only a user visit a web page in Safari
• Remote code execution via SMS found by Charlie Miller (https://www.blackhat.com/
presentations/bh-usa-09/MILLER/BHUSA09-Miller-FuzzingPhone-PAPER.pdf)
• Nitro JIT vulnerability to download and execute unsigned code via POC app that was
approved also found by Charlie Miller (http://reverse.put.as/wp-content/uploads/2011/06/
syscan11_breaking_ios_code_signing.pdf)
• Vulnerability in carrier mandated baseband control protocols by Matt Solnik and Marc
Blanchou (https://www.blackhat.com/docs/us-14/materials/us-14-Solnik-Cellular-
Exploitation-On-A-Global-Scale-The-Rise-And-Fall-Of-The-Control-Protocol.pdf)

Myth 3 - Jailbreaks are always
obvious to the user

Myth 3 - Jailbreaks are always obvious to the user
• It is a commonly held misconception that if Cydia is not on the
device then it is not jailbroken.
• Cydia is an app that is commonly installed with public jailbreaks but
is certainly not a prerequisite or in any way required for a jailbreak.
• In fact, any kind of targeted exploit is unlikely to install Cydia in the
ﬁrst place.

Myth 4 - Jailbreaking is Apple’s
problem

Myth 4 - Jailbreaking is Apple’s problem
• FACT: The security of your app, your data and your users is your
responsibility.
• FACT: The security risk to your organisation is your responsibility.
You will be the one that suffers the impact if your app is
compromised and you should be actively managing that risk.
• FACT: Apple won’t secure your app for you.

Myth 5 - You can completely
protect against jailbreaking

Myth 5 - You can completely protect against jailbreaking
• FACT: Unfortunately you will never be able to completely secure an
application.
• The idea is to raise the bar for the security of your app so that it
becomes too difﬁcult or costly to attack.

Debug Check
• A simple and effective method of securing the runtime is to
implement anti-debugging control.
• There may be reasons to allow an application to run on a jailbroken
device but there are no legitimate reasons for debugging a
production application

Debug Check
• Debugging protection can be implemented using the following techniques:
• Periodically monitoring the process state ﬂag to determine if application process
is being debugged and then terminating the process.
• Using the ptrace request PT_DENY_ATTACH two prevent future tracing of the
process. This can be done with the following function call from within the
application:
• ptrace(31,0,0,0)
• These techniques should be used in conjunction with each other to provide a
more robust anti-debugging control.

Jailbreak Detection
• There are multiple ways to implement jailbreak detection but the
two most common methods are:
• File system check
• Sandbox integrity check

File System Check
• File system checks test for the presence of files that are typically found on jailbroken
devices.
• Some examples of files to look for:
• /Library/MobileSubstrate/MobileSubstrate.dylib
• /var/cache/apt
• /var/lib/apt
• /bin/bash and /bin/sh
• /usr/sbin/sshd and /etc/ssh/sshd_config

File System Check
• When implementing a file system check you should ensure you
check for multiple files using different methods such as
fileExistsAtPath and isReadableFileAtPath
• This protects against attacks that simply patch the implementation
of these methods.

Sandbox Integrity Check
• A sandbox integrity check tests that the integrity of Apple’s sandbox is intact
on the device, and that the application is running inside it.
• A sandbox integrity check works by attempting to perform an operation that
would not typically succeed on a device that has not been jailbroken.
• A common test is to attempt to use the fork function to spawn a new child
process
• If it works - sandbox integrity is compromised
• If it doesn’t - all good

Jailbreak Detection
• Check out the IMAS project’s Security Check module https://
github.com/project-imas/security-check
• A bit old now but still solid

Inline Functions
• Any sensitive functions such as the security checks should be
compiled as inline functions
• Inlining functions complicates attacks that involve editing memory
and patching the application by forcing an attacker to ﬁnd and
patch all occurrences of the code.
• Specify a function as inline using the
__attribute__((always_inline)) compiler directive.

Inline Functions
• This directive may not always be honoured however. To minimise the
chance that this will happen configure the following:
• Set the -finline-limit compiler flag high enough to allow for inlining of
your code (e.g. 5000)
• Set the optimisation level at least -O1
• Don’t use -unit-at-a-time (note this is automatically set at -O3 and above)
• Don’t use -keep-inline-functions if your functions are static

Address Space Validation
• Any time malicious code is injected into your application it must be
loaded into an address space
• Validating the address space adds complexity to attacks as it forces
an attacker to inject the malicious code into the existing address
space with the valid code or attacking dynamic linker

Address Space Validation
• The dladdr function in the dynamic linker library returns
information about the address space a particular function belongs
to.
• Passing it the function pointer of a class’s method implementation
can determine whether it came from your app, Apple’s frameworks,
or an unknown/malicious source

Avoid Simple Logic
• Simple logic checks for security functions and business logic are
susceptible to to manipulation.
• Examples include:
• - (BOOL) isLoggedIn
• BOOL isJailbroken = YES
• - (void) setDebugFlag

Securing Memory
• Instance variables stored within Objective-C objects can be easily
mapped inside the Objective-C runtime.
• Never store anything in memory until the user has authenticated
and data has been decrypted.
• Manually allocate memory for sensitive data rather than storing the
data (or pointers to this data) inside Objective-C instance variables.
• Wipe sensitive data from memory when it’s not needed.

Transport Layer Security
• Users will connect their devices to untrusted networks
• If your app handles sensitive data you should be encrypting all
trafﬁc between the app and the back end.

App Transport Security
• App Transport Security (ATS) was introduced in iOS 9 requires that
all apps use HTTPS to secure all network connections
• Use of ATS is intended to mandated by Apple for all App Store
apps - original deadline was the end of 2016 but this was extended
• Forces the use of the latest protocol versions (i.e TLS v1.2)

• There is some ﬁne grained control available to developers
• Can set per domain exceptions in Info.plist

• Possible to completely bypass ATS
• Don’t do this….

Cipher Suites
• You should disable support for low and medium strength cipher suites on the
server.
• Can also control on the client to some extent although less relevant now with ATS
• If using NSURLSession you can specify the minimum supported TLS protocol
version by setting the TLSMinimumSupportedProtocol property in the
NSURLSessionConfiguration
• If using NSURLConnection there is no API to set minimum protocol however it’s
possible by working with lower level C functions in the older Core Foundation
frameworks but not worth it

Certificate Validation
• Always perform certificate validation checks
• When using Apple frameworks iOS will accept a certificate if it’s
signed by a CA in the trust store
• Certificate validation checks will often be overridden in
development to avoid issues with self-signed certs.
• Typically this is encapsulated in a variable somewhere or in some
other simple logic that can be subverted.

Certiﬁcate Validation
• To avoid having to do this, use valid certs in development (e.g. free
certs)
• If you do need to disable validation, ensure that the production
builds essentially “hard code” validation.
• Consider certiﬁcate pinning.

Certificate Pinning
• Mobile apps are great candidates for certificate pinning as they only
need to communicate with a small, clearly defined set of servers
• Certificate pinning improves security by removing the need to trust
the certificate authorities.
• iSEC partners have a great library for implementing certificate
pinning https://github.com/iSECPartners/ssl-conservatory
• It is important to remember that when pinning a certificate that if you
need to revoke the certificate it will mean an app update.

Two types of data security
issues….

Sensitive data stored on the device by
the application that was not secured
appropriately by the developer

Unintended data leakage via
system functionality

Insecure Data Storage
• It’s common to ﬁnd sensitive data stored insecurely on the device.
• As a general rule sensitive information should not be stored on the
device at all.
• Really consider the need to store sensitive information on the
device. Generally it is functionally and technically possible to not
store the data at all.

Property List Files
• Don’t store sensitive information using NSUserDefaults. Plist files are unencrypted
and can easily be retrieved from the device and backups
• Find all sorts of sensitive information stored in the clear in property list files
including:
• Passwords
• Session tokens
• Sensitive configuration items
• PII (if you consider that sensitive)

SQLite Databases
• Avoid storing sensitive information in SQLite databases if at all
possible.
• If you need to store sensitive information encrypt the database
using SQLCipher https://github.com/sqlcipher/sqlcipher
• If you are using Core Data the Encrypted Core Data module of the
IMAS project leverages SQLCipher to encrypt all data that is
persisted https://github.com/project-imas/encrypted-core-data/

Data Protection APIs
• If you need to write files with sensitive information to the device
(not credentials) at a minimum write files with an appropriate data
protection attribute
• If you don’t need to access the file in the background use
NSFileProtectionComplete (for NSFileManager) or
NSDataWritingFileComplete (for NSData).
• With this attribute set the file is encrypted on the file system and
inaccessible when the device is locked.

Data Protection API
• If you need to access the file in the background use
NSFileProtectionCompleteUnlessOpen for (NSFileManager) or
NSDataWritingFileProtectionCompleteUnlessOpen (for NSData)
• With this attribute set the file is encrypted on the file system and
inaccessible while closed.
• When a device is unlocked an app can maintain an open handle to
the file even after it is subsequently locked, however during this
time the file will not be encrypted.

Unintended Data Leakage
• Sensitive data captured and stored automatically by the operating
system.
• Often developers are unaware that the OS is storing this
information.

Background Screenshot
• Every time an application suspends into the background, a
snapshot is taken to facilitate the launch animation.
• Stored unencrypted in the app container.
• This allows attackers to view the last thing a user was looking at
when the application was backgrounded.

• Place content clearing code in the state transition methods
applicationDidEnterBackground and applicationWillResignActive
• The simplest way to clear the screen contents is to set the key
window’s hidden property to YES.

• Be careful, if there are any other views behind the current view, these
may become visible when the key window is hidden.
• Other methods:
• Manually clearing sensitive info from the current view
• Placing the launch image in the foreground
• Note: ingoreSnapshotOnNextApplicationLaunch will not prevent
the screenshot from being taken

URL Caching
• iOS automatically caches requests and responses for protocols that support
caching (e.g. HTTP/HTTPS) and stores them unencrypted in a SQLite
database in the app container.
• Make sure to conﬁgure the server to send the appropriate cache control
headers
• Cache-Control: no-cache, no-store
• Expires: 0
• Pragma: no-cache

URL Caching
• Can also control caching in the client.
• For NSURLConnection implement the
connection:willCacheResponse: delegate method
• For NSURLSession set the URLCache property to NULL

Logging
• Less of an issue since iOS 7
• Pre-iOS 7 any app was able to view the device console and thus any sensitive data
that was logged.
• Still a good idea to make sure nothing is sensitive is logged.
• If you must log sensitive information in development for debugging purposes
special care should be taken to ensure that this code is not pushed to production.
• One way to do this is to redeﬁne NSLog with a pre-processor macro such as
#deﬁne NSLog(…)

Pasteboard
• When the Cut or Copy buttons are tapped, a cached copy of the
data stored on the device’s clipboard -/private/var/mobile/Library/
Caches/com.apple.UIKit.pboard/pasteboard.
• If the application handles sensitive data that may be copied to the
pasteboard consider disabling Copy/Paste functionality for
sensitive text ﬁelds (note this is done by default for password ﬁelds)

Pasteboard
• To disable pasteboard operations for sensitive ﬁelds subclass
UITextView and override the canPerformAction:withSender:
method to return NO for actions that you don’t want to allow or just
disable the menu completely

Autocorrect Cache
• iOS keeps a binary keyboard cache containing ordered phrases of
text entered by the user – /private/var/mobile/Library/Keyboard/
dynamic-text.dat
• To avoid writing data to this cache you should turn autocorrect off
in text ﬁelds whose input should remain private.
• To turn autocorrect off, the developer should set
textField.autocorrectionType to UITextAutocorrectionTypeNo for all
sensitive text ﬁelds

Cryptography
• Getting cryptography right in mobile apps is difﬁcult.
• The primary challenge is key management.
• Most apps fall prey to storing the key with the lock.
• Need to use a key derivation function.

Key Management
• Don’t hard code an encryption key in the binary as it can easily be
retrieved running strings on the binary.
• Storing an encryption key in the Keychain is not secure on
compromised devices.
• On a compromised device encryption keys can also be retrieved from
memory. You should manually allocate memory for encryption keys
rather than storing them in Objective-C instance variables.
• Wipe keys from memory when not needed.

Key Management
• Use a key derivation function to derive a key to use to encrypt the
master key.
• Should be based on a secret input such as the user’s password.
• Don’t just use a cryptographic hash of the key.
• Use a sensible salt such as the identiﬁerForVendor

Insecure Algorithms
• Shouldn’t need to tell this group but
• MD5, SHA1, RC4, MD4 algorithms are weak and should not be
used

Custom Encryption Algorithms
• Don’t do it.

Q&A?
Twitter: @mgianarakis
Blog that hasn’t been updated in years: eightbit.io

AusCERT - Developing Secure iOS Applications

More Related Content

What's hot

Similar to AusCERT - Developing Secure iOS Applications

More from eightbit

Recently uploaded

AusCERT - Developing Secure iOS Applications