DIVA

Insecure Logging

Decompile to apk using apktool.

Used scrcpy to show the phone UI.

Using Logcat to the view logs. The screenshot shows that the application insecurely logs the credit-card number.

Vulnerable code snippet.

Hard-codingoding Issues Part 1

Reviewing the code reveals that the vendor key has been hard-coded into the application.

Insecure Data Storage Part 1

After saving the credentials, they are saved as a SharedPreferences file.

Vulnerable code snippet shows that a shared prefs file is created.

Viewing the shared prefs file.

Insecure Data Storage Part 2

The credentials are stored in a database called isd2 in plaintext.

Using an app or sqlite3, it is possible to view the contents of the application.

Insecure Data Storage Part 3

When the credentials are saved, the application saves them to a tmp file.

Viewing the tmp file to reveal the credentials.

Insecure Data Storage Part 4

Initially the application did not have permissions to write to the SD card, so after granting the permissions it was possible to view the credentials on the SD card.

Input Validation Issues - Part 1

Submitting a single quote as the username causes a SQL error that is viewable in the log.

Viewing the activity code also shows that the user input is used directly to construct the query.

Performing a SQL injection to view all the customer data.

Input Validation Issues - Part 2

The webview can also be used to read the sensitive files such as the SharedPreferences.xml

Access Control Issues - Part 1

Using Drozer to view the exported activities.

Calling the APICredsActivity.

Access Control Issues - Part 2

Activity contrains an intent filter

Access Control Issues - Part 3

Using Drozer to view the attack surface of the application. Note that 1 content provider is exported.

Viewing the provider info.

Although the app requires a pin to view the notes, the content provider can be queried directly.

/h

Hardcoding Issues - Part 2

There is a library loaded that is called ‘divajni’