ANDROID PT - DIVA / 5 - Insecure Data Storage 3 - Temporary Files

INSECURE DATA STORAGE 3 - TEMPORARY FILES

- Layout for this exercise:




- Connecting from Santoku to Nexus 5 with ADB:




- Launching the application: 




- The fifth challenge is based on the fact that some applications store sensitive information in temporary files.

- Clicking the challenge 5 tab:




- The application asks for credentials, username and password, and then saves them:

- Looking at the Java source code of the activity for this challenge, InsecureDataStorage3Activity.java, we have a hint about where the credentials have been stored:





- The method saveCredentials informs about the storage procedure for the credentials. A temporary file uinfo is created, where the credentials coming from the user input are saved:







- Looking for the temporary file contained at the data directory:






- The credentials are available inside the temporary file:

ANDROID PT - DIVA / 4 - Insecure Data Storage 2 - Local Databases

INSECURE DATA STORAGE 2 - LOCAL DATABASES


- Layout for this exercise:




- Connecting from Santoku to Nexus 5 with ADB:




- Launching the application: 




- The fourth challenge is based on the fact that some applications store sensitive information in local databases. 

- Clicking the challenge 4 tab:




- The application prompts the user for credentials (username + password) to be saved.

- In this example, let's introduce these simple credentials:

     username: Alice
     password: PasswordForAlice


- The applications displays a message stating that the credentials have been successfully saved:




- Searching inside the package jakhar.assem.diva, there is a folder named databases:






- Opening the folder, there are a number of different databases. We could try any of them until finding interesting information. However, for the sake of simplicity, let's go directly to ids2:




- Android uses SQlite database management system:




- There are 2 tables inside the ids2 database:




- Selecting everything from the table myuser, we find the credentials introduced by the user:

ANDROID PT - DIVA / 3 - Insecure Data Storage 1 - Shared Preferences

INSECURE DATA STORAGE 1 - SHARED PREFERENCES

- Layout for this exercise:




- Connecting from Santoku to Nexus 5 with ADB:




- Launching the application: 




- The third challenge is based on the fact that some applications store sensitive information, for instance small name or key value pairs, at local storage files like the Shared Preferences folder (shared_prefs). Although not recommended, a lot of developers use this method.


- Clicking the challenge 3 tab:




- The application prompts for credentials (username + password) to be saved:

 

- Let's introduce these simple credentials:

       username: Bob
       password: PasswordForBob


- The applications tells that the credentials have been successfully saved:

 


- Going to the activity for this challenge, InsecureDataStorage1Activity.java (see how to do it here):



- Opening the file to analyze the Java source code. The saveCredentials method uses the default Shared Preferences folder to store the credentials entered by the user:





- Going to the /data/data/jakhar.aseem.diva (name of the package) the shared_prefs folder is found:


 

- Checking its content:

 

- Opening the .xml file, we find the credentials previously introduced by the user:

ANDROID PT - DIVA / 2 - Harcoding Issues 1

HARDCODING ISSUES 1

- Layout for this exercise:




- Connecting from Santoku to Nexus 5 with ADB:




- Launching the application: 




- The challenge 2 is based of the fact that many Android applications hardcode sensitive information in the source code. 

- This is an important vulnerability because using reverse engineering it would be possible to see that sensitive information. Examples could be access keys, passwords, etc ...

- Clicking the second challenge:




- The application prompts the user to introduce the vendor key to grant the access:



- Testing any invalid key, the applications denies the access, as expected:



- Once the application is decompiled with jadx, as done in the first post of this series (see here), there is access to the source code of the activity related with this challenge 2:




- Opening the Java source code for the activity of this challenge 2 (HardcodeActivity.java), it is very clear how the access is implemented. 

- In case of the hardcoded key "vendorsecretkey" matching (equals) the key entered by the user the access is granted, and denied otherwise:






- Checking that hardcoded key "vendorsecretkey" is the right one, the access is granted:

ANDROID PT - DIVA / 1 - Insecure Logging

INSECURE LOGGING

- Layout for this exercise:



- Connecting from Santoku to Nexus 5 with ADB:




- Launching the application: 




- The first challenge is about how insecure logging may leak sensitive information introduced by users unaware of the vulnerability:




- The application prompts the user to introduces a credit card number:




- From Santoku, the PID of the process is discovered:




- Android holds a centralized logging system that is accessible to all applications on the device. The ADB shell logcat command grepped to the DIVA's PID number outputs in real time debugging information about the application:




- To test the vulnerability, the user introduces his 16 digits credit card number. The answer by the app is an error message:




- However, the logcat command from Santoku shows in plain text the credit number introduced by the user of the application: