First, we check if SSL Pinning is enabled in the target Android app by opening up the app. We can see that there is error during the communication between the mobile client and server.

Step 1: Start Frida server in the Android device

adb shell "/data/local/tmp/frida-server &"

Step 2: Run Objection on the target application

objection -g sg.parking.streetsmart explore -q

Step 3: Run the command to disable SSL Pinning in the Android app

android sslpinning disable

Console showing that the method for certificate pinning is bypassed.

Now we can read the request made by the app.

Killing Frida-Server

If you face any error and require to restart the Frida-Server, you can kill the frida server process by following these commands:

adb shell ps -e | grep frida-server kill -9 pid <pid of the frida-server>

Unable to find executable

DIVA Android: Access Control Issues

Published by Bobby Lin on November 3, 2019

Part 1: Starting an activity externally

The existing access control in the app can be bypassed if an activity can be started externally (outside the app). For example, some other app or debugger can trigger the activity. In the DIVA Android app example, you will see that the API credentials can be displayed after being invoked externally.

First, click the button ‘VIEW API CREDENTIALS’. By running adb logcat command, you can see the activity ‘APICredsActivity’ being triggered.

Using the Activity Manager (am), we can invoke the API Credentials activity using the following command:

adb shell am start -n jakhar.aseem.diva/.APICredsActivity

Once the activity is triggered, we can see the API Credentials activity.

Part 2: Starting Activity externally with input

In this part, you will notice that when you try to start the activity from adb, there will be another activity being shown. This means that the previous method in Part 1 does not work now in Part 2. And you will need to examine the source code to find the flaws in the business logic.

Run this command to see how the extra value can be passed:

adb shell am help start

What value should we pass to the command? The name of the value should be ‘check_pin’ and we should pass ‘false’ value so that the pin condition check will pass and allow you to access the API credential activity directly.

Now run the following command:

adb shell am start -n jakhar.aseem.diva/.APICreds2Activity --ez "check_pin" "false"

You will be able to access the API credentials activity.

Part 3: Poor Access Control for Data content

In this part 3, the app is currently using a pin as a form of access control to a particular note. In the source code, we can see that the app is parsing uri content that is hardcoded. You can use this hardcoded value to open the Notes.

Run this command:

adb shell content query --uri content://jakhar.aseem.diva.provider.notesprovider/notes

DIVA Android: Input Validation Issues

Published by Bobby Lin on November 3, 2019

Just like a Web application, the Mobile app also requires validation of the input. Using the DIVA app, you can see how the common input validation issues affect the app’s behavior.

Part 1: SQL Injection

First, you can input a test case to see the output. The result is showing the user name, password and credit card number. Most likely if the data is stored in the SQLite Database, then it might be vulnerable to SQL Injection issues.

From the source code, you can see that the app is making a concatenated query. Moreover, the app appends whatever the result is given to the output.

"SELECT * FROM sqliuser WHERE user = '" + srchtxt.getText().toString() + "'"

To select all users, enter this input and all the user information will be displayed:

 abc' OR '1' = '1

Part 2: URL Scheme Hijacking

It cannot be assumed that the URL input will be what the developer expected it to be. The attacker can manipulate the input to retrieve sensitive files.

For example, if you input this value, the username and password found in shared preference XML file can be retrieved.
file:///data/data/jakhar.aseem.diva/shared_prefs/jakhar.aseem.diva_preferences.xml

To prevent this issue, the developer should validate the URl input and also to set the appropriate level of access control for WebView settings such as setting file setting access to False etc. if it is not required for the WebView to access a file.

Part 3: Lack of input length / size constraint

In some input form , there is no constraint on the length / size of the input. For example, in the DIVA app, you can give a large string value and observe that the app crashes.

It turns out that the activity is loading a native code. You will be able to find the native code in the github repo of DIVA. The divajni code is expecting that the string value to have a length of 20 chars. But if you insert a value that is more than 20 chars, the app crashes because of a segmentation fault in the memory.

The good practice is to validate the size / length of the input first to make sure they are constrained to the requirement.

DIVA Android: Insecure Logging

Published by Bobby Lin on November 3, 2019

Sometimes, sensitive data is accidentally being logged by the app and can potentially lead to information leakage. In the DIVA Android app example, you can see that the credit number is being saved in the diva-log file without any obfuscation at all. The best practice is not to log the sensitive information if possible. If not, the data should be obfuscated.

Here, you can see that an error had occurred when you tap ‘CHECK OUT’ button. The credit card information will be log somewhere and your goal is to find out what the information can be found.

Run this command to find the information:

logcat | grep 'diva-log'

Now, you can see the error message is logging the credit card number as well.

DIVA Android: Insecure Data Storage

Published by Bobby Lin on November 2, 2019

In this post, you will see some of the common insecure methods of storing sensitive data by the Android app. The DIVA app will be used as a demonstration of these issues:

Part 1: Storing in Shared Preferences

First, you try to save a user credentials in the app. After the credentials are saved, now you can look for the location where the data is saved. For Part 1, you will notice that the credentials are saved in the app’s Shared Preferences XML file (also can be verified in the source code).

Now, look for the app’s shared preferences XML file. It should be found under /data/data/<app name>/shared_prefs

Run a cat command on this XML file and you can see the user name and password stored in plain text without any encryption. This is considered as a bad practice and can be avoided by storing the user credentials in the Keystore.

Part 2: Storing unencrypted data in SQLite

Sometimes, developer try to save the credentials or list of sensitive data in the database. This is useful as the structured data will allow faster search result. However, the developer needs to take note that the database in Android is not encrypted. This means that anyone (with root permission) can copy the database and read what is inside.

In the code snippet below, you can see that the data is stored in a database ‘ids2’.

Now, you can copy this database to your local directory (check out this site for more adb commands):

adb pull /data/data/jakhar.aseem.diva/databases/ids2 ids2.db

Open it using DB Browser for SQLite. In the myuser table, you can see the username and password. For good practices, the credentials should be at least encrypted before saving to the database. And the encryption key should be stored in the Keystore.

Part 3: Storing in unencrypted File

A developer might want to temporarily store some sensitive data in a file. If the data is stored in a plaintext file, the data might be leaked easily. It is more secure to encrypt the file if the data needs to be stored in the file.

Part 4: Storing in External Storage

Data stored in external directory can be accessed easily by any party. In addition, if the file and data is not encrypted sufficiently, then any malicious attacker can access the data. In the example, the data is stored as a hidden file ‘uninfo.txt’

You can simply just run a cat command to see this file and the credentials.

DIVA Android: Hardcoding Issues

Published by Bobby Lin on November 2, 2019

The following post will demonstrate how to view the source code in an APK file using JADX GUI to solve the Hardcoding issues in DIVA.

First, we pull the APK file into the local directory.

Then, open up JADX GUI and select the base.apk

The APK will be decompiled and you will be able to see the source code. Now to solve the problem, you will need to find the hard-coded value in the code.

Now, for Part 2, it’s not so straightforward. If you read the code carefully, you can see that the developer is trying to compare the user input and a key from the R file. In this case, the developer is trying to store sensitive access code in the R file (which is a bad practice). Once you navigate to the R file, you should look for ‘hc2Key’ for the access code.