ANDROID PT - DIVA / 8 - Input Validation Issues 2 - File Protocol

INPUT VALIDATION ISSUES 2 - FILE PROTOCOL 

- Layout for this exercise:



- Connecting from Santoku to Nexus 5 with ADB:




- Launching the application: 




- Clicking the tab for challenge 8:

- The application asks for an URL, for instance https://dgmsp.blogspot.com:





































- The browser opens the website of this blog, as expected:




- However, this circumstance can be used to exploit the browser using a different protocol than HTTP, for instance the File protocol, to read the contents of the internal file system, or even data at external storage.

- From a previous exercise, we have some credentials stored at this path:







- Using the File protocole, access to the uinfo file can be achieved:




- Introducing the File path as input, the content of the uinfo file is displayed:




- In the same way, this input validation vulnerability can be used for accessing data at external storage. For instance, let's say that there is a Key file at the SD card:








- Introducing the path to the external storage or SD card, the content of the Key file is displayed:

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: