Mobile Application Penetration Testing on

Windows Subsystem for Android

Graduate Students
Flengas Vasileios

Assistant Professor
Stergiopoulos Georgios

July 2022

1
Πίνακας περιεχομένων
1. Methodology.................................................................................................................... 4
1.1 Static Application Security Testing (SAST) ............................................................. 4
1.2 Dynamic Application Security Testing (DAST) ........................................................ 5
2. Setup Rooted Windows Subsystem for Android .......................................................... 8
2.1 Uninstall Existing WSA ............................................................................................. 8
2.2 Download Rooted WSA Release............................................................................... 8
2.3 Enable Developer Mode ............................................................................................ 9
2.4 Enable Virtual Machine Platform .............................................................................. 9
2.5 Install Rooted WSA.................................................................................................. 10
3. Install Android Debug Bridge (ADB) ............................................................................ 10
4. Verify if WSA is Rooted ................................................................................................ 11
5. Pentesting on InsecureBankv2 Application ................................................................ 12
5.1 Configure and Install the Server ............................................................................. 13
5.2 Install InsecureBankv2 App .................................................................................... 13
5.3 Exploit Vulnerabilities ............................................................................................. 15
5.3.1 Exploit Android Activities ................................................................................. 16
5.3.2 Developer Backdoor ......................................................................................... 17
5.3.3 Exploit Android Backup Functionality ............................................................. 17
5.3.4 Insecure WebView Implementation.................................................................. 18
5.3.5 Insecure Login................................................................................................... 19
5.3.6 Exploit Weak Cryptography.............................................................................. 20
5.3.7 Exploit Android Content Provider .................................................................... 22
5.3.8 Exploit Debug Mode .......................................................................................... 22
5.3.9 Insecure HTTP Traffic ....................................................................................... 23
5.3.10 Parameter Manipulation with BurpSuite ........................................................ 25
5.3.11 User Enumeration with BurpSuite ................................................................. 26
5.3.12 Hidden Button for Admin ................................................................................ 28
5.3.13 Bypass Android Root Detection..................................................................... 30
5.3.14 Exploit Android Broadcast Receiver ............................................................. 33
5.3.15 Exploit Android Pasteboard ........................................................................... 33
5.3.16 Exploit Android Keyboard Cache................................................................... 35
6. Pentesting on Android AppSec Application ............................................................... 36
6.1 Install Android AppSec ........................................................................................... 36
6.2 Exploit Vulnerabilities ............................................................................................. 37

2
 6.2.1 Login Bypass with Cookie Manipulation ......................................................... 37
6.2.2 REST API HTTP Methods .................................................................................. 39
6.2.3 Server-Side Request Forgery (SSRF) .............................................................. 41
6.2.4 JSON To XXE ..................................................................................................... 45
6.2.5 JSON Web Token (JWT) Misconfiguration ...................................................... 47
7. References..................................................................................................................... 50

3
1. Methodology

The methodology followed through the penetration testing process was based on static code
analysis and dynamic application security testing.

1.1 Static Application Security Testing (SAST)

Static Application Security Testing, also known as Static Code Analysis, commonly refers to
an attempt to find possible vulnerabilities by examining the code before executing it.
Vulnerabilities can exist to an application due to insecure code, design or configuration. Static
code analysis is mostly implemented during the code review phase of the Secure Software
Development Lifecycle (S-SDLC) process or during a white-box penetration testing.

There are a lot of techniques which can be used to perform static code analysis.

Control Flow Analysis is a technique in which the reviewer checks all the logical conditions
in the code. More specifically, the reviewer identifies various conditions such as loops, if
statements, try/catch blocks, etc. and then figures out under what circumstances these
conditions are executed.

Data Flow Analysis is a technique used to trace data from the points of input to the points of
output. This analysis helps the reviewer to find vulnerabilities associated with poor input
validation and sanitization, especially with data coming from the user which is considered to
be an untrusted source.

Taint Analysis is trying to identify security vulnerabilities that are associated with user input.
Most common examples are SQL Injections or Buffer Overflow attacks. Perl and Rudy are two
example of programming languages which have this feature enabled by default.

Lexical Analysis is a technique which converts the syntax of the source code into a sequence
of tokens and then further analyze them. [1]

One way to perform static code analysis is the manual, which means go through the code line
by line. This way is very time consuming and is hard to perform especially when there are
many lines of code, that's why most of the times are used code scanning tools that can perform
the process automatically. Table 1 presents the advantages and disadvantages of using an
automated static code analysis tool. [3]

Advantages Disadvantages
Faster scan than humans. Unable to find vulnerabilities which are
associated with business logic flaws,
transactions and sensitive data.
Return the exact lines of code that are Only find vulnerabilities which are specified
vulnerable. in the tool’s scope repository.

4
 Able to trace inputs given to the app in Can’t spot design flaws because they are
order to check if they are associated with not part of the code structure that’s been
insecure code patterns. analyzed by the tools.
Create a report that includes risk rating and High number of false positive issues.
description for all the vulnerabilities that
was found.
Table 1

Tools that can perform android static code analysis based on OWASP. They are listed in
alphabetical order. [2]

• AppSweep
• Coverity Static Analysis
• Fortify
• HCL AppScan Source
• Insider CLI
• MobSF
• Oversecured
• Veracode

Based on OWASP the right criteria in order to select a static code analysis tool are the
following: [2]

➢ Support the programming language that you want.

➢ Detects a large number of vulnerabilities based on OWASP Top Ten.
➢ Good rate of false positive and false negative results.
➢ Support all the libraries and frameworks you used.
➢ Requirement for buildable source code.
➢ Be able to scan binaries and not just source code.
➢ Have a plugin extension for your preferrable IDE.
➢ Easy to install and use.
➢ Be able to include in continuous integration and deployment tools.
➢ License cost based on the organization, the app that will be scanned and the lines of
code.
➢ The report must be easy to understand and use.

1.2 Dynamic Application Security Testing (DAST)

Dynamic Application Security Testing is the process of finding vulnerabilities and weaknesses
in an application while it is running. This is possible by injecting malicious payloads as inputs
and then analyzing the response for potential flaws. DAST is usually performed by automatic
tools which scan both the client and the server side looking for vulnerabilities that can be
exploited by an attacker. [5] The main advantages of these tools are the fact that they need
minimal user interaction once they are configured and they are completely independent from
the source code of the app. From the other side, they can't find the exact location of a
vulnerability in the code and sometimes they can be really time consuming. [6]

5
Tools that can perform dynamic code analysis based on OWASP. They are listed in
alphabetical order. [5]

• Acunetix
• Burp Suite
• HCL AppScan on Cloud
• InsightAppSec (AppSpider)
• Netsparker
• Nuclei
• Veracode Dynamic Analysis
• ZED Attack Proxy

The DAST tool that was used in this penetration testing is Burp Suite Community Edition [26]
and the approach followed was based on the vulnerability categories as they are described in
the Open Web Application Security Project (OWASP) Top Ten Security Risks. The OWASP
Top Ten is a list of the most critical web application vulnerabilities which a lot of times used as
a standard for web application vulnerability assessment. [4]

A01 - Broken Access Control

Access control enforces policy by preventing users to perform unintended actions. A failure in
this mechanism may give user access to unauthorized information and even allow them to
modify or destroy data in the system. [7]

A02 - Cryptographic Failures

Cryptography is important in order to protect data when they are transmitted through internet
or when they are stored in a computer. Strong cryptographic algorithms must be used
especially when they must encrypt sensitive information like credit card numbers, passwords,
health records, personal information etc. Avoid using deprecated algorithms and weak
encryption keys is a must to keep the data safe. [8]

A03 – Injection

Injection attacks are possible to perform when user's input is not validated or sanitized by the
application before executing it. Every parameter of the app must be always filtered for escape
characters because dynamic queries can compromise the entire system. [9]

A04 - Insecure Design

Insecure design exists when security controls aren't included in the development lifecycle
phase of the application. Design flaws can lead to information disclosure, or even compromise
the application. [10]

6
A05 - Security Misconfiguration

Security misconfiguration arises when essential security settings are missing from the
application, or they are not implemented correctly. Most common examples are the use of
default username and passwords, system running unnecessary ports and services, accounts
with more privileges that they should, and error messages displayed to users. [11]

A06 - Vulnerable and Outdated Components

Vulnerable and outdated components are referring to libraries, frameworks or any other type
of software which contains vulnerabilities or is not upgraded. Both client-side and server-side
components that are used, must be scanned for potential vulnerabilities, including zero-days,
and always take the latest updates. [12]

A07 - Identification and Authentication Failures

Identification and authentication failures exists when the app is not correctly implements
functions, or they are weak, in order to protect user's identity, authentication and session
management. Most common weaknesses are allowing brute force attacks, use default or well-
known credentials, missing multi-factor authentication mechanism and not properly handling
session IDs. [13]

Α08 - Software and Data Integrity Failures

Software and data integrity failures relate to code and infrastructure that does not protect
against integrity violations. This vulnerability exists when an application is using software
components like libraries and plugins, from untrusted sources. [14]

A09 - Security Logging and Monitoring Failures

Logging and monitoring are two important features in order to detect, escalate and respond
when a breach takes place on the system. A failure in these features will give attacker the
ability to stay undetected and exploit the application more easily. [15]

A10 - Server-Side Request Forgery

SSRF vulnerability exists when a web application is not properly validating user’s URL input
before executing it. As a result, an attacker can send crafted requests to the server in order to
access internal systems or services even when they are protected by a firewall, VPN, or
access control lists. [16]

7
2. Setup Rooted Windows Subsystem for Android

Windows Subsystem for Android (WSA) is a virtual platform which runs under Hyper-V,
created by Microsoft for Windows 11. It gives users the ability to run Android applications on
their laptop or desktop computers alongside with their regular Windows apps. Based on the
official Microsoft’s documentation you can install Android apps only from the Amazon
Appstore, but it’s also possible to install applications through Android Debug Bridge (ADB).
[17]

2.1 Uninstall Existing WSA

As a first step you need to remove any installed version of Windows Subsystem for Android
(WSA) by going over to Start Menu, search for Windows Subsystem, right click on it and
select Uninstall. Once the process is completed, you need to reboot your computer.

2.2 Download Rooted WSA Release

To get a rooted Windows Subsystem for Android you need to download a WSA version which
has GApps and Magisk already installed. GApps are the google applications which come pre-
installed on most Android devices (Play Store, Gmail, Google Maps, etc.) and Magisk is a
rooting software that modify your phone’s system without changing the core code.
MagiskOnWSA is project created by LSPosed which gives you the ability to customize and
download a rooted WSA release with the above apps installed. After following each step from
the GitHub page you will have both an arm64 and an x64 architectures ready for download.
To find the correct one based on your system, go to Start Menu, search for Settings, then on
the System tab go at the end and select About. On Device specifications you will find your
System type.

Figure 1

Once the download is completed make sure to extract the files on your PC.

8
2.3 Enable Developer Mode

Before moving to the installation process you need to enable Developer Mode on Windows
11. First go again to your Settings, on the left column select Privacy & security and then
select For developers. On the next page make sure to enable Developer Mode.

Figure 2

You will get a confirmation popup message. Click Yes to confirm.

2.4 Enable Virtual Machine Platform

Virtual Machine Platform is a requirement feature for Windows Subsystem. In order to enable
it, go to Start Menu, search for Turn Windows features on or off and click on it to open.
Scroll down until you find Virtual Machine Platform, checkmark it and hit the Ok button.

Figure 3

9
2.5 Install Rooted WSA

Since you have downloaded and extracted the rooted WSA from step 2, go to the extracted
folder and you will find a file with the name Install.ps1. The .ps1 extension is referring to a
PowerShell script. To properly install the file, right click on it, select Run with PowerShell,
then click Open and Yes in the next two popup windows in order to start the installation.
After the process is finished you will see the message “All Done Press any key to exit”. Once
you hit any key, Windows Subsystem for Android will start loading including Play Store and
Magisk. [18]

3. Install Android Debug Bridge (ADB)

Android Debug Bridge (ADB) is a command-line tool which gives user the ability to
communicate with a device. ADB is included in the Android SDK Platform-Tools package and
gives client the ability to execute a variety of actions on a device such as install applications,
copy files, view logcat output, get a Unix Shell, create a backup file of an app and set up port
forwarding rules. You can download it for windows from the official link. ADB doesn’t require
installation, it’s a portable app and once you unzip the files you can run it just by opening a
command-line in the extracted folder. [19]

Before you connect the rooted WSA to the ADB you need to enable developer mode from the
WSA Settings. Move to Start Menu, search for Windows Subsystem for Android and click
on it. On the left side click on Developer and enable Developer mode.

Figure 4

Next go to the extracted ADB folder, right click on it, and select Open in Terminal. You can
connect to the device either by typing the localhost address and the port “adb.exe connect
127.0.0.1:58526” or by typing the given IP address without any port “adb.exe connect
172.27.145.249”.

Figure 5

By typing “adb.exe devices” you can check the list of devices.

10
 Figure 6

4. Verify if WSA is Rooted

One way to check if the WSA machine is rooted properly, is by using the adb shell. After
establishing a connection between the adb and the WSA device you can get an interactive
shell by typing “adb.exe shell” in the command-line. By using the “whoami” command which
prints the username of the current user, you can see that you are logged in as “shell”.

Figure 7

Shell is a standard user without many privileges on the system. In order to upgrade to root,
you need first to open Magisk by going to Start Menu and search for it. Then navigate to the
Superuser tab at the bottom of the app and enable “[SharedUID] Shell”.

Figure 8

11
 Figure 9

Then move back to the adb shell and with the use of the su command you can switch the
current user to the root one by typing “su root” or just “su”. Now you have a full privileged
user in the system. [18]

Figure 10

5. Pentesting on InsecureBankv2 Application

InsecureBankv2 is a vulnerable Android application created by Dinesh Shetty, and it was

presented on Black Hat USA 2016. The app was designed for security enthusiasts and
developers to learn and test Android vulnerabilities. You can download the application from
the InsecureBankv2 official GitHub page [20] by selecting the Code button and Download
ZIP.

Figure 11

Once the download is completed, unzip the files at any location in your computer.

12
5.1 Configure and Install the Server

In order to work properly, InsecureBankv2 requires a python server to run locally on our
computer. The files of the server are in the “AndroLabServer” folder that you previously
download from GitHub. To run the server, you need first to install Python2 [21] to your
computer. Once the installation process is finished go to the installed folder. By default, this
folder is at “C:\Python27\”. Right click, press Open in Terminal and run the following
command to download the pip file, “curl https://bootstrap.pypa.io/get-pip.py -o get-pip.py”.

Figure 12

After that, run “python.exe get-pip.py”. Since pip is installed, you can now use it to install the
requirements for the InsecureBankv2 server. Move to your AndroLabServer and run
“C:\Python27\python.exe -m pip install -r requirements.txt”. [20]

You can now run the server by typing “C:\Python27\python.exe app.py”. If everything works
properly you will see a message saying, “The server is hosted on port: 8888”.

Figure 13

In some cases, you may encouter an “ImportError: No module named wsgiserver” as the one
in the following picture.

Figure 14

To solve the problem run the command “C:\Python27\python.exe -m pip install wsgiserver”
and then run again the “app.py” file to start the server.

5.2 Install InsecureBankv2 App

To install the application to your computer you need to copy the “InsecureBankv2.apk” file that
you downloaded from the GitHub repository to your adb folder. Then you need to connect your
device with adb. Once the connection is set run “adb.exe install InsecureBankv2.apk” and
the app will be installed.

Figure 15

13
To start the app, go to Start Menu, search for InsecureBankv2 and click on it.

Figure 16

Before you try to login with the default credentials from the GitHub page you need to configure
the app to listen to the server. Select the three dots on the right corner and then click
Preferences. On the next page, in the Server IP field you can either enter the localhost IP
(127.0.0.1) or your computer’s local IP which can be found by typing “ipconfig” in the command
line.

Figure 17

Figure 18

There are two default accounts on GitHub. The first username is dinesh with password
Dinesh@123$ and the second is jack with password Jack@123$. Use one of them to log into
the app.

14
 Figure 19

If you look at the server, there will be a message that shows the login activity.

Figure 20

5.3 Exploit Vulnerabilities

Every android application must have an AndroidManifest.xml file. The manifest file describes
the components of the app, which permissions are needed, the hardware and software
features that the app requires and a lot of essential information regarding the application.
Being able to read this file is crucial since developers plenty of times make code mistakes
which can lead to exploit the app. To inspect the manifest file and the code from an apk you
can use Bytecode-Viewer [22] which is an Android APK Reverse Engineering tool written in
Java. After download the latest release from GitHub run “java -jar Bytecode-Viewer-
2.11.2.jar” to start the app. Keep in mind to change the “Bytecode-Viewer-2.11.2.jar” to your
latest version and have Java 8 installed on your computer. Once the app is running go to File,
select Add and navigate to the InsecureBankv2.apk folder to select it. After a couple of
seconds, the app will be displayed in the files section. Click on the “>” mark to export the
extracted files and select the “Decoded Resources”.

15
 Figure 21

5.3.1 Exploit Android Activities

Inside the manifest file, you can find the Android activities of an application. An Android activity
is an element that implements part of the app’s graphical user interface. If the activity has an
attribute called android:exported and its value is true, it means that this activity is accessible
to any app by launching its class name. If you check on the manifest file of the InsecureBankv2
there is an activity called “PostLogin” and it has an exported value equals to true.

Figure 22

“PostLogin” is referring to the screen displayed after the user successfully log into the app.
You can call this exported activity to bypass the login mechanism by using adb.
“adb shell am start -n com.android.insecurebankv2/com.android.insecurebankv2.PostLogin”

Figure 23

Once the command is completed you will be successfully login to the application without using
any credentials. Also, in the server there is no activity displayed.

16
5.3.2 Developer Backdoor

Looking at the source code of the app you can find a “DoLogin.class” file, which has a method
called “postData”. This method is sending the login credentials to the server, but as you can
see in the code, if the username is “devadmin” the credentials are sent to a different endpoint
called “/devlogin”.

Figure 24

So, by typing “devadmin” as the username and leave blank the password field you can log into
the app.

Figure 25

Figure 26

5.3.3 Exploit Android Backup Functionality

The application has the android:allowBackup attribute set to true in the manifest file.

Figure 27

17
When this attribute is true you can use adb to create a backup of the app by running “adb
backup com.android.insecurebankv2”. The command will create a “backup.ab” file that
must be unpacked.

Figure 28

To unpack it you can use abe.jar [23] which is a java script that converts backup files to tar.
First copy the “abe.jar” file to the same directory as the “backup.ab” file and then type “java -
jar abe.jar unpack backup.ab insecurebankv2_data.tar”.

Figure 29

In order to unzip the .tar file you can either type the command “tar xvf
insecurebankv2_data.tar” in a Linux terminal or download 7zip [24] for Windows. Once the
file is unzipped, by searching you can have access to files like “mydb”,
“mySharedPreferences.xml”, “preferences.xml” which contain sensitive information about
the users such as usernames, passwords and log history.

5.3.4 Insecure WebView Implementation

Android WebView allows you to load a remote url or display an html page which is stored in
our application. InsecureBankv2 allows users to view their statements after they have made a
transaction. By checking the source code for the “ViewStatements” activity you can find out
that it’s using a WebView to load a html file from an external storage. The file always begins
with “Statement_” and the developer has the “setJavaScriptEnable(true)” which allows the
execution of JavaScript code.

Figure 30

18
You can use logcat to find the storage location of the html file. Logcat is capturing a lot of
traffic, so you need to filter the output with the use of “findstr” if you are using Windows or
“grep” if you are using Linux. The command you need to execute is “adb.exe logcat | findstr
“System.out” “. After running the command, you need to login with the default credentials of
dinesh and push the View Statement button.

Figure 31

The location of the file is “/storage/emulated/0/Statements_dinesh.html”. This is an external

storage which means that everyone can read and write on this file. Since the JavaScript is
enabled, you can perform an XSS attack. First you need to create a new file with the name
“Statements_dinesh.html” and inside add “<script>alert(You Have Been Hacked);</script>”.

Figure 32

Replace the existing file with the new one by typing “adb push Statements_dinesh.html
/storage/emulated/0/”.

Figure 33

Once the file is pushed press again the View Statement button in the app.

Figure 34

5.3.5 Insecure Login

Open the ByteCode Viewer and check the source code of the DoLogin activity.
InsecureBankv2 application uses “Log.d” as its method to produce log messages when a user
attempts to login.

19
 Figure 35

These logs can be dumped by using logcat. To reduce the results, you can filter only for the
message “Successful Login:” by typing “adb logcat | findstr “^Successful Login:”. The
symbol “^” is a regular expression referring to “Line position: beginning of line” which means
that the message you are searching must be in the beginning of the line.

Figure 36

The login credentials are shared between every application on the device.

5.3.6 Exploit Weak Cryptography

In the “LoginActivity.class” file there is a method called “fillData” which is used to save user’s
credentials in a file named “mySharedPreferences”.

Figure 37

To inspect the file, you can get a copy of it by running the command “adb pull
/data/data/com.android.insecurebankv2/shared_prefs/mySharedPreferences.xml”.

Figure 38

From the source code in the “LoginActivity.class” you can see that the password is encrypted
with a method called “aesEncryptedString()” which is called from the “CryptoClass.class” file.
“CryptoClass” is using AES encryption with Cipher Block Chaining (CBC) mode. The problem
is that the initialization vector is static, and the encryption key is hardcoded in the file.

20
 Figure 39

Also, from the “fillData()” method you can see that the developer is using AES CBC to encrypt
only the password, while the username is just saved as base64 encode.
You can use the following python script to decrypt the values from “mySharedPreferences” file
to readable format.

Figure 40

In order to run the script you must first install the the “pycryptodome” package by typing “pip
install pycryptodome”. Once the package is installed you can run the script and get the
credentials.

Figure 41

21
Another way to decrypt the credentials is by using an online tool called CyberChef [25] in which
you must select the decryption method and add the right parameters.

5.3.7 Exploit Android Content Provider

Content providers are mostly used to share app data with other applications. From the
“TrackUserContentProvider.class” you can find the URI of the content provider in the
InsecureBankv2 app.

Figure 42

Since you have the URI you can query this content provider to get the data. First you need to
run “adb shell” and then type “content query –uri
content://com.android.insecurebankv2.TrackUserContentProvider/trackerusers”. As a
result you will get the login history, including the username and the id of each user which are
completely unencrypted.

Figure 43

5.3.8 Exploit Debug Mode

In the Android manifest file you can see that the android:debuggable attribute is set to true
by the developer.

Figure 44

22
When this attribute is enabled, you can access the application’s data by assuming the unique
user id of that app. To perform the attack, start the adb shell and change user to root with the
“su” command. Then type “run-as com.android.insecurebankv2” to get the privileges of the
application.

Figure 45

Since you have access to the application’s data by searching around you can find a file named
“mydb” which is the database of the application.

Figure 46

To get a local copy of the database you can run the following command.
“adb exec-out run-as com.android.insecurebankv2 cat /databases/mydb > mydb-copy”

Figure 47

5.3.9 Insecure HTTP Traffic

InsecureBankv2 is using HTTP protocol when connecting to the server which does not provide
any encryption on the traffic. To intercept the traffic you can use Burp Suite Community Edition
by PortSwigger [26]. The community edition is free and can be downloaded from the official
site. Before you start intercepting you need to configure Burp to listen the connection between
the app and the server. First open Burp, go on the Proxy tab, select Options and on the
Proxy Listeners click Edit to get a popup window. In the Bind to port add the port number
that Burp will listen for connections. For example, you can choose 5555. In the Bind to
address choose Specific address and select the private IP of your computer.

23
 Figure 48

Then move to the Request handling section on the top of the window. From this section you
will configure Burp to redirect the traffic from the app back to the server. In the Redirect to
host field add the private IP of your computer as you did before, and in the Redirect to port
filed add the port 8888 which is the listening port of the server.

Figure 49

Apart from Burp you also need to configure the app to send the traffic in the port 5555. Move
to the app, click on the three dots on the top right corner and select Preferences. In the Server
Ip add your private IP and in the Server Port add 5555.

Figure 50

Now if you try to login to the application with the default credentials you will get an intercept
on BurpSuite with the username and password in cleartext because the app is using HTTP
and not HTTPS.

24
 Figure 51

5.3.10 Parameter Manipulation with BurpSuite

You can use BurpSuite to manipulate the parameters when they are sent from the application
to the server. First login with the default credentials, e.g. jack:Jack@123$ and then select
Change Password in order to submit a new password for the user. Add the new password,
for example Jack123@, and click Change Password to save it.

Figure 52

Once Burp intercepts the request, right click on it, and select Send to Repeater.

Figure 53

25
Burp Repeater is a tool for manual manipulating HTTP and WebSocket messages and
analyzing the responses. You can change the new password from Jack123@ to
Jack123456@ and send the request to the server. As you can see in the Response tab
password changed successfully.

Figure 54

The Request is vulnerable to manipulation since it’s not asking for the old password and it’s
unencrypted.

5.3.11 User Enumeration with BurpSuite

Using BurpSuite you can perform user enumeration in order to find existing usernames. Log
into the app and when Burp intercepts the request right click on it and select Send to Intruder.

Figure 55

Burp Intruder is a tool for automating customized attacks against web applications. Once the
request sent to intruder you need to specify the position where the payload will be used. To
perform a user enumeration set the payload in the username position and leave the attack
type to Sniper.

26
 Figure 56

Then you need to move to Payload section to add all the potential usernames that the intruder
will try. To add a payload, go to the Payload Options and in the Add filed you can type as
many usernames as you want. In case you have a wordlist, you can add it by clicking on the
Load button.

Figure 57

You can start the attack by hitting the Start Attack button at the top. By inspecting the
responses for each payload it’s possible to enumerate if that username exists or not. For
example, if you check the response for the username “admin” you will see a message that
“User Does Not Exist”. This message is displayed for every username that’s does not exist.

Figure 58
On the other hand, if you inspect the response of the “jack” payload you will get a different
message saying, “Wrong Password”.

27
 Figure 59

Another way to find the difference is by checking the Length column. For every username that
doesn’t exist, the Length value is between 203 to 206, while at the existing user its 199.

Figure 60

5.3.12 Hidden Button for Admin

In the “LoginActivity” source code there is a method called “onCreate” which checks if a
resource string called “is_admin” is set to “no”. If the value is “no”, the method uses the
“setVisibility(view.GONE)” to make a button named “Create User” invisible. The “view.GONE”
parameter makes the view invisible without taking up any space in the layout.

Figure 61

28
You can make this button visible by changing the value of the string resource from “no” to
“yes”. To make the change you first need to decompile the APK file by using a Apktool [27],
which is used for reverse engineering Android files. Type “apktool d InsecureBankv2.apk”

Figure 62

Once everything is extracted navigate to “/res/values/” and open “strings.xml” to modify the
string value to yes.

Figure 63

Next you need to rebuild the application with the new “strings.xml” file. This can be done with
Apktool by typing “apktool b InsecureBankv2”.

Figure 64

To install the new apk file you created, you need to sign it first otherwise the device will not
allow you. To sign the new app, you can use Apk Sign [28] which is a Java tool and it can be
executed in any platform. From the Releases page in GitHub, you can download the “sign.jar”
file. Then move the file in the same folder with the application you rebuild and open a terminal.
You can sign the app by running “java -jar sign.jar InsecureBankv2.apk”. Once the
command is completed you will have a new apk file called “InsecureBankv2.s.apk” which is
the signed one.

29
 Figure 65

Before install the new application on the device with “adb install InsecureBankv2.s.apk” you
need to remove the old one, otherwise you will encounter an error.

Figure 66

The button is now visible. However, if you click on it, you won’t be able to create a new user.
That’s because at the source code the “createUser()” function is still in-progress.

Figure 67

5.3.13 Bypass Android Root Detection

Every time you successfully log into the app, you get a message saying “Rooted Device!!”.
This message is created by a method called “showRootStatus()” which can be found by
looking in the “PostLogin” source code.

30
 Figure 68

To determine if the device is rooted or not it’s using two methods called
“doesSuperuserApkExist()” and “doesSUexist()”. You can find the source code for both
methods in the “PostLogin” file. The “doesSUexist()” method is checking if the “su” command
exists in the “/system/bin/which” folder, while the “doesSuperuserApkExist()”, checks the file
system to see if the “Superuser.apk” file installed.

Figure 69

Figure 70

You can bypass the root detection mechanism by changing smali code which have been
extracted by decompiling the app with “apktool d InsecureBankv2.apk”. The file you need to
modify is in “/smali/com/android/insecurebankv2/PostLogin.smali”. Open the file and go
to line 450 which contains the conditional loop “if-ne v0, v1, :cond_2”.

Figure 71

31
This condition means that if not equal jump to cond_2, which based on the assembly code in
line 472 to 480, cond_2 has the “Device not Rooted!!” tag.

Figure 72

To bypass the root detection you can force a jump always to cond_2, by changing the
conditional loop to a goto loop. First disable the condition in line 450 by adding the “#”
character at the begin of the line and then add a goto loop to jump to cond_2 directly by typing
“goto :cond_2”.

Figure 73

Save the changes and rebuild the app with “apktool b insecurebankv2”. Run “java -jar
sign.jar InsecureBankv2.apk” to sign the application, uninstall the old one and run “adb
install InsecureBankv2.s.apk” to install the modified version. Once the installation is
completed, log into the app by using the default credentials and you will see the message
“Device not Rooted!!”.

Figure 74

32
5.3.14 Exploit Android Broadcast Receiver

An Android broadcast works as a messaging system across applications. A broadcast receiver

is listening and when a message has the right parameters the broadcast triggers an event. In
the manifest file there is a receiver called “MyBroadCastReceiver” with an intent filter which
includes an action called “theBroadcast”.

Figure 75

By looking at the source code of the “MyBroadCastReceiver.java” file, you can see that there
is a method called “onReceive” which is used to trigger the broadcast receiver with two
parameters called “phonenumber” and “newpass”. The method checks if the phone number
has a value and then updates the password from the “mySharedPreferences” file. Then it’s
calling the default sms application and sends a message to the phone number that the
password have been changed, including both the new and the old password in cleartext.

Figure 76
You can trigger the broadcast receiver and update the password by executing the command
“adb shell am broadcast -a theBroadcast -n
com.android.insecurebankv2/com.android.insecurebankv2.MyBroadCastReceiver --es
phonenumber 12345 –es newpass Dinesh123!”.In Windows Subsystem for Android there
isn’t any default SMS application, so in order to check if the command is executed correct
you can use logcat to inspect the traffic by typing “ adb logcat | findstr “password” “.

Figure 77

5.3.15 Exploit Android Pasteboard

Android gives you the ability to copy and paste data by using the clipboard framework. You
can view the contents of the clipboard by calling the “getSystemService()” method of the

33
ClipboardManager. First, open the app and login with the default credentials. After that, select
the Transfer button, type any value in one of the fields and copy it.

Figure 78

Next move to adb and run “adb shell ps | findstr “insecurebankv2” “ to get the ID of the
application.

Figure 79

To check the contents of the clipboard you need to execute the command “adb shell su
u0_a79 service call clipboard 2 s16 com.android.insecurebankv2”. The service call
clipboard instantiates an object of the ClipboardManager by calling the “getSystemService()”
which is represented by the number “2” in the command. “s16” is referring to UTF-16 string
which exist inside the parcel.

Figure 80

Once you run the command you won’t get any output. That’s because this vulnerability has
been patched in the Android 10 and later versions by providing limited access to clipboard
data. Windows Subsystem for Android is using Android 11 and after 20 May 2022 Android
12.1 based on the official Microsoft Page for WSA [29]. In order to see how the vulnerability
would look like, you can check the official walkthrough which contains the following picture.

Figure 81

34
5.3.16 Exploit Android Keyboard Cache

Android uses a dictionary with words entered by a user for future auto-correction. This
dictionary is saved as a database and can be accessed by any application. Sometimes users
add sensitive information such as usernames, mobile numbers, emails addresses, etc. To add
a word in the dictionary you need to highlight it and select “Add to dictionary”. If you open
InsecureBankv2 app and try to add a word in the dictionary database, you will see that there
is no such option available.

Figure 82
That’s because this vulnerability has been fixed on Android 9 and later. In older versions of
Android, the location of the dictionary database should be at
“/data/data/com.android.providers.userdictionary/databases/user_dict.db”. If you start
an adb shell and try to access this file with root permissions, you will find out that this file
doesn’t exist.

Figure 83

In previous Android versions you can pull the file with adb command, “adb pull
/data/data/com.android.providers.userdictionary/databases/user_dict.db” and use
sqlite3 to see the content of the database, as it is in the official walkthrough.

Figure 84

35
6. Pentesting on Android AppSec Application

Android AppSec was created by Hiral M. Patel and Ravi Ramesh in order to help everyone
practice how to exploit android vulnerabilities. It is a CTF (Capture The Flag) style application
and every time you exploit a vulnerability you get a flag which can be submited in the
“ctf.hpandro.raviramesh.info” website and get reward points. You can download the latest
version from the official GitHub page [30] or by searching “hpAndro” on the Playstore [31]
application.

6.1 Install Android AppSec

To install the Android AppSec application on WSA you first need to copy the installation file
(com.hpandro.androidsecurity_1.3.apk) in the ADB folder. Then open the terminal and
connect with the WSA device. Once the connection is done type “adb.exe install
com.hpandro.androidsecurity_1.3.apk”.

Figure 85

From the Start Menu you can run the application.

Figure 86

36
6.2 Exploit Vulnerabilities
In this section we will describe in detail the steps in order to exploit the network
vulnerabilities that exists in the Android AppSec application.

6.2.1 Login Bypass with Cookie Manipulation

By opening the Cookies Manipulation task, we get a login form which expects a username and
a password value. We type “admin” in both fields and press the login button to send the request
and capture it with Burp Suite.

Figure 87

As we can see in the request, the form is creating a cookie and sets the admin value equal to
0.

Figure 88

37
In order to further analyze the request, we will send it to the repeater module. Then we’ll
change the value of the admin variable from 0 to 1 and forward the request.

Figure 89

By inspecting the response tab we can see that we got the flag. The attack was possible since
no cookie protection mechanism was implemented. Cookies are a usual attack vector from
malicious users and should always be protected by the application.

Figure 90

We can also confirm this by sending the request back to the application.

Figure 91

38
6.2.2 REST API HTTP Methods

In the REST API HTTP Methods task we are asked to delete the user “hpAndro” with empid
“31337” and uid “1337”. In the page there is a form which expects one value for the “Your
name” field and one value for the “Your Emp ID” field.

Figure 92

By adding the value “admin” in the first filed and the value “1” in the second we send the
request to Burp Suite. We can see that it’s using the PUT method in order to insert our values.
PUT is a method used to create or update data to a server.

Figure 93

39
In order to delete the user we’ll change the PUT method to DELETE which is a method used
to remove data from the web server. Also, we will modify the “uid”, “uname” and “empid” fields
with the ones we want to remove.

Figure 94

Once we send the request we can see the flag in the response tab. Apart from GET and POST
which are by far the most common methods used in HTTP there are several others like HEAD,
PUT, DELETE, CONNECT, TRACE, OPTIONS and PATCH. Some of these methods could
cause a security risk since they allow an attacker to make changes in the files of the web
server, that’s why their usage must be limited only to trusted users.

Figure 95

40
6.2.3 Server-Side Request Forgery (SSRF)

In this task we need to perform a Server-Side Request Forgery attack to an internal IP with
range 10.10.0.0/22 on port 1337 in order to read the flag from the “data.txt” file. SSRF is an
injection type attack which allows the malicious user to abuse the server-side application in
order to access internal resources.

Figure 96

By pressing the “Connect..” button we get a DNS error saying that we can’t access external
hosts.

Figure 97

Since we have a range of internal IPs we can calculate how many hosts exist in this range by
going to the “https://jodies.de/ipcalc” website and use the parameters that we have. Once we
add everything, we can see that starting address is 10.10.0.1 while the last address is
10.10.3.254, which means that there are 1022 potential hosts.

41
 Figure 98

We’ll choose 10.10.0.1 as a random IP to make a connection to the server and intercept the
request through Burp Suite.

Figure 99

Then we’ll send the captured request to the intruder to perform a brute force attack in order to
find the correct IP.

Figure 100

42
The attack will be performed in the last two positions of the given URL.

Figure 101

Once we add the payload position we’ll choose “Cluster Bomb” as the attack type.

Figure 102

Finally, in the payload section will add the values 0-3 for the first payload, 1-254 for the second
and start the attack.

Figure 103

43
 Figure 104

Once the attack is completed we can see that for all the wrong requests the length value is
4108 while for the correct one is 4131. The correct URL is 10.10.3.37.

Figure 105

By sending a request to the “http://10.10.3.37:1337/data.txt” we get the flag back.

Figure 106

44
6.2.4 JSON To XXE

In this task we were asked to perform an XXE attack in order to retrieve the flag file from the
server. XML External Entity (XXE) is an attack that occurs against an application which is not
validating users input before sending it to the XML parser.

Figure 107

We give "admin" as input for the first field, "1" as input for the second field and press the
"INSERT" button. Once we capture the request in Burp Suite we'll send it to repeater for
analyzing.

Figure 108

45
By inspecting the response tab, we can see that the "uid" parameter is reflected as a result in
the application. First, we will try to modify that value with a different one in order to see if it will
cause any error. More specifically, by changing the value to "9999" and sending the request
no error was occurred.

Figure 109

In this case we can't perform a classic XXE attack because the input data are placed into a
back-end SOAP service. As a result we need to perform a XInclude attack in order to get the
flag. The payload we will use is:

<foo xmlns:xsl=\"http://www.w3.org/2001/XInclude\">
<xsl:include parse=\"text\" href=\"file:///home/hpandro/xxe_flag.txt\"/></foo>

Once we send the request we can see the flag in the response tab.

Figure 110

This can also be confirmed in the application.

Figure 111

46
6.2.5 JSON Web Token (JWT) Misconfiguration

In this task we are trying to bypass a login session by exploit a misconfiguration on the JSON
Web Token. JWT are used to transfer security information between a client and a server.
Server is signing the JWT information with cryptographic algorithms in order to make sure that
the data haven’t been modified by a malicious user.

Figure 112

By adding a random value on both username and password, we’ll try to login in order to grab
the request with Burp Suite. In the intercepted request we can see that there is a cookie named
“jwt_access” with a value on it.

Figure 113

Once we copy this value we’ll go on a website called “jwt.io” to further analyze the JSON
Web Token. In the webpage, we’ll paste our value in the “Encoded” filed and it will
automatically decode the data that exist on this token.

47
 Figure 114

Under the “Encoded” section we can see a message saying, “Invalid Signature”. That’s
because the “your-256-bit-secret” key which is used is wrong. By looking at the login page of
our application we can find a hint saying that the key is “RaviRamesh”, so we’ll modify that
value.

Figure 115

Also, the hint says that the “isadmin” value in the payload data must be true, so we’ll modify
that too.

Figure 115

48
Finally, we will copy the new JWT value from the “Encoded” field and go back to Burp Suite
to replace the old value in the captured request.

Figure 116

Once we send the request, we get the flag.

Figure 117

49
7. References

[1] Static Code Analysis, OWASP, 2022, “https://owasp.org/www-

community/controls/Static_Code_Analysis”.
[2] Source Code Analysis Tools, OWASP, 2022, “https://owasp.org/www-
community/Source_Code_Analysis_Tools”.
[3] Code Review Guide v2, OWASP, 2017, “https://owasp.org/www-pdf-
archive/OWASP_Code_Review_Guide_v2.pdf”.
[4] OWASP Top Ten, OWASP, 2021, “https://owasp.org/www-project-top-ten/”.
[5] OWASP DevSecOps Guideline - v-0.2, OWASP, 2022, “https://owasp.org/www-project-
devsecops-guideline/latest/02b-Dynamic-Application-Security-Testing”.
[6] Static & Dynamic Analysis for Web Applications, OWASP, 2010, “https://owasp.org/www-
pdf-archive/Atlanta_March_2010_Presentation.pdf”.
[7] A01:2021 – Broken Access Control, OWASP, 2021, “https://owasp.org/Top10/A01_2021-
Broken_Access_Control”.
[8] A02:2021 – Cryptographic Failures, OWASP, 2021, “https://owasp.org/Top10/A02_2021-
Cryptographic_Failures/”.
[9] A03:2021 – Injection, OWASP, 2021, “https://owasp.org/Top10/A03_2021-Injection/”.
[10] A04:2021 – Insecure Design, OWASP, 2021, “https://owasp.org/Top10/A04_2021-
Insecure_Design/”.
[11] A05:2021 – Security Misconfiguration, OWASP, 2021,
“https://owasp.org/Top10/A05_2021-Security_Misconfiguration/”.
[12] A06:2021 – Vulnerable and Outdated Components, OWASP, 2021,
“https://owasp.org/Top10/A06_2021-Vulnerable_and_Outdated_Components/”.
[13] A07:2021 – Identification and Authentication Failures, OWASP, 2021,
“https://owasp.org/Top10/A07_2021-Identification_and_Authentication_Failures/”.
[14] A08:2021 – Software and Data Integrity Failures, OWASP, 2021,
“https://owasp.org/Top10/A08_2021-Software_and_Data_Integrity_Failures/”.
[15] A09:2021 – Security Logging and Monitoring Failures, OWASP, 2021,
“https://owasp.org/Top10/A09_2021-Security_Logging_and_Monitoring_Failures/”.
[16] A10:2021 – Server-Side Request Forgery (SSRF), OWASP, 2021,
“https://owasp.org/Top10/A10_2021-Server-Side_Request_Forgery_%28SSRF%29/”.
[17] Windows Subsystem for Android™️, Microsoft, 2022, “https://learn.microsoft.com/en-
us/windows/android/wsa/”.
[18] Android Application Testing Using Windows 11 and Windows Subsystem for Android,
Michael Higgo, 2021, “https://sensepost.com/blog/2021/android-application-testing-using-
windows-11-and-windows-subsystem-for-android/”.
[19] Android Debug Bridge (adb), Android Developers, 2022,
“https://developer.android.com/studio/command-line/adb”.
[20] Android-InsecureBankv2, Dinesh Shetty, 2016,
“https://github.com/dineshshetty/Android-InsecureBankv2”.
[21] https://www.python.org/download/releases/2.7/
[22] https://bytecodeviewer.com/
[23] android-backup-extractor, nelenkov, 2022, “https://github.com/nelenkov/android-backup-
extractor/releases”.
[24] https://www.7-zip.org/download.html.
[25] https://gchq.github.io/CyberChef/.

50
[26] https://portswigger.net/burp.
[27] https://ibotpeaches.github.io/Apktool/.
[28] sign, Appium-boneyard, 2020, “https://github.com/appium-boneyard/sign”.
[29] Release Notes for Windows Subsystem for Android™️, Microsoft, 2022,
“https://learn.microsoft.com/en-us/windows/android/wsa/release-notes”.
[30] hpAndro1337, Ravikumar Ramesh, 2021,
“https://github.com/RavikumarRamesh/hpAndro1337”.
[31] https://play.google.com/.

51