A Guide To Mobile Application Pen-testing

First of all note down the IP address of your Android VM. In my case it’s 10.0.2.15

After that connect the attacking VM to the Android VM using adb.
In order to start adb daemon run:
* adb root
Connect the VMs by running:
* adb connect 10.0.2.15:5555

adb tool can be used to install apps directly on the android emulator. To install an app on the Android VM run:
* adb install InsecureBankv2.apk
* adb install diva.apk

In order to perform penetration testing on an android apk we first need to disassemble it in order to view it’s components and source files. This can be done using a tools known as apktool or jadx-gui. The apktool utility help us to read the manifest files as well as look at all the files in the application bundle. The code would be in smali format and there might be some files which are found in plaintext as well. It also contains the class files in .dex format which can be read using jadx-gui utility.
Run:
* apktool d InsecureBankv2.apk
* jadx-gui InsecureBankv2.apk

Attacking Vectors:

• Exported Activities:
  The export tag determines whether or not the activity can be launched by components of other applications. If the export tag is set to true then the activity can be called easily.
  Looking at the manifest.xml file of our apk we can see that the activity PostLogin is exported. It is possible to call this activity directly by running:
  * am start -n com.android.insecurebankv2.apk/.PostLogin
  Thereby bypassing the login screen. **Applications should not export activities unless specifically required.

• Developer Backdoors:
  There are times when developer put a backdoor to a particular application for debugging purposes. If we go through DoLogin then we will find that there is a Backdoor. There is a Username(devadmin) which turns on some Admin Options.
  * Enter the username devadmin and press login, it is discovered that we can login regardless of the password input we gave.

• Bypassing ROOT Detection:
  From the decompiled code , under the class PostLogin we can see that showRootStatus() is performing the root check for the application. Analyzing the code we found that it’s calling two other functions
  * doesSuperuserApkExist(“/system/app/Superuser.apk”)
  or
  * doesSUexist()
  The first function checks for the location of /system/app/Superuser.apk file and based on that it returns True or False.
  The Second function checks whether it can execute sudo command at the location /system/xbin/su and returns True if possible.

We can bypass this checks by mounting the /system partition as read/write:
* mount -o rw,remount /system
and changing the locations of Superuser.apk and su (if present) from their respective locations.

• Exported Broadcast Receivers:
  From the manifest it is found that the following broadcast receiver is exported. Looking into the class MyBroadcastReceiver from the decompiled code, we can see that the onReceive method sends an SMS to the phone number parameter with the new password.
  This can be used to exploit into changing user passwords by running:
  * am broadcast -a theBroadcast -n com.android.insecurev2/com.android.insecurebankv2.MyBroadCastReceiver --es phonenumber 1234 --es newpass avengers

• Android Pasteboard:
  All the data copied using the cut/copy feature in android goes to buffer known as clipboard. The clipboard data can be read by any applications without needing any permission. If the clipboard contains confidential information, it might leads to data leakage.
  In order to read the clipboard data of a specific applications note down it’s ID by running:
  * adb shell ps
  And then run:
  * adb shell su <ID> service call clipboard 2 s16 com.android.insecurebankv2

• Insecure Logging:
  Misconfigurations in code leads to insecure logging of sensitive data. Command adb logcat can be used to analyze the device logs. Once a successful username/password combinations is entered, it can be found in the device logs. **Apps must not log any Personally Identifiable Information (PII) as part of normal operation, unless it’s absolutely necessary to provide the core functionality of the app.

Insecure Data Storage:

All the data of Android apps are stored under the location /data/data. The Android OS creates unique directories for each app. The name of the directory is the same as the package name. No app can access other app’s data. Only the respective app and root user could access the contents in the directory.

• Part 1:
  Shared Preference is a way to store data of an Android app in the form of key, value pair. It stores these values under /data/data/<package_name> directory. The username and passwords are stored in clear texts inside the shared_prefs folder in xml file.

• Part 2:
  On viewing the decompiled code with jadx-gui we can see that it saves the credentials inside ids2 database file. That means if we read the database file in application folder, we can find credentials there.

• Part 3:
  According to the decompiled code under the class InsecureDataStorageActivity, we can see that the function saveCrendentials checks for the external storage permissions and saves the credentials under the .uinfo.txt file.
  If we can access the text file we can easily see the credentials.

Conclusion:

This projects covers the basic Pentesting techniques. It helps clearing a lot of basics involved in mobile applications pentesting. It is a good guide for people who are just starting in this field.

Feel free to add comments and help me improve my posts.