INPUT VALIDATION ISSUES 3 - BUFFER OVERFLOW
- Layout for this exercise:
- Connecting from Santoku to Nexus 5 with ADB:
- Launching the application:
- Clicking the tab for challenge 13:
- The applications prompts the user to enter any input able to crash the app.
- Entering 1111 the application just answers "Access denied!":
- However, entering a long string of characters, let's say a string of 30 "1"s, the app stops after crashing:
- To understand what has happened inside the app, it is very convenient to examine the log generated by the command logcat.
- We see a fatal signal (SIGSEGV = segmentation fault, or segmentation violation), because the operating system considers protected the memory address 0x31313131 (0x31 is the ASCII code for character "1"):
- Looking up into the Java source code of the challenge, InputValidation3Activity.java:
- The application is using JNI (Java Native Interface), what suggests that the method DivaJni is related to a program written in other language:
- Going to the source code of the applications, there is a program divajni.c written in language C:
- Opening divajni.c, there is a constant (#define CODESIZEMAX 20) defining a maximum value of 20, later used to determine the size of the string code:
- Also, the function strcpy copies the string entered by the user over the variable code:
- The problem is that the function strcpy does not check whether the size of the destination's buffer is large enough to hold the source parameter.
- A consequence of function strcpy bad usage is the corruption of memory or buffer overflow, and eventually the crash of the application.
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:
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:
