Mobile Pentesting I
In this post you will see the different vulnerabilities that android devices can face. (OWASP Mobile Top 10)
Mobile Pentesting I
Diva
In this writeup we will see how to exploit different vulnerabilities in android. Here is the apk we use payatu/diva-android: DIVA Android Note that we may see more of this type of writeup later. Diva is an application designed to be insecure:
Insecure Logging
Logging is a way to see the errors or warnings that an app can give. In the first challenge we find that through the logs we can see the credit card number:
If we decompile the apk we see that this confirms what we can see through the adb logcat that the attempts put it in the logs.
Hardcoding Issues - Part 1
According to Wikipedia, hard coding is defined as: “the software development practice of embedding data directly into the source code of a program”. In this challenge we see how the developer left the key in plain text in the code:
Looking at the code we can see the key:
Insecure Data Storage - Part 1
In this challenge we see what happens when data is not securely stored on the device and the attacker knows about it:
If we do a cat to jakhar.aseem.diva_preferences.xml we can see the password in plain text:
//data/data/jakhar.aseem.diva/shared_prefs.
Insecure Data Storage - Part 2
We continue to see insecure ways of storing data:
In the logs we can see where the password is stored:
Here we use DB Browser for SQlite to display the password:
Insecure Data Storage - Part 3
We continue to see insecure ways of storing data:
Here we see that a file is created to save the credentials:
Insecure Data Storage - Part 4
We continue to see insecure ways of storing data:
Here we see that it is stored in plain text:
In this series of ways to store data insecurely we realize that no matter how you do it if the attacker follows the trail he will come up with the credentials.
Input Validation Issues - Part 1
In this challenge we see what happens when you trust the user and do not have a correct validation when entering data into the app:
Here we see a bad validation SQLi:
Input Validation Issues - Part 2
In this part we continue to see what happens when the user is trusted. With file we can see the content of the device:
Here is a proof that it makes use of a browser to visit the URLs:
Access Control Issues - Part 1
Starting from the definition provided by citrix about what access control is: “Access control is a fundamental component of data security that dictates who can access and use information and resources”. Knowing this we will see how we can access app data without interacting with the app.
We will use the [Drozer] utility (https://github.com/FSecureLABS/drozer). First we must do a forwarding so that drozer can connect with the agent that we must install in the device:
adb forward tcp:31415 tcp:31415
If we run this command what we are telling drozer is to run the activity that is related to the vendor’s credentials:
run app.activity.start --component jakhar.aseem.diva jakhar.aseem.diva.APICredsActivity
We have another simpler way to do this which is with adb:
adb shell am start -a jakhar.aseem.diva.action.VIEW_CREDS
- With am we tell you to initiate the activity:
Access Control Issues - Part 2
In challenge it gets a little more complicated, but we are still looking for ways to access. Here the idea is to show us the key without having the pin. What happens here is that if we do the same as the previous challenge it will ask for a pin:
We see that it uses the boolean (true in this case) for the pin:
For this with adb we have an option that allows us to bypass this, we start the activity and with –ez we change it from true to false:
adb shell am start -a jakhar.aseem.diva.action.VIEW_CREDS2 -n jakhar.aseem.diva/.APICreds2Activity --ez check_pin false
Access Control Issues - Part 3
We continue to see ways to access data, in this case private notes that are password protected:
Analyzing the code for a while and reviewing it we realize that it stores the pin in plain text:
/data/data/jakhar.aseem.diva/shared_prefs
Input Validation Issues - Part 3
In this case we see how the bad validation ends up causing the application to stop:
Tools
Recommendation
Follow the controls proposed by ther OWASP Mobile Fundación
Additional Resources
Victor Garcia - Pentesting Aplicaciones Android
