Let's consider that you read the previous posts about Android Security and that you have already a debuggable app ready and installed on your android phone.
And that, following what was described, you had a look at the OWASP and you understand the most "classic" flaws that occur in a software.
First of all, it is important to understand that all of these flaws could be very easily prevented using a proper reviewing process and making the software developers aware of it and explain them what are secure coding practice.
Moreover, it is very important that everyone in the process of making a software service is aware of it, understand the assets of secure coding (in terms of money saved) and allow the developers to take more time to develop a feature. But it will be very beneficial for the future.
This video is a very good example of taking the time to do things correctly and sustainably for the future.
and Security as a part of the process of creating a software is a part of it.
Let's focus on the security assessment of an Android app that is on the Play Store (event if your security must be a part of your software creation process) and especially on all the OWASP Mobile Top 10 static flaws, like insecure logging, insecure storage, reverse engineering or insufficient cryptography.
To explain this, I will use a on-purpose-vulnerable android application called InsecureBank.
Vulnerable Android application for developers and security enthusiasts to learn about Android insecurities
This is a major update to one of my previous projects - "InsecureBank". This vulnerable Android application is named "InsecureBankv2" and is made for security enthusiasts and developers to learn the Android insecurities by testing this vulnerable application. Its back-end server component is written in python. It is compatible with Python2. The client component i.e. the Android InsecureBank.apk can be downloaded along with the source. The list of vulnerabilities that are currently included in this release are:
- Flawed Broadcast Receivers
- Intent Sniffing and Injection
- Weak Authorization mechanism
- Local Encryption issues
- Vulnerable Activity Components
- Root Detection and Bypass
- Emulator Detection and Bypass
- Insecure Content Provider access
- Insecure Webview implementation
- Weak Cryptography implementation
- Application Patching
- Sensitive Information in Memory
- Insecure Logging mechanism
- Android Pasteboard vulnerability
- Application Debuggable
- Android keyboard cache issues
- Android Backup vulnerability
- Runtime Manipulation
- Insecure SDCard storage
- Insecure HTTP connections
- Parameter Manipulation
- Hardcoded secrets
- Username Enumeration issue
If you want to go further on security testing on other apps, you can have a look at that Github repository where a lot of Android on-purpose-vulnerable android applications on that
This is a curated list of mobile based CTFs, write-ups and vulnerable apps. Most of them are android based due to the popularity of the platform.
This is a curated list of mobile based CTFs, write-ups and vulnerable mobile apps. Most of them are android based due to the popularity of the platform.
Mobile CTF challenges
- Mobile challenges collection
- THC CTF 2018 - Reverse - Android serial
- Mobile CTF Challenges: Challenge 1, Challenge 2, Challenge 3, Challenge 4 ZIP password is CTF.
- Android crack me challenges
- OWASP crack me
- Rednaga Challenges
- iOS CTF
- Android Hacking Event 2017: AES-Decrypt
- Android Hacking Event 2017: Token-Generator
- Android Hacking Event 2017: Flag-Validator
- Android Hacking Event 2017: You Can Hide – But You Cannot Run
- Android Hacking Event 2017: Why Should I Pay?
- Android Hacking Event 2017: Esoteric
- Android Hacking Event 2016: StrangeCalculator
- Android Hacking Event 2016: ReverseMe
- Android Hacking Event 2016: ABunchOfNative
- Android Hacking Event 2016: DynChallenge
- PicoCTF-2014: Pickle Jar…
- Clone the InsecureBank Github repository :
git clone https://github.com/dineshshetty/Android-InsecureBankv2
- Install the InsecureBankv2.apk to your Android phone
adb install InsecureBankv2.apk
Start using the application to understand how it is working.
- Make sure that the AndroLab server is running
- Use the credentials dinesh/Dinesh@123$ or jack/Jack@123$ and start using the application
Now that you have a quick understanding of what are the application key features and how the application is working, we can focus on testing the static vulnerabilities on the application.
Static vulnerabilities can be easily industrialized and so added to your development process as it is done on the application and doesn't require actions from a user.
I will come back later on how you can industrialized security testing on Android application.
Android application data can be backed up in order to keep it for future use for instance if you are going to reinstall an app and you want to get back your data.
There is a simple adb command to get the data from an app and store it on your computer.
It stores the backup as a ".ab" file.
You can unzip that kind of file with some tools or a shell command.
My go-to tool is Android Backup Extractor, a free Java tool for Windows, Linux and Mac OS.
# Usage java -jar abe.jar [-debug] [-useenv=yourenv] unpack <backup.ab> <backup.tar> [password]
Let's say, you've got a file "data.ab", which is not password-protected, you're using Windows and want the resulting .tar-Archive to be called "data.tar". Then your command should be:
java.exe -jar abe.jar unpack data.ab data.tar ""
If you don't want to install a new tool, you can use these bash commands to unzip the Android backup.
dd if=data.ab bs=1 skip=24 | openssl zlib -d | tar -xvf -
If you have a problem with zlib, try the following command:
dd if=data.ab bs=1 skip=24 | python -c "import zlib,sys;sys.stdout.write(zlib.decompress(sys.stdin.read()))" | tar -xvf -
When you are using an Android application, developers may want to store some data on the device for persistent storage. That could be your preferences in the app or something that is related to the application. It comes in various ways.
It is very easy to have a look at the application storage as you have installed a debuggable application.
adb shell run-as package-name
Then you can just "cd" through the directory tree and "ls" to see the files and "more" to see the files content.
If something is relevant you will be able to find it.
But it can take quite some time.
So I am using a tool in order to get all the files from an application and then look at them from the comfort of my computer.
This tool is Humpty-Dumpty.
Humpty Dumpty - A file dumper for Android
A simple file dump utility for Android.
Note that this only works for debuggable applications.
humpty.sh [--list-files <package-name>] [--dump <package-name> <db-file>] [--all <package-name>] [...]
For example, to query all files of an application:
$ humpty.sh -l com.pixplicity.example Listing of /data/data/com.pixplicity.example/: /data/data/com.pixplicity.example: cache databases /data/data/com.pixplicity.example/cache: com.android.opengl.shaders_cache /data/data/com.pixplicity.example/databases: example.db example.db-journal
To dump the database
$ humpty.sh -d com.pixplicity.example databases/example.db Dumping com.pixplicity.example/databases/example.db to dumps/com.pixplicity.example/databases/example.db... Success!
To dump all the files of an application:
$ humpty.sh -a com.pixplicity.example Dumping com.pixplicity.example/databases/example.db to dumps/com.pixplicity.example/databases/example.db... Success! ... ...
All database dumps are located in the subdirectory
Licensed under the Apache license.
Just download the "humpty.sh" and run it with the proper arguments to retrieve all the files from an Android application.
humpty.sh -a com.android.insecurebankv2
Now that you have the files the application stored on the device, you have to look for some file names that could have some interesting info in it or for strings in the files.
I am using bash commands to do this. You can extensively use
grep to perform these researches.
These commands work just great when you learned how to properly use it.
Of course, you should look as well in the files you retrieved from the Android application backup we retrieved just earlier.
Earlier, I considered that you already did the setup of the application you want to assess, in order to retrieve the application's source code.
Nevertheless, with InsecureBankv2, you already have the codebase.
Just like what we did during the "Insecure Storage" assessment, we are going to look for specific strings within the codebase that should be interesting.
There are a lot of lists on the internet for security assessment strings. Just pick the one that is relevant to you and automate it with a bash script.
Let's do this for a very specific subset of strings.
- Credentials are often stored in variables named "pass", "passwd" or "password".
- Secrets are often stored in variables named "key" or "secret"
- Admin or development configuration are often stored in variables named "admin", "adm", or "dev".
With all of these values, we have a good starting point to look for some hardcoded secrets.
Let's do this for "admin" we identified above through a simple
grep -i -r "admin" decompiledPackage/
This command is going to look recursively ("
-r") in every file under the "decompiledPackage/" folder if it has the strings "admin" in it, regardless of the casing ("
It is going to be displayed on your terminal stdout and it can become really massive really quickly.
So, a common practice is to put the result in a file.
That is very easy, as bash offers this natively.
grep -i -r "admin" decompiledPackage/ > grep-admin.txt
The result is going to be in a "grep-admin.txt" file.
Did you notice something interesting in your file?
Could you exploit it a little further?
Feel free to tell me in the comment what you found.
Data is very often stored in databases and what is true for a very complex system is true as well for a mobile application.
In the files that you retrieved in the Insecure Storage step, you retrieved some databases. You can identified them through their ".db" extension.
To read an Sqlite database, you can use the terminal.
Let assume that you have a data.db file. To open the database, just type the following command :
sqlite3 data.db sqlite>.help
Then with the help command, you can list the tables, read the data, etc...
You have all the information about the Sqlite3 Command Line Interface on the Sqlite3 website.
But, as always, there is a tool to open and read a database in a graphical way.
It is DB Browser for SQLite.
DB Browser for SQLite is a high quality, visual, open source tool to create, design, and edit database files compatible with SQLite.
Use DB Browser SQLite on the mydb file.
You are now able to see the database's Tables and the values.
But that is not that critical!!! I mean, everyone knows my login, but they don't know my password so it is not that kind of a problem.
If you have what is called a digital sanity about login and password management.
Which is unfortunately very rare currently.
Let's first consider your passwords. Do you think that it is really strong enough?
Check it against that kind of service.
How Secure Is My Password?
It is called the complexity of a password. Your password has to be complex in order to resist a Brute Force attack.
Nevertheless, even if your password is a very complex password.
Like this one for instance : LNA0'F<0]s|<V8Rn9%W,O6|
If a service where you used that password was compromised (let say Yahoo or LinkedIn recently which have massive password leaks), then the password is no more secure.
Because it can be used in what we called a Dictionary attack or Rainbow table attack.
So you must use complex passwords that are unique to any service you're using.
That could be pretty complex to handle.
- But Password manager are a good starting point for digital sanity.
- And U2F Security keys, like the Yubiko, are a good second step for account security.
All of this digression about digital sanity, to let you understand why a disclosed login within a database can be a vulnerability that can be exploited.
Let just get the logins from the database and try to Brute Force them in order to get access to the account.
User Enumeration is a vulnerability and should be avoided.
A quick fix for this vulnerability would be to remove the user enumeration or encrypt it if it is absolutely vital for the service.
And that's it for the static flaws on the InsecureBankv2.
As you can imagine, these are not the only vulnerabilities that can be found on a mobile application.
A lot of vulnerabilities are in fact dynamic. Which means that they are exploitable while you are using the application.
I will cover them in a future article.
Thanks for taking the time to read this.
I hope you are learning new things about security on the Android platform.
It is important to understand what are the most basic vulnerabilities and how easy it is to exploit them in order not to do it.
Give me your feelings about that article in the comments.