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-coding
oding 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.
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.
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.
Hardcoding Issues - Part 2
There is a library loaded that is called ‘divajni’
