Mobile application Pentesting Lab
Table des matières
DIVA: Damn Insecure & Vulnerable App ................................................................................................. 1
Preparation .......................................................................................................................................... 1
Insecure Logging .................................................................................................................................. 2
Hardcoding Issues................................................................................................................................ 4
Insecure Data Storage ......................................................................................................................... 5
Database Insecure Storage .................................................................................................................. 7
Temporary Files Insecure Storage ....................................................................................................... 8
External Insecure Data Storage ........................................................................................................... 9
SQL Injection in Android .................................................................................................................... 10
Abusing Web View in Android ........................................................................................................... 12
Access Control Issues ........................................................................................................................ 13
Authentication Based Access Control Issues ..................................................................................... 14
Leaking Content Provider .................................................................................................................. 18
Hardcoding Issues Using JNI .............................................................................................................. 20
DOS Attack in Android ....................................................................................................................... 22
DIVA: Damn Insecure & Vulnerable App
In this Lab, we will look at the DIVA Android app developed by Github user payatu. It was designed to
assist developers and security enthusiasts in learning more about Android vulnerabilities by evaluating
a deliberately vulnerable Android application.
Preparation
As in the Lab of Reverse engineering:
1) In order to decompile diva-beta.apk using JaDX, copy the archive .apk to /usr/share/jadx/bin
2) Decompile the apk archive into a folder named diva using the command: ( sudo ./jadx –d diva
diva-beta.apk) it is normal to see some errors, so ignore that errors
Prof. Ahmed EL-YAHYAOUI
3) dex2jar: convert the classes.dex into a jar file using the command below (sudo d2j-dex2jar
classes.dex)
You will get a jar file named classes-dex2jar.jar (you may need to install dex2jar: sudo apt install
dex2jar)
Move the directory diva to your Desktop and continue this Lab
Insecure Logging
Android Applications may store some data as logs
Logs are stored in a central place and every Android application can access those logs
But in latest Android versions permissions for accessing that logs are changed.
Open your Kali Linux shell and go to: Desktop/diva/resources (cd Desktop/diva/resources)
Open the jar file classes_dex2jar.jar, already created in step (Analyzing Dex Files of the
Lab_ReverseEngineering), with jd-gui
Go to jakhar.aseem.divaLogActivity, this is the activity which is responsible for storing our data
as logs
Prof. Ahmed EL-YAHYAOUI
Analyse the source code of the checkout() method?-->it is adding user’s entered information in logs.
open the DIVA application in your emulator and click on “Insecure logging”
find out the process ID of this application (adb shell ps | grep “diva”)
In my case PID=2420
Prof. Ahmed EL-YAHYAOUI
we will analyse the logs of this application (adb logcat | grep 2420)
Go back to DIVA and type a number then click “ckeck out” then verify in the logcat in Kali
What do you see? the credit card number is stored in clear as log
Hardcoding Issues
Sometimes developers made mistake in source code of an Android application
They explicitly define a constant value
If any confidential data is hardcoded in source code, then that is also a security issue
Attackers can decompile the application and see the hardcoded sensitive information
Hardcoded data might be –password, access token, authentication string etc.
go to DIVA application and open “Hardcoding Issues-Part 1”
Enter a value and click OK
Prof. Ahmed EL-YAHYAOUI
What do you see? An access denied message
Now go to jd-gui in Kali and open the code source HardCodeActivity.class
analyse the code source of the access() method, what do you think?
The access method compares the input value with “vendorsecretkey” and grant access if are equal
now try to use “vendorsecretkey” to access the application, what do you get?
Insecure Data Storage
Sometimes Android developers store sensitive information without encryption
Application might store data in shared preferences
/data/data/[package name]/shared_preferences
Databases
Temporary files
External storage
Prof. Ahmed EL-YAHYAOUI
Go to DIVA and open “Insecure Data Storage- Part 1”
Enter a username and a password, then click “Save”
Now go to jd-gui in Kali and open the activity InsecureDataStorage1Activity
Analyse its code, what do you think? user and password are stored in Shared Preferences
in adb shell, change directory to: /data/data/jakhar.aseem.diva/shared_prefs, then list its content
what do you find? An xml file jakhar.aseem.diva_preferences.xml
cat the content of this file, what do you deduce?
Prof. Ahmed EL-YAHYAOUI
We have obtained our saved credentials in clear! This is a security issue; the DIVA application don’t
store sensitive data into an encrypted form!
Database Insecure Storage
Go to DIVA and open “Insecure Data Storage- Part 2”
Enter a username and a password, then click “Save”
Now go to jd-gui in Kali and open the activity InsecureDataStorage2Activity
Prof. Ahmed EL-YAHYAOUI
Analyse its code, what do you think? an SQLite DB instance is created named “ids2”, in this
instance a table named “myuser” is used to insert user credentials
in adb shell, change directory to: /data/data/jakhar.aseem.diva/databases and list its content
What do you see? our database instance “ids2”
try to connect to “ids2” using the command (sqlite3 ids2)
list the tables existing in this database using the command (.tables)
type the command: (select * from myuser;), what do you get? Username and password in clear
Temporary Files Insecure Storage
Go to DIVA and open “Insecure Data Storage- Part 3”
Enter a username and a password, then click “Save”
Prof. Ahmed EL-YAHYAOUI
Now go to jd-gui in Kali and open the activity InsecureDataStorage3Activity
Analyse its code, what do you think? a temporary file named “uinfo” is used to store our data
in adb shell, change directory to: /data/data/jakhar.aseem.diva and list its content; what do you
see? A temporary file
show the content of this file using the cat command, what do you see?
We have found our credentials in clear
External Insecure Data Storage
Go to DIVA and open “Insecure Data Storage- Part 4”
Enter a username and a password, then click “Save”
Prof. Ahmed EL-YAHYAOUI
Now go to jd-gui in Kali and open the activity InsecureDataStorage4Activity
Analyse its code, what do you think? there is a method called saveCredentials() which use the
method getExternalStorageDirectory() method to store credentials, in this method a hidden file
called .uinfo.txt is created
in adb shell, change directory to: /mnt/sdcard and list its content using the command (ls –a); what
do you see? We see our file .uinfo.txt
show the content of this file using the cat command, what do you see?
We have found our credentials in clear
SQL Injection in Android
Input validation issues occurs where application does not sanitize user input
Results in client side as well as server side attacks
E.g.- SQL Injection
Prof. Ahmed EL-YAHYAOUI
Some SQL Injection Payload
1’ or’1’=’1
admin’ or’1’=’1’
admin’ or’1’=’1’-
admin’ or’1’=’1’#
admin’ or’1’=’1’/*
admin’ or 1=1 or ‘’=’
admin’ or 1=1
admin’ or 1=1-
admin’ or 1=1#
admin’ or 1=1/*
admin’) or (‘1’=’1
Now go to jd-gui in Kali and open the activity SQLInjectionActivity and analyse its code
Go to DIVA and open “Input Validation Issues – Part 1”
Enter a username to search, then click “Search”, in this step you can inject your query as below
Prof. Ahmed EL-YAHYAOUI
So we have displayed all user data without knowing any user name before
Abusing Web View in Android
A WebView is an embeddable browser that a native application can use to display web content.
Protocols supported by browsers
http
https
ftp
smtp
file: throw which we can access internal system file, we will use this protocol to access
internal system files
Go to DIVA and open “Input Validation Issues – Part 2”
Enter a URL and see what it gives
in adb shell, change directory to: /mnt/sdcard and list its content using the command (ls –a); what
do you see? We see our file .uinfo.txt
Now we will enter the file system, type in the view the URL: file://mnt/sdcard/.uinfo.txt
Prof. Ahmed EL-YAHYAOUI
What do deduce? we are able to enter this file system and show its content
Access Control Issues
Access control issues arise when application does not authenticate user.
Authorization check is missing
Attacker with un-sufficient privilege can see the protected resource.
Go to DIVA and open “Access control issues- Part 1”, then click “View API credentials”
we will try to access these secret API credentials without passing from these steps
Our objective is to open that API credentials without opening the DIVA Application
At first we will analyse the source code of DIVA
In Kali Linux, Change directory to /Desktop/diva/resources and list its content:
Read the content of the file AndroidManifest.xml ( vim AndroidManifest.xml)
what do you deduce when analysing its content? There is one Activity called
AccessControlActivity which is responsible for the first view in “Access control issues- Part 1” and
contains the “View API credentials” button. If we click this button, another activity named
APICredsActivity will be called by using an intent filter named
“jakhar.aseem.diva.action.VIEW_CREDS”, this intent filter is responsible for invoking that activity
which contains our secret keys
we will use this intent filter to invoke our activity containing credentials
we will do this, from Kali, by the help of activity manager which allow to open any activity running
intent filter with the help of ADB.
Prof. Ahmed EL-YAHYAOUI
Close DIVA application in the emulator
Open adb shell, and the command: am what do you see? Activity manager
To open an activity in Activity Manager we have to use this command:
(am start –a jakhar.aseem.diva.action.VIEW_CREDS)
Go to your emulator, you will find the activity “APICredsActivity “ is opened containing secret
credentials
we can also invoke that activity without opening adb shell:
Authentication Based Access Control Issues
As described in the objective part of this Lab, the application “Access Control Issues- Part 2” has a
mechanism of access control to allow access to some credentials
If we select “Register now” we should register online and to obtain a valid PIN which we could use
to get access to TVEETER API Credentials
we can see those credentials by selecting “Already registred”
Prof. Ahmed EL-YAHYAOUI
now we will break this mechanism of authentication to get access to credentials
we will do this, from Kali, by the help of activity manager which allow to open any activity running
intent filter with the help of ADB.
Read the content of the file AndroidManifest.xml ( vim AndroidManifest.xml)
what do you deduce when analysing its content? There is one Activity called
AccessControl2Activity which is responsible for the first view in “Access control issues- Part 2” and
contains the two radio button and the “VIEW TVEETER API CREDENTIALS” button. If we select
“Register now” and click this button, another activity named APICreds2Activity will be called by using
an intent filter named “jakhar.aseem.diva.action.VIEW_CREDS2”, this intent filter is responsible for
invoking that activity which contains our secret keys
Try to get access to credentials by using the same steps as before, what do you deduce? if we try
the same method as in the previous step, we will be unable to get access to credentials because it is
protected by an authentication mechanism
In order to bypass this access control issue, lets analyse the source code
Prof. Ahmed EL-YAHYAOUI
change directory to /Desktop/diva/sources/jakhar/aseem/diva and list its content
Let’s have a look at the following piece of code from APICreds2Activity.java
https://github.com/payatu/diva-
android/blob/master/app/src/main/java/jakhar/aseem/diva/APICreds2Activity.java
Looking at the above piece of code, it can be seen that there is an extra boolean type argument
required along with the ADB command we used to launch the intent.
First the string “chk_pin” is resolved using the following line.
boolean bcheck = i.getBooleanExtra(getString(R.string.chk_pin),true);
Let’s check the chk_pin entry from strings.xml to see it’s actual value.
Strings.xml file is available at the following path:
Open the file strings.xml (vim strings.xml)
“chk_pin” is “check_pin”.
Prof. Ahmed EL-YAHYAOUI
The next line is making a check to see if “check_pin” value is false or not. This condition is to verify
if the user is already registered or not. This can be seen from the following code in
AccessControl2Activity.java
If the user is already registered “check_pin” is set to false, if not it is set to true. When the
“check_pin” button’s value is set to “false”, there are no other checks made by the application at
receiving side.
So, let’s try to pass this additional argument to the intent and see if it works.
–ez is to pass a key value pair of type boolean.
Running the above command shows the following screen.
Challenge cracked!
Prof. Ahmed EL-YAHYAOUI
Leaking Content Provider
Normal Scenario: Application requesting data from database without Content Providers
Content providers:
Content providers are used to store and query data within the application
All content providers have unique URI (Uniform Resource Identifier)
Content://
Leaking Content Providers:
If our application wants some data from database, it will send a query to content provider
then this content provider itself sends that query to database
If an attacker requests the same data to that content provider and if the content provider is
not doing authentication check then it will end by sending the same data to the attacker
Application: DIVA “Access Control Issues- Part 3”
Prof. Ahmed EL-YAHYAOUI
Now, let’s access directly to “Diva Private Notes” in step 4 without control access process.
for that reason, we will:
1. Find out the content provider URI
2. Then we will query data from that particular content provider.
so, let’s begin by analysing AndroidManifest.xml file ( vim AndroidManifest.xml)
A look at the AndroidManifest.XML file reveals that there is a content provider registered, and it is
explicitly exported using android_exported=”true”.
Content Providers are represented using the URI that starts with content://. So, we need to find
the URI to access the data.
First navigate to the directory where the Java code is extracted using JaDX
We can find the strings using grep command. The following command recursively searches all
the files for the strings that contain “content://”.
$ grep -lr “content://” *
NotesProvider.java
$
Let’s open up the file and check for the content provider URI (vim NotesProvider.java)
Prof. Ahmed EL-YAHYAOUI
As we can see in the above figure, the following content provider URI is available in this file.
content://jakhar.aseem.diva.provider.notesprovider/notes
As we saw in the AndroidManifest.XML file, this content provider is exported and hence we can
query it without any explicit permission.
Let’s do it using ADB. Run the following command in a terminal.
This should query all the data from the application’s notes database.
Challenge cracked! We can query the data from the application without knowing the PIN.
Hardcoding Issues Using JNI
JNI (Java Native Interface)
Java Native Interface is a programming framework that enable java code running in JVM to
be interact with other libraries.
Other programming languages ie- C, C++ can also interact with java code with JNI.
Application
Click on “12. HARDCODING ISSUES – PART 2” in your DIVA application. The goal of this challenge is
to find out the vendor key and submit it to the application.
Following is the decompiled code that is associated with the activity. (Hardcode2Activity.java)
Looking at the above code at Hardcode2Activity.java, it appears that this activity is creating an
object of DivaJni class when it is loaded. Exploring other files reveal that there is a file called
DivaJni.java as shown below.
Prof. Ahmed EL-YAHYAOUI
From above code, it is clear that a native library called “divajni” is loaded. Libraries will come with the
APK file, and they are usually located within the”lib” directory.
Let’s navigate to /Desktop/diva/resources/lib (diva/ is the unzipped package of our diva-beta.apk)
and show its content:
As we can see in the above excerpt, there are multiple instances of “libdivajni.so” files for various
architectures. Lets pull one of them and run strings command on that to see if we can find anything
interesting. This is shown below.
Prof. Ahmed EL-YAHYAOUI
Looking at the above output, we can notice various strings coming out among which two strings that
are highlighted in the above output caught my attention. After trying both of them in the application,
I ended up finding the right vendor key olsdfgad;lh
We can also find this hardcoded key in the source, which is available at the following link.
https://github.com/payatu/diva-android/blob/master/app/src/main/jni/divajni.c
Following is the hardcoded constant from the source code.
DOS Attack in Android
Click on “13. INPUT VALIDATION ISSUES – PART 3” in your application. The goal is to crash the
application somehow.
Let’s first see how the application is responding when we enter some input. I have entered 4 As in the
input field as shown below.
Prof. Ahmed EL-YAHYAOUI
As you can see, the application has shown an error message.
After entering multiple inputs as such, the application responded with the same error message as
long as the input length is not greater than 20.
The following figure shows that the app is throwing the same error when we enter 20 As.
Prof. Ahmed EL-YAHYAOUI
Now let’s see how the application responds of we enter some large text. This time, I am entering
40 As.
As you can see in the above figure, the application has been crashed.
Let’s see if we can find any information about this crash in “logcat”. Open up a new terminal and
type “adb logcat”
Looking at the above output from logcat, its clear that the crash is due to CPUs attempt to jump to
41414141. Basically A maps to 41 in hex. We have used large number of As in the input we have
supplied, and CPU is trying to jump to this location thus causing an error condition since this location
is something that is unknown.
Prof. Ahmed EL-YAHYAOUI
Now, let’s explore the source code available at the link:
https://github.com/payatu/diva-android/blob/master/app/src/main/jni/divajni.c
After exploring the source code available at the above link, it is clear that the application is processing
user supplied input using strcpy() function.
The buffer size allocated is 20. We can see it from the following figure.
Prof. Ahmed EL-YAHYAOUI
