AdSense

Saturday, December 31, 2016

ANDROID PT - DIVA / 7 - Input Validation Issues 1 - SQL Injection Vulnerability


INPUT VALIDATION ISSUES 1 - SQL INJECTION VULNERABILITY

- Layout for this exercise:





- Connecting from Santoku to Nexus 5 with ADB:




- Launching the application: 





- Clicking the tab for challenge 7:




- The application prompts the user to introduce an username. If the username is invalid the applications outputs a "not found" message:




- The goal of this challenge is to get data related with users stored into the local database. 

- Examining the Java source code for this activity, SQLInjectionActivity.java:




- The Java source code informs about an SQLite database storing the users credentials:








- The SQL sentence embedded into the Java code queries from users stored in the database:




- This query is vulnerable to a typical SQL injection like this:


SELECT*FROM sqliuser WHERE user = 'Thomas' or '2'='2'--

- Examining the previous sentence, the final string is composed of two parts. The first part corresponds to an invalid user, but it is linked to the second part with an OR binary operation. The second part is always "true" ('2'='2'), so the whole string is also "true" (0 OR 1 = 1). The remaining two hyphens -- mean that everything after the hyphens is considered a comment.

- Introducing as input the expression Thomas' or '2'='2'--, the SQLite database validates it as "true", giving access to all the data stored at the database:









ANDROID PT - DIVA / 6 - Insecure Data Storage 4 - External Storage


INSECURE DATA STORAGE 4 - EXTERNAL STORAGE


- Layout for this exercise:





- Connecting from Santoku to Nexus 5 with ADB:





- Launching the application: 





- Clicking the tab of the challenge 6:



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




- Examining the Java source code of this challenge, InsecureDataStorage4Activity.java, helps to understand how the application saves the credentials:




- The method saveCredentials indicates that an external storage directory is used to save the credentials, inside a file called .uinfo.txt. The dot at the beginning of the file means that it is a hidden file, giving it a layer of security:








- Looking inside the SD card directory with command ls, nothing interesting is found:






- However, when command ls is run with -la options, it is possible to detect hidden files like .uinfo.txt, starting with a dot:




- Openning the content of the file, the credentials are available:



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: