Watch a live presentation at http://offer.bitbar.com/how-to-test-security-and-vulnerability-of-your-android-and-ios-apps
Majority of today’s mobile apps consist of third-party code/libraries. This is a prudent and well-accepted development practice that offloads the task of developing code for non-core functions of your mobile app – or game. Identifying third-party code, its vulnerabilities and its license restrictions, is highly critical in order to understand your security exposure and your liability.
Stay tuned and join our upcoming webinars at http://bitbar.com/testing/webinars/
Enhancing User Experience - Exploring the Latest Features of Tallyman Axis Lo...
How to Test Security and Vulnerability of Your Android and iOS Apps
1. How to Test Security and
Vulnerability of Your
Android and iOS Apps
4 December 2013
Ville-Veikko Helppi
Antti Häyrynen
Technical Product Manager
Security Specialist
ville-veikko.helppi@bitbar.com
antti.hayrynen@codenomicon.com
18. Mobile software
•Software development is increasingly
shifting into mobile
•Android and iOS dominant
platforms, followed by WP and Qt
–All different, even on preferred programming
language level
•Volumes larger than traditionally, average
revenue per user much lower
19. Mobile software paradigm
•Traditionally software opens files and
handles them.
–Only Android supports this properly via
registering as content handler
•The modern way is to have client / server
architecture
–Mobile device is a client. Payload is usually
json, protobuf, xml or media.
20. Traditional Threats
•Open malicious file / content (via
email, web etc) that contains an exploit ->
target popped.
•In Android, content handlers can have
these issues.
–Platform somewhat limits what the attacker
can do unless privilege escalation is possible.
–For example PDF readers, video players etc.
21. Modern threats
•In the modern app paradigm, the mobile
client “enriches” content from pre-defined
server
–Usually SSL protected
–Certificate checks?
•Cert pinning?
•Attacks somewhat limited to either
–Man in the middle
–Injecting malice via server
22. IOS apps
•IOS apps are Mach binaries usually written
in Objective-C
•Packaging follows the common paradigm –
manifest, code and resources inside zip
•Inside the device executable code is usually
encrypted, but in clear before blessed by
Apple.
–Can be decrypted on jailbroken devices.
•Allows mixing of C into apps -> common
OSS libs can be used.
23. Anatomy of an Android app
•The simplest form: simple java application.
–Manifest, .dex, resource files
•Manifest has meta data (app name,
permissions, content handler registrations
etc)
•DEX contains java byte code
–With or without proguard obfuscation.
•Resource files contain images etc.
•Optionally native code (usually just ARM) in
lib/
24. Native code
•Sometimes java is not enough.
–~15% of android apps contain native code
•.so’s in lib/
–Among popular apps, the amount is much
higher
•If the native code processes untrusted data,
it’s out of dalvik supervision.
–Can corrupt memory and contain exploitable
bugs.
25. Third party code
•Modern world contains plenty of ready
components either as open source or licensable.
•People use them to
–Avoid re-inventing the wheel
–Save time and costs
–Create better software – many of those components
are actually great at what they do.
•Apps that use them inherit the bugs they have.
•Since there’s no “package management” in
Android like in Linux distros, apps bundle third
party code with them.
–Fixing 3rd party bugs require actions from app vendor
26. Third party code in Android apps
•There are different types of 3rd party libs
popular in Android, for example
–Ad networks
–Protocol clients
–Content decoders/encoders
–Shiny UI widgets
–Cross-platform app frameworks
–Most of the Java 3rd party libs usable in
Android
•Either Java or native
27. Introducing Appcheck
•Codenomicon Appcheck makes it easy and
fast to increase your application security
•Integrated into Testdroid
•Works on binaries, no source code
necessary.
•Main idea is to look for third party code from
apps and categorize them.
28. Vulnerabilities
•Third party libraries may contain vulnerabilities that
endanger application security
•Common pitfalls in android libraries include for
example missing certificate checks, missing
crypto, privacy issues
•In native libraries common native code problems
persist.
•Vulnerability feeds provide vulnerability information
on common components
–http://nvd.nist.gov/
–Appcheck performs matching against vulnerability feeds
29. Ad networks
•Ad networks vary from benign to outright
evil
–Some replace dial tone
–Some have critical vulnerabilities
–Some may send more information than user is
willing to accept
•Appcheck detects all the common ad
networks.
30. Licenses
•Third party code sometimes comes with some
strings attached in form of licenses
–Eg. GPL requires you to distribute source code of
derivative works
–Apache license requires some attribution
–GPLv3 forbids DRM
•Common pitfall in Android would be to bundle for
example LGPL lib in on .so with rest of the native
code
•Appcheck makes all the used licenses visible
31. Improving security
•By being aware of security issues of
reusable third party components in their
apps, developers can take action to fix
issues
•If you source software, you can use
Appcheck to check what supplier has
actually bundled inside the app.
32. Conclusions
•Mobile applications face threats and risks
stemming from bundled 3rd party code.
•Third party code scanning gives you
actionable results to
–Remove or mitigate known vulnerabilities
–Eliminate license risk
–Remove overlapping and unwanted
functionality such as privacy leaks