Baby Step toward Android App Penetration Testing

13 min readJan 25, 2022

What is Android

Android is a mobile Operating system based on a modified version of the Linux kernel and other open-source software designed primarily for touch-screen devices. It’s owned by Google and

available as an open-source OS with almost 2 Billion users worldwide and almost generating 35+ Billion dollars per year.

Android app can be divided into four components :

Activity:- An activity is one screen of the android app’s user interface. We can understand the activity as a web page of a website. An app can contain one or more activities.

Any activity goes through a certain life cycle during its life inside the app.

When an app is first started, the main activity is created. The activity goes through 3 states before it’s ready to serve the user -> Created, Started, Resumed.

Services:- A Service is an application component that can perform long-running operations in the background. It does not provide a user interface. Once started, a service might continue running for some time, even after the user switches to another application. Additionally, a component can bind to a service to interact with it and even perform interprocess communication (IPC). For example, a service can handle network transactions, play music, perform file I/O, or interact with a content provider, all from the background. It is dependent on some UI component for getting triggered

Content Providers:- A content provider manages access to a central repository of data. A provider is part of an Android application, which often provides its own UI for working with the data. However, content providers are primarily intended to be used by other applications, which access the provider using a provider-client object. Together, providers and provider clients offer a consistent, standard interface to data that also handles inter-process communication and secure data access.

Broadcast Receivers:- Android apps can send or receive broadcast messages from the Android system and other Android apps, similar to the publish-subscribe design pattern. These broadcasts are sent when an event of interest occurs. For example, the Android system sends broadcasts when various system events occur, such as when the system boots up or the device starts charging. Apps can also send custom broadcasts, for example, to notify other apps of something that they might be interested in (for example, some new data has been downloaded).

Apps can register to receive specific broadcasts. When a broadcast is sent, the system automatically routes broadcasts to apps that have subscribed to receive that particular type of broadcast. Generally speaking, broadcasts can be used as a messaging system across apps and outside of the normal user flow.

WEB vs ANDROID

The vulnerabilities plaguing mobile apps are different from those affecting web apps. For one, mobile apps can collect much more information about the user, such as location, biometric, video, and audio data, than web browsers. In addition, mobile apps are essentially public code. Web apps never release their code publicly, but anyone can download mobile apps from the public app stores and inspect the code using open source tools. This makes finding flaws in mobile apps easier.

Third, the most critical difference between mobile apps and web apps is where the apps run. Mobile app code runs on poorly protected end-user devices, where the users are the admins. They may have lax standards around applying updates or being selective in the apps they choose to download. Web app code, by contrast, runs on the enterprise’s server or cloud, over which the enterprise has complete control, and which resides well-protected behind corporate firewalls. More broadly, this means mobile apps have a larger attack surface than web apps. The bad guys can not only attempt to compromise the app, its data stored and runtime memory, they can also attempt to compromise communications between the app and the enterprise’s back end, and target the data in the app, such as user names, passwords, and anything else stored locally. Such attacks can be far easier on mobile apps than on web apps because the attacker owns the device and can manipulate the environment.

{* Point is we need to think in a different way, we just can’t continue with the methods we use on the web *}

Primarily there are three domains in Android app Security:-

Code Security — Under this we check the client-side code of the app. We check if there are any hard-coded IP addresses, credentials, weak cryptographic libraries, insecure certificates, or any other weak point because of poor coding habits.
Communication Security — Under this we check how the application interacts with the server. Here we check for vulnerability in authentication, authorization, session management, and other dynamic parameters. (this is kinda similar to what we do using Burp Suite on the web)
Platform Interaction — Under this we check how the application interacts with the deceive (hardware), here we check for disclosure of sensitive data like username and password.

Types of apps

Native apps

Such apps are developed for a single mobile operating system exclusively, therefore they are “native” for a particular platform or device. Apps built for systems like iOS, Android, Windows Phone, Symbian, Blackberry can not be used on a platform other than their own. In other words, you won’t be able to use the Android app on the iPhone.

The main advantage of native apps is high performance and ensuring a good user experience as developers use native device UI. Moreover, access to a wide range of APIs that puts no limitation on app usage. Native applications are distinctly accessible from app stores of their kind and have a clear tendency to reach target customers.

Some cons to native apps are higher costs compared to other types of apps — due to the need of creating app duplicates for other platforms, separate support, and maintenance for different types of apps resulting in the bigger product price.

Hybrid apps

They are built using multi-platform web technologies (for example HTML5, CSS, and Javascript). So-called hybrid apps are mainly website applications disguised in a native wrapper. Apps possess the usual pros and cons of both native and web mobile applications.

Hybrid multi-platform apps are fast and relatively easy to develop — a clear advantage. A single code base for all platforms ensures low-cost maintenance and smooth updates. Widely used APIs, like gyroscope, accelerometer, geolocation are available.

On the other hand, hybrid applications lack performance, speed, and overall optimization in comparison to native apps for instance. Also, there are certain design issues due to app's inability to look in the exact same way on two or more platforms.

Web apps

These are software applications that behave in a fashion similar to native applications. Web apps use a browser to run and are usually written in HTML5, JavaScript, or CSS. These apps redirect a user to a URL and offer an “install” option by simply creating a bookmark to their page.

Web applications require a minimum of device memory, as a rule. As all personal databases are saved on a server, users can get access from any device whenever there is an internet connection. That is why the use of web apps with poor connection would result in bad user experience. The drawback is access to not that many APIs for developers, with exception of geolocation and few others.

BASIC TOOLS

MobSf

Mobile Security Framework (MobSF) is an automated, all-in-one mobile application (Android/iOS/Windows) pen-testing, malware analysis, and security assessment framework capable of performing static and dynamic analysis. MobSF supports mobile app binaries (APK, XAPK, IPA & APPX) along with zipped source code and provides REST APIs for seamless integration with your CI/CD or DevSecOps pipeline. The Dynamic Analyzer helps you to perform runtime security assessment and interactive instrumented testing.

The simplest way to use mobsf is using docker(i am in linux system)

Command to install docker:-

sudo apt install docker.io

Command to install mobsf image:-

sudo docker pull opensecurity/mobile-security-framework-mobsf

Command to run mobsf from the image:-

sudo docker run -it — rm -p 8000:8000 opensecurity/mobile-security-framework-mobsf:latest

If the above command do not work try removing -it and -rm

The tool can be accessed by visiting the port given by the terminal.

Upload the apk (here we are using a vulnerable password manager by droser) https://github.com/mwrlabs/drozer/releases/download/2.3.4/sieve.apk

And we will be getting results like :

We can also get some code review in this tool also added malware analysis and many more

OR we can use https://www.immuniweb.com/mobile/ latest and updated it works same as mobsf

BurpSuit for DAST

Now add a port for Listening other than some specific port because 127.0.0.1:8000 is for localhost and response will stay back in the app only.

Here for testing purposes, we will be using insecure bank v2 (a vulnerable application)

https://github.com/dineshshetty/Android-InsecureBankv2

Setting up the emulator (i am using genymotion)

In this device/emulator we need to go to wifi then the advance option there we will get the option of proxy.

We will set the proxy to manual and put the IP and the port we have configured in the burp.

Then we can visit http://burp

In the emulator to download the certificate.

The certificate might be in .der format we need to change it to .cer for installation (currently using android 8)

We have to set the certificate for both VPN and wifi.

After this, all the traffic will send to burp suite proxy listener

Here for testing purposes, we are using insecure bank v2

https://github.com/dineshshetty/Android-InsecureBankv2

This application runs on a python2 server

So we need to satisfy as per python2

Now our app is installed and running

Let’s intercept the request in burp

And try to get the password

Here we can find we have a username and password option

More vulnerabilities are available in the walkthrough folder of the app which we can test on our own.

Android Debug Bridge (adb)

ADB is a versatile command-line tool that lets you communicate with the device.The adb command facilitates a variety of device actions, such as installing and debugging apps, and it provides access to a Unix shell that you can use to run a variety of commands on a device. It is a client-server program that includes three components:

A client, which sends commands. The client runs on your development machine. You can invoke a client from a command-line terminal by issuing an adb command.

A daemon (adbd), which runs commands on a device. The daemon runs as a background process on each device.

A server, which manages communication between the client and the daemon. The server runs as a background process on your development machine.

adb — help will list all the commands available for use

They are:-

global options:

-a listen on all network interfaces, not just localhost

-d use USB device (error if multiple devices connected)

-e use TCP/IP device (error if multiple TCP/IP devices available)

-s SERIAL use device with given serial (overrides $ANDROID_SERIAL)

-t ID use device with given transport id

-H name of adb server host [default=localhost]

-P port of adb server [default=5037]

-L SOCKET listen on given socket for adb server [default=tcp:localhost:5037]

general commands:

devices [-l] list connected devices (-l for long output)

help show this help message

version show version num

networking:

connect HOST[:PORT] connect to a device via TCP/IP [default port=5555]

disconnect [HOST[:PORT]]

disconnect from given TCP/IP device [default port=5555], or all

forward — list list all forward socket connections

forward [ — no-rebind] LOCAL REMOTE

forward socket connection using:

tcp:<port> (<local> may be “tcp:0” to pick any open port)

localabstract:<unix domain socket name>

localreserved:<unix domain socket name>

localfilesystem:<unix domain socket name>

dev:<character device name>

jdwp:<process pid> (remote only)

forward — remove LOCAL remove specific forward socket connection

forward — remove-all remove all forward socket connections

ppp TTY [PARAMETER…] run PPP over USB

reverse — list list all reverse socket connections from device

reverse [ — no-rebind] REMOTE LOCAL

reverse socket connection using:

tcp:<port> (<remote> may be “tcp:0” to pick any open port)

localabstract:<unix domain socket name>

localreserved:<unix domain socket name>

localfilesystem:<unix domain socket name>

reverse — remove REMOTE remove specific reverse socket connection

reverse — remove-all remove all reverse socket connections from device

file transfer:

push [ — sync] LOCAL… REMOTE

copy local files/directories to the device

— sync: only push files that are newer on the host than the device

pull [-a] REMOTE… LOCAL

copy files/dirs from device

-a: preserve file timestamp and mode

sync [system|vendor|oem|data|all]

sync a local build from $ANDROID_PRODUCT_OUT to the device (default all)

-l: list but don’t copy

shell:

shell [-e ESCAPE] [-n] [-Tt] [-x] [COMMAND…]

run remote shell command (interactive shell if no command given)

-e: choose escape character, or “none”; default ‘~’

-n: don’t read from stdin

-T: disable PTY allocation

-t: force PTY allocation

-x: disable remote exit codes and stdout/stderr separation

emu COMMAND run emulator console command

app installation:

install [-lrtsdg] PACKAGE

install-multiple [-lrtsdpg] PACKAGE…

push package(s) to the device and install them

-l: forward lock application

-r: replace existing application

-t: allow test packages

-s: install application on sdcard

-d: allow version code downgrade (debuggable packages only)

-p: partial application install (install-multiple only)

-g: grant all runtime permissions

uninstall [-k] PACKAGE

remove this app package from the device

‘-k’: keep the data and cache directories

backup/restore:

to show usage run “adb shell bu help”

debugging:

bugreport [PATH]

write bugreport to given PATH [default=bugreport.zip];

if PATH is a directory, the bug report is saved in that directory.

devices that don’t support zipped bug reports output to stdout.

jdwp list pids of processes hosting a JDWP transport

logcat show device log (logcat — help for more)

security:

disable-verity disable dm-verity checking on userdebug builds

enable-verity re-enable dm-verity checking on userdebug builds

keygen FILE

generate adb public/private key; private key stored in FILE,

public key stored in FILE.pub (existing files overwritten)

scripting:

wait-for[-TRANSPORT]-STATE

wait for device to be in the given state

State: device, recovery, sideload, or bootloader

Transport: usb, local, or any [default=any]

get-state print offline | bootloader | device

get-serialno print <serial-number>

get-devpath print <device-path>

remount

remount /system, /vendor, and /oem partitions read-write

reboot [bootloader|recovery|sideload|sideload-auto-reboot]

reboot the device; defaults to booting system image but

supports bootloader and recovery too. sideload reboots

into recovery and automatically starts sideload mode,

sideload-auto-reboot is the same but reboots after sideloading.

sideload OTAPACKAGE sideload the given full OTA package

root restart adbd with root permissions

unroot restart adbd without root permissions

usb restart adb server listening on USB

tcpip PORT restart adb server listening on TCP on PORT

internal debugging:

start-server ensure that there is a server running

kill-server kill the server if it is running

reconnect kick connection from host side to force reconnect

reconnect device kick connection from device side to force reconnect

reconnect offline reset offline/unauthorized devices to force reconnect

More information on adb here

Drozer

https://github.com/FSecureLABS/drozer

Drozer helps to provide confidence that Android apps and devices being developed by, or deployed across, your organization do not pose an unacceptable level of risk. By allowing you to interact with the Dalvik VM, other apps’ IPC endpoints, and the underlying OS.

drozer provides tools to help you use and share public exploits for Android. For remote exploits, it can generate shellcode to help you to deploy the drozer Agent as a remote administrator tool, with maximum leverage on the device.

It has two parts

1 The console that runs on the workstation

2 The apk that interact with the vulnerable application