This is the second of a series of articles about the most significant security risks lurking mobile applications. Per the OWASP Mobile Top 10 2016, the second category of most significant mobile risks is the M2-Insecure Data Storage and it is concerned with whether or not sensitive data is securely stored on the application, this category also covers any kind of unintended data leakage.
The Insecure data storage category covers vulnerabilities or risks related to, first if any sensitive information it’s been stored by the application and second how this information is secured, note that from a security point of view, applications should be designed to not store sensitive information on the client side in the first place. This category also cover any sort of data leakage that was not intended, this includes issues related to having sensitive information in the application logs, in the applications memory or it’s decompiled code, the category also includes soring sensitive information on media like SDCard, application files or local SQLite databases.
Exploring the applications folders/files
Exploring the application’s folder and file structure is relatively simple, you can do it using the ADB’s shell and checking the usual folder locations, like /data/data/app.package.name, therefore, the first thing we need to do is find the package name we want to explore, we can find this information on the AndroidManifest.xml configuration file (read here for more about getting this file from the application’s apk using apktool), look for the package field within the manifest tag and take note of the package name (com.securitygrind.application in this case):
Once you have installed and used your target application on the physical or virtual device, connect to it with ADB and navigate to the application’s folder (/data/data/com.securitygrind.application):
Here, you can navigate the application’s file and folder structure. Note: if you are using an Android virtual device and, when trying to list the files/folders, you get an “Permission denied” message, try running the adb root command to run adb as root and get a root shell.
World readable/writable files
While exploring the application’s files and folders, you can also check for any world readable or writable files, these files are sensitive because they can be either read or modified by owner, group or anybody. You can find these files using the next commands:
For word readable files: find / -perm -o+r
For word writable files: find / -perm -o+w
Local databases
Applications may also store sensitive information using local databases, these are created within the application’s folder structure and can usually be explored using a simple database management system like sqlite3. If no encryption was applied to the database, then you can use the following commands to access and explore the database:
Opening the database: sqlite3 database.db
Listing tables: .tables
Select content from a table: select * from tablename;
If any sort of encryption was applied to the database, you will need to find a way to bypass encryption first and then explore the contents of the local database (this will not be covered in this section).
Checking Android logs for sensitive information
Logging information into the Android logs can be very useful during development as it may be used for troubleshooting specific circumstances of your application execution. However useful logging may be during development, it can represent a security risk in the sense that, if not done carefully, an application may leak sensitive information to an attacker that has access to the device, through malware or a repackaged application acting on behalf on the attacker. Here, we will see how to access and analyze application logs using the logcat command available through the Android Debug Bridge.
You can the Android logs using logcat; a command-line tool that dumps a log of system messages, including stack traces from errors and messages written from an application using the Log class. You can read more on viewing and analyzing Android logs with logcat.
Examining the application’s memory
While developing your application, dumping and analyzing it’s memory can help you troubleshoot memory-related issues like leaks, garbage collection, duplicated strings, etc. From a security point of view, we dump and analyze the memory of an application looking for sensitive data that may stay in the memory longer that it should and thus exposed to a possible attacker with physical access to the device or a malicious application acting on behalf of the attacker.
To do this you can first get a memory dump using the Android Device Monitor, covert it using hprof_conv and exploring with the Memory Analysis Tool, here you can find more about dumping and analyzing an Android application’s memory.
Reverse engineering the application’s code
Reverse engineering an Android application can yield decompiled code that is very similar to the original source code (if no obfuscation was applied in the first place). From a security point of view, this can be used to check if any sensitive information has been hardcoded within the code, in trying to understand how the code flows to find any possible vulnerability or in checking whether or not any kind of obfuscation has been applied to the code. Find more on reverse engineering an android application.
Conclusion
Insecure Data Storage is the second OWASP Mobile Top 10 category affecting mobile application, this category is concerned with checking if any sensitive information is stored on the mobile application, how it is stored and if any sensitive information has been unintendedly leaked. From a security point of view, sensitive should be handled at server level and not at the client side.
Recent Comments