Start assessing the security of your Android application
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.
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
1. Clone the InsecureBank Github repository
```bash
git clone https://github.com/dineshshetty/Android-InsecureBankv2
```
2. Install the InsecureBankv2.apk to your Android phone
```bash
adb install InsecureBankv2.apk
```
3. Start using the application to understand how it is working.
1. Make sure that the AndroLab server is running
2. 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 Backup Vulnerability
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.
```bash
adb backup
```
It stores the backup as a “.ab” file.
You can unzip that kind of file with some tools or a shell command.
1. Tools
My go-to tool is Android Backup Extractor, a free Java tool for Windows, Linux and Mac OS.
```bash
# Usage
java -jar abe.jar [-debug] [-useenv=yourenv] unpack <backup.ab> <backup.tar> [password]
```
Example:
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:
```bash
java.exe -jar abe.jar unpack data.ab data.tar “”
```
2. Commands
If you don’t want to install a new tool, you can use these bash commands to unzip the Android backup.
```bash
dd if=data.ab bs=1 skip=24 | openssl zlib -d | tar -xvf -
```
If you have a problem with zlib, try the following command:
```bash
dd if=data.ab bs=1 skip=24 | python -c “import zlib,sys;sys.stdout.write(zlib.decompress(sys.stdin.read()))” | tar -xvf -
```
Insecure Storage
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.
```bash
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.
Just download the “humpty.sh” and run it with the proper arguments to retrieve all the files from an Android application.
```bash
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 ```find``` and ```grep``` to perform these researches.
These commands work just great when you learned how to properly use it.
```bash
man find
```
```bash
man grep
```
Of course, you should look as well in the files you retrieved from the Android application backup we retrieved just earlier.
Hardcoded secrets
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.
1. Credentials are often stored in variables named “pass”, “passwd” or “password”.
2. Secrets are often stored in variables named “key” or “secret”
3. 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 hard coded secrets.
Let’s do this for “*admin*” we identified above through a simple ```grep``` command.
```bash
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 (“```-i```”).
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.
```bash
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.
Insecure Database
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 :
```bash
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](https://sqlite.org/cli.html).
But, as always, there is a tool to open and read a database in a graphical way.
It is [DB Browser for SQLite](http://sqlitebrowser.org/).
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.
If you look at the “names” table, you can see what is called “User Enumeration”.
I can see the logins of the users that connected to the application.
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.
That’s true.
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?
For instance, if we check the most common password of 2017 (from that list), which is “123456” (pretty common indeed).
It would be cracked instantly through a method called Brute Force.
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|<V8^Rn9%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 Dictionnary attack or Rainbow table attack.
You can test your account on a very well known service called Have I Been Pwned from Troy Hunt
So you must use complex passwords that are unique to any service you’re using.
That could be pretty complex to handle.
1. But Password manager are a good starting point for digital sanity.
1. 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.