Have you ever wondered about the vulnerabilities hidden beneath the surface of your favorite mobile apps? I certainly did, which is why I dove headfirst into the deep end of mobile application training and found a mobile application that I can train with. AndroGOAT is an app filled with secrets, each one is a teachable moment in mobile application security. With this article, I’m opening up my diary of discoveries, sharing all the technical moments from my AndroGOAT journey. So feel free to follow along as we explore security flaws of this vulnerable mobile app together!

Installation

For this walkthrough I am using a physical android phone and a VM (Genymotion).

You dont have to use my exact method of setup, you can place platform tools and apk file in the same location or provide full path of their location in order to install the AndroGOAT application to run the Android virtual machine.

Either you can Drag and Drop the APK file of AndroGoat on Android VM or you can install it with Android Debug Bridge (adb).

Installation with ADB:

Open Command Prompt and Navigate to the location of AndroGoat APK file.

Now run following command:

adb devices

This command will show us status of any android device running on our system

As VM which we started earlier is running, now it’s time to install AndroGoat application. Run command given below and shown in figure

adb install AndroGoat.apk

You will get success status printed on command line:

Icon of AndroGoat app will also appear on your VM as shown below:

Tap (Click) on the AndroGoat app Icon to launch the application.

1. HTTP

Setup a proxy on mobile phone like this:

192.168.18.231 is the IP address of my computer which is connected with internet.

Start Burpsuite and enter the proxy details in proxy listener section:

Then open the AndroGoat application and click on HTTP and the traffic will be intercepted in Burpsuite:

2. Intercepting HTTPS

For task 2, we need to export Burpsuite SSL certificate to mobile phone, so that HTTPs based traffic can be intercepted. Certificate exporting option is shown below.

Enter the name of file with extension of .cer:

Transfer burp.cer to the mobile phone files folder and then Go to certificate option in mobile phone settings.

Phone types and menus vary but if you are having issues finding the certificate menu then try to search for “certificate”:

After the certificate is installed on the mobile phone, navigate to the folder where the certificate is stored.

Click on certificate and install it, select the option “VPN and Apps” using any preferred name and press OK:

Now go to the application and click on https. Wait about 5–10 seconds and https://owasp.org will be intercepted by Burpsuite:

3. Certificate Pinning

What we want to do here is install Frida Server and send the server file to the rooted android phone location /data/local/tmp.

Install Frida tools on windows/ linux system as shown below:

Now go to android phone location and run the command:

chmod +x frida-server-16.0.9-android-arm64

After running the above command, type the following command to run Frida server.

Run the following command on windows/linux system to check if Frida is installed correctly.

Now install the objection framework and run it on the host PC system.

Run the following command to bypass SSL/ Certificate pinning on AndroGOAT Application.

objection –g owasp.sat.agoat explore –s “android sslpinning disable”

Now click on certificate pinning in AndroGOAT:

According to this code, if the correct pin is inserted then AccessControl1ViewActivity will be called:

Instead of providing the correct pin, the user can directly jump to the AccessControl1ViewActivity by using the following command:

adb shell am start -n owasp.sat.agoat/.AccessControl1ViewActivity

After running the command successfully, the following activity will be shown:

1. Shared Preferences(Part 1)

In this task, input the username and password of activity and then click on save.

Go into android shell by typing the following commands

adb shell > su > cd /data/data/owasp.sat.agoat/shared_prefs

Then type ls command to list all files and you should see interesting files including users.xml. :)

Show the content of the xml files with cat or nano:

cat users.xml

2. Shared Preferences (Part 2)

Click on “shared preferences — Part 2” to open a score card.

Now go to /data/data/owasp.sat.agoat/shared_prefs

Type the ls command and there will be new file present there named score.xml.

Now edit the score.xml file either by exporting it or by editing it in the location and values will be reflected on the activity page as shown below:

3. SQLite

Next in the Insecure Data Storage section, go to SQLite and enter any username and password and click on Save option.

Now go to cd /data/data/owasp.sat.agoat/databases and type ls –l to list databases.
After that type sqlite3 <database_name> , list tables using the command, .tables, and enumerate the table contents by typing select * from users;

4. Temp File

The temp file is created when a user enters username and password.

After the temp file is created in the application container, go to the application container by cd /data/data/owasp.sat.agoat/ and then type ls –l.

Display the contents of the file users*tmp and it will list the sensitive contents (i.e. username/password) in plaintext.

5. External Storage — SDCard

For this one, ensure that you have granted permissions to the mobile application as shown here:

Now to take a look at the code, open the .apk AndroGoat file in jadx tool and go to InsecureStorageSDCardActivity.

As shown in the red box, the data is going to be stored in SDCARD (external storage) with name “users” prefix “tmp” as postfix and input userinfo will be stored there.

Now access the device with adb shell > su > cd /sdcard/ and type ls –l and cat users*tmp.

1. Cross-Site Scripting (XSS)

XSS (Cross Site Scripting) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted websites. In this case due to lack of input validation any simple/ complex script written in the input text field will be reflected back to user. Like for example write a javascript line i.e <script>alert(‘hello’)</script>

2. SQL Injection (SQLi)

SQL Injection (SQLi) is a common attack vector that uses malicious SQL code for backend database manipulation to access information that was not intended to be displayed.

Following is the screenshot of the code running behind this SQLIActivity, as depicted in the code, there is no input validation on username and if any person enters special chars, then it will get reflected into database or data will be retrieved from database.

As shown below input ‘ or 1=1 — it will fetch data from database because of lack of input validation whilst fetching data from database. It will enumerate all values from database (aGoat) and list all users.

3. WebView

In web view activity, due to lack of input validations and lack of setAllowFileAccess parameter and javascript is enabled, so it will display user sensitive info from application container, if exact path is entered.

Enter exact path of any sensitive resource with prefix file:///, as shown in following application screenshot.

1. Keyboard Cache

Keystrokes are logged in a particular location of application context as shown:

Open the keyboard cache and type in some simple phrases in the username and password fields.

Go the shell of android phone and navigate to user history by using the below location:

adb shell
su
cd /data/data/com.google.android.inputmethod.latin/files/personal/userhistory

Now cat out the contents of UserHistory.en_GB.dict as shown in subsequent pictures. (However, if your keyboard input language is different then it will show with different name here.)

In the contents of userhistory.en_GB.dict you will see the keystrokes strokes input by the user, which was me in this case:

2. Insecure Logging

First inspect the code by going into InsecureLoggingActivity in Jadx and study the code as shown below.

As shown in the picture figure, Log.e is logging username and password into log of the application.

Now just type adb logcat and enter any credentials in GUI of application as shown below and keep the adb logcat running.

In the logcat activity logs, the details of usernames and passwords will be displayed in text.

3. Clipboard — Copy and Paste

Insert some test numbers for a credit card like this:

For the security flaw in this area, the sensitive data is wrongfully being displayed in plaintext (ClipboardActivity).

Inspect the relevant activity HardCodeActivity class and notice the hardcoded promocode as shown:

Now insert the discovered value NEW2019 into the application:

After clicking on verify, the price will go to zero:

Inspect the IsRooted activity as shown below:

There are number of ways to bypass these checks, like using RootCloak, Frida scripts and Magisk. However, we will use the Objection Framework tool already used by us in the Certificate Pinning activity. Now, run the Frida server as already shown and type the following command to bypass the root detection:

objection –g owasp.sat.agoat explore –s "android root disable"

The command above is only different from the objection certificate pinning command at the string “root”.

After successfully running the command, go to the root activity and it will now get successfully bypassed:

While reviewing the emulator detection code and you will find that the isEmulator() function code contains the logic to check for detection of an emulator.

Now, open objection framework and the application:

objection -g owasp.sat.agoat explore

You should be able to list all the class methods with the following command:

android hooking list class_methods owasp.sat.agoat.EmulatorDetectionActivity

In the above mentioned you will see to that all class methods of EmulatorDetectionActivity are listed in the figure. Now, hook the method isEmulator using following command:

android hooking set return_value owasp.sat.agoat.EmulatorDetectionActivity.isEmulator false

Now click on check emulator activity and it will display that the device is not an emulator:

Binary Patching

Inspect the activity of Binary Patching and understand the logic. Here we want to patch the function isAdmin() so that it to returns true.

To decompile this, run apktool with following command:

java -jar apktool.jar d -r "C:\Users\Administrator\Downloads\AndroGoat.apk" -f

Successfully running the command on Windows should look like this:

File location may vary, depending on the stored location of AndroGoat.apk

Now, view the smali files and navigate to the BinaryPatchingActivity.smali

Now take a look at the line 16 and notice that the if-ne (if not equal) is looking for the isAdminText condition.

Change if-ne to if-eq so that isAdmin results into always true as shown below:

Now save the file and build the application folder (AndroGoat) with apktool using this command:

java -jar apktool.jar b -r AndroGoat/ -o test.apk

Download and run uber-apk-signer with following command in order to properly sign and zipalign the output file test.apk:

java -jar uber-apk-signer-1.3.0.jar --apks test.apk

Note: The above version 1.3.0 may vary depending on when you do this

Now install the output application, test-aligned-debugSigned.apk in the android phone.

Now open the application and go to binary patching and you will see “You are admin now”, signifying that application is successfully patched.

I hope you were able to follow along and learn something new from this walkthrough!

~Martian