A presentation about security of mobile apps by our senior quality assurance engineer Kristaps Felzenbergs. It was presented at TAPOST 2017 software testing conference.
2. ABOUT ME
- Lead Security and Test Automation Engineer at TestDevLab Ltd
- Certified Ethical Hacker
- DSS 2016 Speaker
3. IN THIS
TALK
• Mobile apps in media
• The situation
• How do we test? (from
outside to inside)
• Android apps
• iOS apps
• Conclusions
testdevlab.com
5. testdevlab.com
MOBILE APPS IN MEDIA
PICTURE SLIDE
http://www.zdnet.com/article/this-android-infecting-trojan-malware-uses-your-phone-to-attack-your-router/
http://www.techrepublic.com/article/1-2-million-infected-android-malware-hummer-could-be-biggest-trojan-ever/
6. testdevlab.com
Apple CEO Tim Cook released a statement arguing against the FBI's recent order to hack into
the San Bernardino shooter's iPhone 5c. (Jhaan Elker/The Washington Post)
By Ellen Nakashima February 17, 2016
https://www.washingtonpost.com/world/national-security/us-wants-apple-to-help-unlock-iphone-used-by-san-bernardino-shooter/2016/02/16/69b903ee-d4d9-11e5-9823-02b905009f99_story.html
8. testdevlab.com
STATISTICS
From Trustwave Global Security Report 2017:
• 99.7% of tested apps displayed at least one
vulnerability
• 10% of vulnerabilities Trustwave detected and classified
as high-risk critical
• 67% of breaches targeted payment card data
9. testdevlab.com
WHY THE SITUATION IS BAD?
• Developers are focused on features and not security
• Relying on your custom encryption might not be the best choice
(reinventing the wheel)
• Users are not well educated about security
• Users are easy targets for social engineering attacks
10. ATTACK
GLOALS
Credentials
(To the services that you use)
Personal data
• Name
• Location
• Contacts
Credit card data
Access to your device
(Use your device for botnets
and spamming) testdevlab.com
15. testdevlab.com
ANDROID DEBUG BRIDGE
• A command-line utility
• Can control device over USB
• Copy files back and forth
• Install and uninstall apps
• Run shell commands
• …
16. testdevlab.com
LOGCAT
• A command-line utility
• Dumps:
• a log of system messages
• stack traces when the device throws and error
• messages written in the app with Log class.
18. testdevlab.com
HOW DO I EXTRACT?
Two ways:
1. Extract using ADB
2. Use an app to extract the app
19. STEP 1
DETERMINE THE PACKAGE NAME
Determine the package name of the app, e.g.
“com.example.app”.
testdevlab.com
adb shell pm list packages
20. STEP 2
DETERMINE THE PATH
Get the full path of the APK file for the desired package.
testdevlab.com
adb pm path com.example.app
21. STEP 3
PULL IT FROM DEVICE
Pull the APK file from the Android device to your computer.
testdevlab.com
adb pull /data/app/com.example.app-1a.apk path/to/destination
22. OR
EXTRACT USING
AN APP FROM
GOOGLE PLAY
Might be faster if you
don’t have ADB in your
toolset
testdevlab.com
23. NOW
WHEN YOU HAVE THE APP..
several things can be discovered..
testdevlab.com
25. testdevlab.com
JAR SIGNING ( v1 scheme )
• Does not protect some parts of the APK (such as ZIP
metadata)
• Offers a sizeable attack surface
• Consumes more time and memory while verifying the
signature
26. testdevlab.com
APK SIGNATURE SCHEME V2
( v2 scheme )
• Introduced in Android 7.0 Nougat
• Contents of the entire APK are hashed and signed
• Signature check across the entire file
• Any modification to the APK invalidates the signature
27. HOW
SHOULD
I SIGN?
v1 scheme + v2 scheme = good
• v2 scheme speeds up the
installation process in Android
7.0+
• Older platforms will ignore v2
signatures and will relay on v1
scheme instead testdevlab.com
32. testdevlab.com
• You should know that
APK is actually a valid ZIP archive
• FIRST – UNZIP IT
• NEXT – disassemble or decompile
REVERSE ENGINEERING
33. testdevlab.com
• The code decompiled will be in short form
(i.e., how it’s interpreted by the JVM)
• Might not be readable and won’t contain any comments
• Tools:
• Classy Shark by Google - https://github.com/google/android-classyshark
• Dex2jar - https://github.com/pxb1988/dex2jar
• JD-GUI - http://jd.benow.ca/
TO JAVA
34. testdevlab.com
.dex <------------------> .smali <--------------------- java source code
Smali is the most common human readable format for dex
• Gives a readable code in smali language
• Can be modified and repackaged to APK
• Tools:
• Apktool - https://ibotpeaches.github.io/Apktool/
TO SMALI
39. testdevlab.com
Things to check for:
• Developers code
• Third party libs
• Obfuscation level
OBFUSCATION
the action of making something
obscure, unclear or unintelligible
47. STORAGE
Where to look for things?..
• What data stores are
available for an
application?
• Where secrets should not
be stored?
testdevlab.com
48. testdevlab.com
• By default, files that are created on internal storage are accessible
only to that application
• Android implements this protection, and it’s sufficient for most
applications
USING INTERNAL STORAGE
49. testdevlab.com
• Files created on external storage, such as SD cards, are
globally readable and writable
• External storage can be removed by the user and modified by any
application
USING EXTERNAL STORAGE
this is not a place for sensitive data
59. testdevlab.com
The process of associating a host with their expected X509 certificate or
public key
SSL PINNING
https://drive.google.com
60. testdevlab.com
Focus on:
• Storage and what is stored
• Network and data flowing
RUNTIME ANALYSIS RECAP
Try to look for:
• Advanced
measures like SSL
pinning
61. testdevlab.com
• Evaluate the app before installing ( check permissions )
• Prepare your environment
• Get familiar with ADB
• Use logcat to observe device activity
• Decompile and get into source code, check misconfigurations
• Run the app and check what is stored and transmitted over network
SUMMARY FOR ANDROID
63. testdevlab.com
• iOS strictly enforces application boundaries and sandboxing
• Apps cannot communicate directly
• Written in native ObjectiveC or Swift
A MUCH HARDER NUT TO
CRACK
64. testdevlab.com
• Involves finding an exploit in the kernel allowing to run unsigned code
• Can be tethered, meaning you have to boot it while connected to a laptop
and running the jailbreak code every time you restart
• Untethered, meaning once its jail-broken, it will remain so after reboots
JAIL-BREAKING IS JUST THE
BEGINNING
65. testdevlab.com
IPA is a valid zip file as well
Might contain sensitive data outside the binary in case of poor programming
STATIC ANALYSIS
69. testdevlab.com
• SSH into a jail-broken device
• Find the target application’s install folder and look for the Library/caches
directory
INVESTIGATE CACHES
71. testdevlab.com
• Most of the iOS apps are written in ObjectiveC and link to the ObjectiveC runtime
• ObjectiveC is a superset of C, with macros to make a Smalltalk-like syntax
• Its also a “reflective” language – it can alter itself at runtime
• Harder to reverse, but WAY easier to hook
• “Method Swizzling” is a feature of the ObjectiveC runtime
• Allows to swap method implementations at runtime
• What could possibly go wrong?
RUNTIME ANALYSIS
POSSIBLE?
https://www.owasp.org/images/c/cf/ASDC12-Mobile_Application_Security_Who_how_and_why.pdf
72. testdevlab.com
• Get familiar with contents of IPA archive
• Setup tools and get familiar with debuggers and disassemblers
• Hook into active running process
• Run the app and check what is stored and transmitted over network
SUMMARY FOR iOS
73. testdevlab.com
FINAL
THOUGHTS
• Test the app on a jail-broken or rooted device to see what can be
seen
• Examine app package contents thoroughly
• Get a clear view of what is stored and what is transmitted
Hi!
My name is Kristaps and today I am going to talk about security vulnerabilities in mobile applications and things that you need to know to reveal them.
I am currently employed by TestDevLab Ltd, the quality assurance company and I am working as Lead Security and Test Automation Engineer.
My day-to-day work is related to test and test infrastructure development.
I am Certified Ethical Hacker and Certified Security Analyst.
I am Data Security Solutions 2016 speaker. I gave a speech about Security Risks and Common Mistakes in Mobile Application Development
Besides that I am passionate about security so whenever there is a new product in my hands I am trying to evaluate its functionality in terms of security to see if I can find something interesting there by digging deeper.
So today I am going to present you some ways to dig deeper and look under the hood of mobile applications.
First we will have a short look at reported vulnerabilities for mobile applications in daily news.
Then I am going to talk a bit about statistics of known and reported vulnerabilities
After that I am going to dig into the main part where I will try to cover tips and tricks on how to test Android and iOS mobile applications for security vulnerabilities.
Just please don’t mind if there will be a much more information on android apps compared to iOS as most of the experience that I am carrying is with Android. However, I will try to cover some interesting things that you can do with iOS as well so bear with me.
And finally I will present my final thoughts about vulnerabilities and test strategies for Android and iOS mobile apps.
So let’s get started.
As I mentioned – let’s take a quick look at the current situation and see if we can find some major vulnerabilities reported in daily news.
So after a really quick search it came up with some pretty interesting articles related to Android vulnerabilities.
In the upper picture we see a Trojan which was infecting your Android phone to attack your router. OK. This seems pretty major. It was released on January 2017, so early this year.
The lower picture shows article about Android malware named “Hummer” infecting 1.2 million devices. Was it the biggest Trojan ever? Could be! Release date is June 2016.
What about iOS? Is it save and secured?
Year 2015, San Bernardio shooting.
FBI requested Apple to unlock terrorists iPhone. Of course Apple resisted to do so because if they do – would Apple users still trust them their data?
Anyway, a short time later FBI claimed that they have gained access to the terrorist’s iPhone without Apple’s help.
I don’t know more insights into this and cannot explain how they do it. It just makes me think that nothing is safe and everything can be hacked.
It is just the matter of time and resources that you are willing to spend.
So here are a few statistics which I extracted while reading Trustwave Global Security Report 2017.
Trustwave issues such a report yearly so I consider this a good resource for security vulnerability and threats statistics.
So it seems that almost 100% of their tested applications displayed at least one vulnerability
10% of vulnerabilities that they detected were classified as high-risk meaning that they might harm your personal data
67% of data breaches actually targeted payment card data
Why the situation is as it is?
Mostly because we always think new features first and only then security.
Besides that there might be cases that you want to build something on your own that already exists. - I suggest that your never do that with encryption related things. Do not reinvent the wheel..
of course - if you don’t know exactly what are you doing.
The other thing is that that users are still not well educated about security and they are easy targets for social engineering attacks.
Let’s have a look at attack goals
Top #1 – credentials. Everyone wants your credentials to the services that you use.
Personal data – your name, your location, your daily directions, places you visit, your contacts and relationship.
Credit card data - card number, expiration date and card verification value. That’s all that is needed to use your card in online purchases.
And finally access to your device. Once it’s possible your device can be part of a botnet, spamming networks.
And everything of this can be achieved by installing a single harmful mobile applications which fights it way through the system and infects your phone.
So how do we test applications against security vulnerabilities?
My suggestions is that you move from outside to inside.
Meaning that – first evaluate what can be evaluated even before installing the app. Then proceed with installing, then dig deeper and proceed with next things.
As I mentioned – let’s take a quick look at the current situation and see if we can find some major vulnerabilities reported in daily news.
So first security check that can be performed is to see what kind of permissions are asked for user to accept prior installing the app.
Android 6.0 implements additional security checks where developer needs to explicitly ask for user to accept given permission during the runtime of the application.
Previous versions of Android will ask to accept all the required permissions before the installation of the app.
On the right you can see the app which I always like to show as a bright example where the app asks for every possible permission but it’s just a flashlight and your personal data harvester. Don’t install it.
OK. Before we move further let’s have a look at a couple of tools which you definitely want to use to dig deeper into investigating Android apps.
As I mentioned – let’s take a quick look at the current situation and see if we can find some major vulnerabilities reported in daily news.
ADB – Android debug bridge
I hope that everyone of you know it and you are using it already.
It’s a command line utility,
you can install the apps,
control your android device over USB,
perform file transfers,
run different shell commands and send keyboard inputs.
You can get it by installing Android SDK from Google
Logcat – another command line utility which is built into your Android operating system.
You can access it via adb or once you are connected to your Android shell.
It provides very verbose logging of different kinds of processes running on the Android device.
Some of the important things that you might want to see are stack traces when the device throws and error or when the app crashes and messages that are written in the app code using the Log class.
So the next thing that you want to do when you are familiar with the common android tools like adb and logcat is to extract the actual app from your Android device.
The reason is that it might not be so effective to work with the app on the phone than on your computer.
So let’s have a look into the strategies extracting the app from the phone
Basically two very common ways of doing it
First – extract using command line utility – android debug bridge
Second – use an Android app to extract the Android App
dsdsdsds
dsdsdsds
dsdsdsds
As I mentioned – let’s take a quick look at the current situation and see if we can find some major vulnerabilities reported in daily news.
dsdsdsds
dsdsdsdshttp://jd.benow.ca/
dsdsdsdshttp://jd.benow.ca/
dsdsdsdshttp://jd.benow.ca/
dsdsdsds
dsdsdsdshttp://jd.benow.ca/
dsdsdsdshttp://jd.benow.ca/
dsdsdsdshttp://jd.benow.ca/ the action of making something obscure, unclear, or unintelligible
dsdsdsdshttp://jd.benow.ca/
dsdsdsdshttp://jd.benow.ca/
dsdsdsdshttp://jd.benow.ca/ the action of making something obscure, unclear, or unintelligible
dsdsdsdshttp://jd.benow.ca/
now let’s move to the part where you are actually running the app
dsdsdsdshttp://jd.benow.ca/
dsdsdsdshttp://jd.benow.ca/ the action of making something obscure, unclear, or unintelligible
dsdsdsdshttp://jd.benow.ca/ the action of making something obscure, unclear, or unintelligible
dsdsdsdshttp://jd.benow.ca/
dsdsdsdshttp://jd.benow.ca/
dsdsdsdshttp://jd.benow.ca/
dsdsdsdshttp://jd.benow.ca/
dsdsdsdshttp://jd.benow.ca/
dsdsdsdshttp://jd.benow.ca/
dsdsdsdshttp://jd.benow.ca/ the action of making something obscure, unclear, or unintelligible
dsdsdsdshttp://jd.benow.ca/ the action of making something obscure, unclear, or unintelligible
dsdsdsdshttp://jd.benow.ca/
dsdsdsdshttp://jd.benow.ca/
dsdsdsdshttp://jd.benow.ca/
dsdsdsdshttp://jd.benow.ca/
dsdsdsdshttp://jd.benow.ca/
dsdsdsdshttp://jd.benow.ca/
As I mentioned – let’s take a quick look at the current situation and see if we can find some major vulnerabilities reported in daily news.