Slides of the Talk I Gave at Pragma Mark Conference 2014
iOS APPS SECURITY
Mobile Security Researcher @ viaForensics
• R&D Team Member @ viaForensics
• Part of my job is to attack and break
Black Box Approach
We can use the app,
• We will focus on apps side security, no
server side. When possible we will refer back
to OWASP categories to be more clear.
• Concrete approach, not theoretical only, with
real world examples.
• Explain the tools used, and why Jailbreak is
important doing these assessments, but
nullify your device security (more or less).
• Try to share the passion for Reverse
M3 - INSUFFICIENT TRANSPORT LAYER
• First vulnerabilities and attacks that we speak about because they
affects every user of your mobile application, without even have to
make distinction of having physical access to the device, or if it’s
jailbroken or not.
• If the informations leaked are valuable the risk of this vulnerability is
usually high, because it’s easy to exploit. It can also lead to the
exploitation of other vulnerabilities (like malicious content injection)
Snifﬁng credentials like in the '90
SIMPLE PCAP CAPTURE
You can just listen your network for trafﬁc and you will ﬁnd the credentials
passed in a HTTP GET request as a parameter in plain text
• wireshark or any other tool to visualize trafﬁc
• more advanced tool, like burp or mitmproxy
SAME PLATFORM, SAME STORY…
MAYBE TV IS
Nope, same issues…
Again password in plain text in the packet capture.
WHO CAN SEE THESE PASSWORDS?
• Any network node your trafﬁc passes from your iOS device to the
server, maybe somebody is listening?
• Anyone on your network that can somehow access your trafﬁc.
(Sysadmins? Other users passively or actively listening for other’s
HOW CAN I PREVENT THIS?
• You must protect data in transit
• It’s not that hard :) Use SSL/TLS (i.e. use HTTPS instead of HTTP and
don’t pass stuff in ﬂying GET parameters for example.)
• Don’t disable certiﬁcate validation! At least be sure to don’t do it
in production! Otherwise your implementation will be pretty much
WHAT ABOUT CERTIFICATE
• By default the certiﬁcate is accepted if it’s signed by a CA that ships in
• If you disable the validation, any certiﬁcate will be accepted.
• If you disable it an attacker can MiTM the communication, intercepting it
and see everything, resigning the trafﬁc going to your device, and you will
not be able to verify if you are speaking with the legitimate server
without someone in the middle!
• Use SSL/TLS typically using HTTPS instead of HTTP.
• Don’t override settings just to get stuff work! Buy a valid certiﬁcate.
WHAT IF MY APPLICATION NEEDS A
HIGHER LEVEL OF SECURITY?
• Scenario: my app transmit very sensitive
data (banking apps for example)
• I don’t want that an advanced adversary
that can somehow sign certiﬁcates with a
valid CA can read my trafﬁc.
• Solution: Certiﬁcate Pinning.
CERTIFICATE PINNING TL;DR
• Stronger protection, you don’t rely anymore on what is signed by CA, instead you can
verify your certiﬁcate against a “known good” set.
• You are in control and you can choose to trust exactly only a certiﬁcate: yours.
M2 - INSECURE DATA STORAGE
• You should encrypt your sensitive data at rest or not save them at all.
• On iOS the private application folder is protected by the sandbox, but
the device can be lost or jailbroken and those data retrieved.
• Other forms of leaks of this informations can be backups and similars.
• Regular users often reuse the same passwords for everything, so it’s
enough a leak from an application to compromise lot of them.
CORRECTLY USE THE SYSTEM FILES AND
KEYCHAIN PROTECTION LEVELS
• A detailed explanation would require a big chunk of this presentation, if
interested you can learn more in this excellent Apple document: http://
• TL;DR: You can set on Files and Keychain Items a “protection level”, which
determine when something is available in a decrypted form (for example: -
always, -after the ﬁrst login on the device, -or only after the device unlock,
so they are encrypted when it’s locked).
EVALUATE ADDING ANOTHER
• You can also apply another layer of
encryption to your sqlite databases or
core data, deriving the encryption key
from a user passcode.
• Sqlcipher is a encrypted sqlite, easy to
• Keep an eye on iMas project which
offers lot of libraries and components
to help you with the development of
M6 - BROKEN CRYPTOGRAPHY
• Don’t implement your cryptography,
use standardised and tested crypto
libraries developed by experts.
• Don’t use static keys, generate
encryption keys from user input
(passcode or password) with a good
level password derivation function and
don’t persist them.
• Don’t embed static keys in the code
In the demo later
M4 - UNINTENDED DATA LEAKAGE
• There are some side channels attacks
typical to the iOS platform.
• Be careful with caches, keyboard logs,
NSLog, snapshots, screenshots, cut
EXAMPLE: PAY ATTENTION ALSO TO
• iOS feature to take snapshots when the app goes in
• They can leak sensitive data like login screens, or your
• You can grab them from the application private folder in
your Library/Caches/Snapshots folder.
• Use the callbacks like willEnterBackground: to sanitise the
screenshot if sensitive data are shown.
OMG it's my bank!
M7 - CLIENT SIDE INJECTION
• iOS is slowly opening to IPC and interoperability between apps, especially in iOS
8. This exposes another attack surface, the Inter Process Communication one.
• Custom URL Schemes: be careful with the untrusted data coming from
• iBeacons: the identiﬁers of iBeacons can be falsiﬁed, be careful if iBeacons trigger
actions in your app.
• In iOS 8 you can create extensions. A whole new attack surface, but luckily there
is maybe some useful expertise from Android which is adopting this from the
M10 - LACK OF BINARY PROTECTIONS
• The defaults in new projects are good
• Be sure checking that you are
generating PIE code and using ARC.
• Position Independent Code makes
harder for an attacker exploiting
vulnerabilities to reliably ﬁnd pieces of
code or informations at a known
address (the application is loaded
differently in memory at each launch)
• Enable stack smashing protection
adding -fstack-protector-all in “Other C
• ARC not only greatly improve the
development experience, it also simplify
the memory management, mitigating
potential vulnerability related to this
problems (use after free for example)
• Don’t embed secrets in the code.
CODE REVERSE ENGINEERING: TOOLS
• A jailbroken iDevice
• Hopper Disassembler or IDA Pro
• cycript (a tool to manipulate iOS apps
and system at runtime)
CODE REVERSE ENGINEERING
• An attacker can reverse third party
applications, even from Appstore by
decrypting them at runtime, with publicly
available tools like “Clutch”, or manually with a
• Run the binary through class-dump to
retrieve the Objective-C class headers
• It can be done also on Swift apps, the names
are less explicit, but they can be deobfuscated
• Good starting point usually
Without sources you can start reversing and understanding the application
with a disassembler and eventually a decompiler
SWIFT REVERSING: JUST THE START
• Swift is a new language, so are the tools and techniques to reverse it
• It does not have metadata as pretty as Objective-c, but it has a lot of
them. Class names must be “demangled”.
• Do you really think this can stop a experienced reverse engineer that
eats stripped, statically compiled binaries for breakfast? :)
• You can experiment yourself with the WWDC
app, it’s in the store and it has parts developed
with Swift inside.
• See this very interesting talk by saurik : https://
• mangled swift class name example:
• Keep an eye on the community in the next
months for more resources on Swift Reversing
CODE REVERSE ENGINEERING
• As you saw, Objective C and Swift leak more
informations about classes and user methods
• If you have important intellectual property to
protect, you may want to code it in C instead of
Objective-C or Swift, the compiler will optimize
it and strip of informations that instead remains
in Objective-C and Swift Code. And maybe
apply an obfuscator on critical parts.
Keep Any Eye On: https://github.com/obfuscator-llvm/obfuscator/wiki
EXAMPLE AND MANIPULATING THE
PIN BYPASS, CLEANING THE
DECOMPILATION A LITTLE
• Simple logic to check if the pin is correct.
• Take the pin and calculate the md5, and check it
against a stored md5 of the right pin
• if correct it dismiss the ViewController, granting
access to the app.
• 1. we can make the view controller dismiss even if we don’t have a valid pin
• 2. we can retrieve the valid pin md5, then crack it trivially, there is no salt and
the pin is only 4 digits (we will do this, just to cover also this easy to crack pin
2 obvious approach that we can take:
~12 PYTHON LOC
WHAT ABOUT TOUCH-ID?
• The Local Authentication Framework
was introduced recently.
• Our app can be notiﬁed if the user
successfully authenticate itself
successfully with biometrics thanks to
• It would be cool to use it right?
CAN YOU SPOT THE PROBLEM HERE?
NOTHING IS WRONG IN THE CODE
• The biggest problem is that the entire
authentication is performed by code running
on the device, so after a jailbreak it’s possible
for an attacker to inﬂuence it, and bypass
our authentication, making the code behave
like the authentication is successful.
• So this feature must be used carefully and
it’s NOT a silver bullet for authentication in
• Apple as well require the passcode at least
once (so something that the user knows)!
KEYCHAIN ACL AND TOUCHID
• You can store secrets in the keychain and provide them back only if
the user authenticate with the touched.
• See Session 711 of WWDC 2014
SECURE MOBILE DEVELOPMENT BEST PRACTICES
Especially the “LEARN” section, very
complete set of tutorial on how to
pentest an iOS app.
Community Edition now available for Free!
SECURITY IS A PROCESS.
WANT TO HELP WITH A IOS PROJECT?
Reverse stuff on your jailbroken iDevice
(maybe one day also on non JB devices)
“Using no way as way, having no limitation as limitation.”