Android InsecureBankv2 Walkthrough: Part 3
In this article, I will be continuing my walkthrough of the InsecureBankv2 Android application created by the GitHub user dineshshetty. Check out Part 1 & Part 2 to see how to setup the application and some of the application’s insecurities I have already demonstrated. I have left a link to application’s GitHub repository in the references below.
Disclaimer
As I stated in Part 1 & 2, I was inspired to make this article out of an interest to learn more about Android mobile application security. This article will obviously contain spoilers about the vulnerabilities present in the InsecureBankv2 Android application. I encourage readers to exploit as many vulnerabilities as they can and then come back later to read this article if you get stuck or want to see a potentially different approach to exploiting an insecurity. Lets get started 😄!
Root Detection Bypass
Each time I successfully login, the new activity contains a message saying that the device is rooted (i.e. “Rooted Device!!”).
Looking at the source code for the “PostLogin” activity, I can see a method called “showRootStatus()” which returns a message based on whether the device is rooted or not.
Looking at the source code above, two methods called “doesSuperuserApkExist()” and “doesSUexist()” are used to determine if the device has been rooted. The source code for both methods can be seen below.
To bypass root detection, I can use Frida to hook both boolean methods and make them return false using the script seen below.
The python script used to load this hook is provided below.
I make sure that the Frida server is running on my emulator and then execute my python script to inject the JavaScript code. Once my script is loaded successfully, I need to successfully login. Once logged in, my script changes the return values of both boolean methods to false.
This results in the application displaying the message “Device not rooted” after logging in.
Insecure WebView Implementation & External Storage
The application allows the user to view statements after they have transferred funds from one account to another.
The source code for the “ViewStatements” activity can be seen in the image below.
I can see that the activity is using a WebView to load a html file stored in external storage, the name of which begins with “Statements_”. I can also see that the developer has enabled JavaScript in the webview with the “setJavaScriptEnabled(true);” method. I can use logcat to identify the name of the file and it’s storage location due to the code “System.out.print” printing the files location to standard output.
adb logcat | grep "$(adb shell ps | grep com.android.insecurebankv2 | awk '{print $2}')"
From the log output, I can see where the file is stored.
/storage/emulated/0/Statements_jack.htmlSince the file is loaded from external storage, the file is readable and writable by everyone. I can replace this file with a new one which contains some JavaScript. This JavaScript will then be executed when the HTML page is loaded.
I can push my new file with the same name (i.e. “Statements_jack.html”) onto the emulator device using ADB.
adb push Statements_jack.html /storage/emulated/0/I can then proceed to click the button “View Statements”. The WebView will load the new “Statements_jack.html” file and execute my JavaScript.
Android Pasteboard Vulnerability
Android provides the clipboard framework for copying and pasting different types of data. It is possible to view the contents of this clipboard by instantiating an object of ClipboardManager by calling the getSystemService() method. To demonstrate this, I can open the transfer activity and copy the account number to the clipboard.
Next, I need the account number of the application. I can use the ps command and grep for this.
adb shell ps | grep "insecure"I can then use the command seen below to view the clipboard contents.
adb shell su u0_a12 service call clipboard 2 s16 com.android.insecurebankv2N.B. The service call clipboard command instantiates an object of ClipboardManager by calling the getSystemService() method. The service codes are 1, 2, and 3, for getClipboardText, setClipboardText, and hasClipboardText respectively. The “s16” argument writes the UTF-16 string STR into the send parcel.
After entering this command, I can see the account number which was copied to the clipboard.
Exploit Android Keyboard Cache
Android has a dictionary, where words entered by a user can be saved for future auto-correction. This user dictionary is available to any app without special permissions. A user can add potentially sensitive information such as a username to the dictionary. This dictionary can be retrieved using ADB as seen below.
adb pull /data/data/com.android.providers.userdictionary/user_dict.dbI can open this database using “sqlitebrowser” and view any words stored in the dictionary. As sseen in the image below, the user has saved their username to the dictionary.
Insecure HTTP Connections
The application makes insecure connections to the server through the use of the HTTP protocol.
N.B. The HTTP protocol does not use encryption. If you’re logging into your bank or entering credit card information in a payment page, it’s imperative that the URL is HTTPS. Otherwise, your sensitive data is at risk.
I can use a tool such as BurpSuite to intercept, inspect and modify the raw traffic passing in both directions. To set this up, I can configure BurpSuite to listen on a specific port on my host-only network adapter by creating a proxy listener. This can be seen in the image below.
I can then create a manual proxy on my emulator in my WiFi settings. I use the IP address of my host only network adapter and the port I specified (i.e. 9999) when I was creating my listener.
I can now view HTTP traffic coming from the application with BurpSuite. When I attempt to login, the credentials used can be seen in plaintext.
N.B. It is possible to view HTTPS traffic with Burp but the burp CA certificate needs to be installed on the target device.
Parameter Manipulation
Using BurpSuite, I can manipulate parameters when they are sent to the python server by the application. I can demonstrate this when the user attempts to change their password, as seen in the image below.
I can use Burpsuite to intercept the HTTP packet and examine it’s contents when the user submits their new password.
I can now manipulate the parameters and change the value to something else. For example, I can change the username from “jack” to “dinesh”, changing a different users password.
Once I’ve changed the username value, I can allow the HTTP packet to be sent and observe that the change was successful.
User Enumeration
The application is weak to user enumeration which can be exploited by using BurpSuite. As seen before, I can use Burpsuite to intercept the users HTTP request to change their password and view the packets contents. As noted earlier, there are two parameters which include the username and the new password. I can right click on BurpSuite and send the interpreted packet to Intruder.
N.B. Burp Intruder is a tool for automating customized attacks against web applications. It is extremely powerful and configurable, and can be used to perform a huge range of tasks, from simple brute-force guessing of web directories through to active exploitation of complex blind SQL injection vulnerabilities.
Once sent to Intruder, I need to mark the position where my payload will be used. I clear all the positions marked initially and then highlight the username value and add it as a position for my payload. The attack type is set to Sniper. The Sniper attack type uses a single set of payloads. It targets each payload position in turn, and places each payload into that position in turn.
I need to set my payload before I can start my attack. For my payload, I can just use a simple list and add some common usernames to the list as seen in the image below.
Finally, I can start my attack by hitting the start attack button located on the positions tab in BurpSuite. The attack will begin and by looking at the responses, it is possible to enumerate usernames that exist. For example, the username admin does not exist and an error is thrown when attempting to change that users password.
However, the username “jack” does exist and so I get a successful response when attempting to change the password.
N.B. Other indicators such as message length can be used as indicators to enumerate users.
Closing Remarks
This concludes Part 3 of my walkthrough for the the InsecureBankv2 Android application. Throughout this series of articles, I have attempted to demonstrate the different vulnerabilities present in the InsecureBankv2 Android mobile application. Feel free to check out Part 1 & Part 2 if you have not already done so. Thanks for reading and till next time😄!
