bookmark_borderTesting for Mobile Vulnerabilities: Hardcoded Credentials and Other Tricks – Part 1

One common mobile application vulnerability is the use of hardcoded credentials, API keys, or application functions such as backdoors or undocumented API requests. In my own vulnerability testing I have found various API keys coded into applications that allow for use of APIs outside the scope of their intended purpose. In this blog post I would like to go over some methods used to locate such issues using InsecureShop. I will not be detailing how to jailbreak, root, or bypass ssl pinning for applications please see Google for such resources. 

First you will need to pull the application from the android device using adb. Once pulled from the device use the following apktool command below to decompile the apk and begin the reverse engineering process.

apktool d base.apk -o dis-insecureshop

Nuclei

Nuclei has a great set of template developed for the purpose of scanning decompile apks for keys, databases, and various activity related vulnerabilities. 

Once you have decompiled the apk you can then run nuclei against the directory created via the -o flag. 

Often developers will leave API keys or any other hardcoded secrets in the /res/values/strings.xml file. So it is a common location to check for various hardcoded values. 

Jadx-gui 

Jadx-gui is the swiss army knife of any android mobile penetration tester. In a nutshell this tool will convert the Davlik code to Java which allows for easier source code review. In this section of the post I would like to go over how to locate the hardcoded credentials. 

Under the AndroidManifest.xml file we can see an activity with a class named LoginActivity which is highlighted in red.

Navigating to the LoginActivity class we can see that a few conditions are met against the username and password variables submitted by the user. As we can see in the screenshot below on line 43.

An if statement compares the Util class verifyUserNamePassword method as seen in the Util class on lines 12 and 18. 

But the hardcoded credentials are stored in clear text on line 14. Using this username and password combination we can login into the InsecureShop application.

Objection

Objection is another powerful tool that I use as part of my methodology for mobile pentesting. This tool is powered by frida for real time hooking of an android or iOS application. 

In this exercise we are going to bypass a boolean class built into the verifyUserNamePassword method called by the Util class. We can use this to bypass the login authorization and load directly into the InsecureShop app. Refer to line 18 of the prior screenshot which sets a boolean operation. 

First off we will load the gadget into objection and begin exploring the underlying classes and methods for our attack path.

Once we have objection hooked onto the InsecureShop app we will want to dump all the classes of the application and begin exploring the methods.

Now that we have identified all 39 classes we can see we have a class titled Util at the very bottom. Now let’s list all the class methods using objection. 

As we can see there is a method that takes a boolean value to compare the LoginActivity values username and password. This method is called verifyUserNamePassword. Let now set the value to true and attempt to login to the application. 

Now we can login to the application with any username or password combination.

Remediation 

Do not set hardcoded credentials or sensitive data in source code. It is very easy for attackers to gain access to the base apk of your application and reverse engineer the code. 

https://cwe.mitre.org/data/definitions/798.html

Below are public reports disclosed via HackerOne related to this issue.

https://hackerone.com/reports/412772

https://hackerone.com/reports/753868

https://hackerone.com/reports/792850