In this article, I will be walking through the InjuredAndroid CTF. This is a vulnerable Android application with CTF examples based on bug bounty findings, exploitation concepts, and pure creativity. I have left a link to the creators Github and the GitHub I used to download the APK in the references below for anyone interested in trying out the CTF themselves.
Disclaimer
This writeup will obviously contain spoilers and I encourage readers to attempt this CTF before looking at this article. You will learn more by attempting it yourself first and will gain more satisfaction from solving the challenges yourself.
The author of this CTF has also mentioned that:
Looking at the source code of the applications in the InjuredAndroid directory, InjuredAndroid FlagWalkthroughs.md file, or binary source code in the Binaries directory will spoil some if not all of the ctf challenges.
I must also point out that challenge seven and eight for the release of the APK I used do not function properly and do not have flags. I discovered this after starting the writeup and decided to continue on anyways. With all that said, it’s time to move onto to the writeup!
Initial Setup
For this CTF, I will be using a Kali Linux virtual machine as my host device and a Samsung Galaxy S8 emulator created with Genymotion with the following specs:
To begin the CTF, i connected to my emulator using Android Debug Bridge (ADB) and installed the “injuredandroid.apk” file.
Looking at my emulator, I can see that the application has been installed successfully.
The CTF author also highly recommends decompiling the “injuredandroid.apk”. To accomplish this, I will be using a tool called Mobile Security Framework (MobSF). MobSF automates the process of decompiling the APK, reading the manifest file, identifying issues in the source code and in the Manifest file, extracting the certificate of the application etc. and saves me from having to do this manually. The image below shows the application has been successfully decompiled by MobSF.
With the initial setup out of the way, I can now move on to the challenges.
XSS Test
Opening the application, I am greeted with the following main activity.
There appears to be eight flags in total. According to the author:
XSSTEST is just for fun and to raise awareness on how WebViews can be made vulnerable to XSS.
Looking at the XSSTEST activity, I am presented with a simple input field where I can submit text.
I can enter some simple JavaScript that will create and alert box to demonstrate if the vulnerability exists.
<script>alert('XSS!!')</script>
Entering this input causes an alert box to be generated when the activity used to display our input is loaded.
The challenge recommends looking at the “DisplayPostXSS” activity to determine what makes this activity vulnerable. The source code for the “DisplayPostXSS” activity can be seen in the image below.
Examining the source code, I can see that a new WebView object is created which allows developers to display web content as part of their activity layout. This activity is vulnerable to XSS because the developer has enabled JavaScript execution as seen highlighted in red above. This is a nice, simple example of how developers can leave WebViews vulnerable to XSS.
#mobile-app-security #ctf-writeup #technology #android #mobile-app-testing #android
