ANDROID PT - DIVA / 12 - Hardcoding Issues 2 - Shared Object Files

HARCODING ISSUES 2 - SHARED OBJECT FILES

- Layout for this exercise:



- Connecting from Santoku to Nexus 5 with ADB:




- Launching the application: 




- Clicking the tab for challenge 12:




- The application prompts the user for a key. Introducing an invalid key the access is denied:




- Let's have a look to the Java source code of this challenge, Hardcode2Activity.java:




- First, it is important to notice that in this activity the JNI (Java Native Interface) is used to validate the access.

- Java Native Interface is a programming framework that enables Java code running in a Java Virtual Machine (JVM) to call and be called by applications and libraries written in other languages such as C, C++ and Assembly.

- The access method gets a text using JNI and checks whether the text entered by the user matches or not the valid key.





- Also, it is interesting to see the source code for DivaJni.java:









- Going into the application data directory, there is a lib directory:






- Inside the lib directory there is a libdivajni.so file:




- .so (shared object) files are a type of dynamic libraries used with Unix systems (similar to .DLL's for Windows). Code stored inside a .so file is not embedded in a binary. Instead it's just referenced, so the executable will depend on it and the code from the .so file is just added/loaded at runtime.

- .so files are usually written according to the ELF (Executable and Linkable Format) standard.

- In order to analyze the file, we can pull it out from the mobile device to Santoku:




- Now, the file is available to be opened at Santoku:




- Either objdump or readelf can be used to disassemble the file, and look up into the .rodata segment (read only data, storings constant data) of the program with similar results:






- Both outputs indicate the presence of a "suspicious" string ... maybe the secret key?




- Running strings command over the file libdivajni.so, the string olsdfgad;lh appears again:




- Finally, checking the source code of the application, the C program divajni.c holds the original C language program where the vendor key was stored as a constant (#define VENDORKEY "olsdfgad;lh"), and later compared with the function strncmp:











- The most important conclusion from this exercise would be to remember that developers often hardcode keys into .so files.

- To test the validity of the research, using the previous string the access is actually granted:

ANDROID PT - DIVA / 11 - Access Control Issues 3 - Content Provider Vulnerability

ACCESS CONTROL ISSUES 3 - CONTENT PROVIDER VULNERABILITY

- Layout for this exercise:




- Connecting from Santoku to Nexus 5 with ADB:




- Launching the application: 




- Let's see how the challenge 11 works. Clicking the tab:




- The user is prompted to create a PIN to protect private information stored on the application:




- Using the newly created PIN, access to some private notes is available: 







- The goal of this challenge is to bypass the access control provided by the PIN, being able to read the private notes from outside the application. 

- A content provider manages access to a central repository of data. A provider is part of an Android application, which often provides its own UI for working with the data. 

- However, a content provider is primarily intended to be used by other applications, which accesses the provider using a provider client object. In other words, content providers are the standard interface that connects data in one process with code running in another process. 

- Checking the source code for the activity AccessControl3Activity.java:











- Also, the source code of AccessControl3NotesActivity.java:











- In the same way, checking the AndroidManifest.xml, the content provider jakhar.aseem.diva.provider.notesprovider is detected. 

- One of its parameters is androd:exported="true", what makes it vulnerable to be accessed without permission. In order to make it secure, it should be put to either "false" or added a permission to access it:











- Using the finduri option by Drozer, the content provider is found:




- Running the query option by Drozer, the notes are available from Santoku, outside of the application:




- Also, adb shell content query can be used to access the notes:

ANDROID PT - DIVA / 10 - Access Control Issues 2 - Intent Filter Vulnerability (2)

ACCESS CONTROL ISSUES 2 - INTENT FILTER VULNERABILITY (2)

- Layout for this exercise:




- Connecting from Santoku to Nexus 5 with ADB:




- Launching the application: 




- Clicking the tab for challenge 10:




- The applications asks the user to register at a website in order to get a PIN, valid to login and see the content of some API credentials related to a third party application:




- Using a false PIN, the access is denied:




- The goal of this challenge would be to access the third party API credentials from outside the application, without using any PIN. 

- Looking at the AndroidManifest.xml, inside the activity for this challenge it is defined the intent filter jakhar.aseem.diva.action.VIEW_CREDS2:







- We could try using the Activity Manager and starting the intent filter, but it does not work because it just prompts the user for registering:







- However, using Drozer will be a lot more powerful. Setting up the Drozer server at Nexus 5:

- Launching the Drozer client at Linux Santoku:

- Running the info option, the activity APICreds2Activity is detected:




- Opening the Java source code of the activity APICreds2Activity:









- It is noticeable that a boolean is compared to the value "true", and then asked for registering at a website.




- Opening the AccessControl2Activity.java for this challenge:









- So, as mentioned, a boolean is defined to validate the PIN entered by the user.

- Going to the code of the application, a string called check_pin is defined:







- Now, from Drozer the value of check_pin is changed from "true" to "false", and the intent filter started with Activity Manager in order to bypass the access control protection: 




- The result is successful because the API Credentials are now available for the user without entering any valid or invalid PIN: