ANDROID PT - DIVA / 9 - Access Control Issues 1 - Intent Filter Vulnerability (1)

ACCESS CONTROL ISSUES 1 - INTENT FILTER VULNERABILITY (1)

- Layout for this exercise:




- Connecting from Santoku to Nexus 5 with ADB:




- Launching the application: 




- Clicking the tab for challenge 9:



- The application allows to see the API credentials:








- However, the goal of this challenge is to access the API credentials from outside the application, taking advantage of the incorrect validation system used in this activity.

- Let's have a look at the Java source code of the activity for this challenge, AccessControl1Activity: 

  

- The jakhar.aseem.diva.action.VIEW_CREDS is the intent filter responsible for allowing the credentials to be displayed by the application:
































- Opening the Java source code for APICredsActivity.java:

- Also, the AndroidManifest.xml indicates the presence of the mentioned intent filter:

- Now, using the Activity Manager tool we can start the intent filter jakhar.aseem.diva.action.VIEW_CREDS from Santoku Linux, without using the DIVA application interface at the Nexus 5 device:

-The result is the application starting by itself and showing the API credentials:




- By the way, an apart for the previous exercise, Activity Manager can also be used for other tasks. For instance, to open a web browser remotely at the mobile device:

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: