Exploring Android File System and Log Vulnerabilities

Securing Android: An In-Depth Exploration

Table of contents

Introduction

Continuing from the previous chapter of this series, we delve deeper into the critical aspects of the file system within Android applications, focusing on security vulnerabilities and best practices. Using the Objection tool, a powerful asset for mobile security assessments, we will analyze the directories used by the com.app.damnvulnerablebank application.

Key points covered in this article include:

1. File System Overview: We start by understanding the key directories in an Android application, such as cache, code cache, external cache, files, and OBB directories. We discuss their roles and the potential security implications associated with each.
2. Analyzing Application Directories with Objection: By using the env command in Objection, we gather valuable information about the application's directories.
3. Significance of the /data Directory: We delve into the /data directory, which is crucial for storing app-specific data. This section explains the subdirectories within /data, their purposes, and the security measures that protect sensitive information from unauthorized access.
4. Understanding the /storage Directory: This section explains the structure of the /storage directory, which is used for external storage and accessible by users and other apps with appropriate permissions. We discuss how data in this directory can be more exposed to potential security risks.
5. Inspecting the Data Directory: We demonstrate how to compress and analyze the data directory of the application using the tar command. This allows us to inspect the contents and identify potential security vulnerabilities.
6. Security Implications of JWT in Logs: Finally, we address a common security vulnerability: the exposure of sensitive information, such as JWT tokens, in application logs. We explain how to detect these tokens in logs and discuss the risks associated with this practice.

By the end of this article, you will have a comprehensive understanding of the file system structure in Android applications, the security risks involved, and practical steps to mitigate these vulnerabilities. Let's dive in and explore how to safeguard sensitive information in mobile apps.

File system

As we explored in the previous chapter, the Objection tool is a powerful asset for assessing the security of mobile applications. Running the env command in Objection provides valuable information about various directories used by the application under analysis. Here, we break down the output obtained for the com.app.damnvulnerablebank application on an Android device:

1. cacheDirectory: This directory (/data/user/0/com.app.damnvulnerablebank/cache) is where the app stores temporary data and cache files. The system can remove these files to free up space when necessary.
2. codeCacheDirectory: Located at /data/user/0/com.app.damnvulnerablebank/code_cache, this directory stores data that helps speed up code execution, such as runtime compilations.
3. externalCacheDirectory: This directory (/storage/emulated/0/Android/data/com.app.damnvulnerablebank/cache) functions similarly to cacheDirectory, but it is on external storage. It is accessible by the user and other apps with appropriate permissions.
4. filesDirectory: The files directory (/data/user/0/com.app.damnvulnerablebank/files) is used for storing persistent data that should survive through the app's lifecycle. Unlike the cache, data here is not automatically removed by the system.
5. obbDir: The OBB directory (/storage/emulated/0/Android/obb/com.app.damnvulnerablebank) stores Opaque Binary Blob (OBB) files, which typically contain large supplementary data for the APK, like additional graphics or media.
6. packageCodePath: This path (/data/app/com.app.damnvulnerablebank-210K03gT5qN-QA-_MgWCHA==/base.apk) indicates where the installed application's APK file is located. It contains the app's code and resources.

To fully understand the significance of these directories, it's essential to look at the broader context of the /data and /storage directories in Android.

The /data Directory in Android

In Android, the /data directory is a crucial part of the system's storage architecture. It is primarily used for storing app-specific data and is divided into several subdirectories:

• /data/app: This subdirectory stores the installed APK files of apps.
• /data/data: Here is where app-specific data is kept, including configurations, databases, shared preferences, and files.
• /data/user/0: A symbolic link to /data/data, representing the primary user's data directory in a multi-user environment.

The /data directory is only accessible by the system and the respective app, ensuring that sensitive data is protected from unauthorized access.

The /storage Directory in Android

The /storage directory is used for external storage, which can be accessed by the user and other apps with the appropriate permissions. It is divided into several parts:

• /storage/emulated/0: This is the primary shared storage location, often referred to as "Internal Storage" by users. It is where the app's external cache, files, and OBB data are stored. For example:
  • /storage/emulated/0/Android/data/[app_package_name]/cache: Stores the app's external cache files.
  • /storage/emulated/0/Android/data/[app_package_name]/files: Stores the app's external files.
  • /storage/emulated/0/Android/obb/[app_package_name]: Stores OBB files for the app.
• /storage/sdcard1 (or similar): Represents the external SD card if available.

The /storage directory is more accessible compared to the /data directory and is used for data that can be shared between apps and with the user, such as media files, downloads, and documents.

Inspecting the data directory

Comparison of the two directories reveals that the storage directory is empty, whereas the data directory contains various directories that may contain valuable information. Therefore, our plan is to compress all the data using tar and analyze it on our machine.

tar -zcf /sdcard/Download/data.tar.gz /data/user/0/com.app.damnvulnerablebak

After creating the compressed file containing all the data, we can download it using adb and the pull command. Subsequently, we can extract the contents using tools such as atool or tar.

To get a high-level view of all the files inside the data directory, we can use the tree command. One of the files that appears to be the most interesting is jwt.xml.

Upon examining the file's contents, we immediately notice the presence of the application's authorization token (JWT). This poses a significant security risk, as sensitive information of this nature should be securely stored to prevent unauthorized access by malicious individuals. In a real-world scenario, such as with a banking application, unauthorized access to a JWT could potentially lead to the exposure of sensitive user data.

One of the recommended tools for analyzing JWT tokens is jwt.io. If you are unfamiliar with JWT tokens, I have a chapter in my series on hacking APIs that delves into them in depth.

As shown in the image above, jwt.io allows us to clearly view all the data contained in the JWT, including the username and admin status of the user.

One of the initial steps we can take, especially if we know the JWT is signed with HS256, is to attempt to crack it using tools like hashcat. If successful, we could potentially modify the JWT and forge tokens for any user. To attempt cracking the JWT, the following command can be used:

hashcat -a 0 -m 16500 jwt.txt /usr/share/wordlists/rockyou.txt

In this scenario, the JWT was successfully cracked, revealing that the secret used to sign the JWT is "secret." With this knowledge, the authorization system of the application has been compromised.

Abusing the JWT

For example, if we intercept traffic using BurpSuite when accessing the user profile, we can observe how the JWT is used to authorize the user and retrieve their corresponding data, such as username and account number. This is visible thanks to the interface, but the response of the request only shows data that appears to be encrypted. Therefore, we rely on the user interface to view the data sent and received for the user.

By modifying the JWT using BurpSuite plugins like JSON Web Tokens, we can attempt to change the username and re-sign the token with the correct password. This allows us to potentially impersonate another user (in this we will try to impersonate the user rsgbengi).

After doing this, I notice that the information of the profile of the user impersonated is not shown my the interface of the application.

This means that we depend on the encrypted response data to understand what is happening. In future chapters of this series, we will learn how to decode this encrypted data.

Sensitive information in logs

Sensitive information exposure in logs refers to the practice of recording sensitive data, such as authorization tokens or user credentials, in application logs. In Android applications, this is particularly risky because logs can be accessed by other apps or malicious actors, leading to potential security breaches.

A common practice when identifying that an application uses a JWT is to search for it in the logs. Developers often save the value of JWTs in the logs, but this is considered a vulnerability because it exposes sensitive information that could be exploited by malicious actors.

To analyze all the logs generated by the application, we can use the following command:

adb logcat | tee logs.txt

This command will create a file with all the logs generated by the Android device. We can then analyze this file to detect sensitive information, such as the JWT. Additionally, if we know that the application uses card numbers or similar sensitive data, we can look for this type of information in the logs as well.

In this case, as you can see in the following image, if we search for "token" after a successful login, we can find the JWT in the logs, demonstrating that the vulnerability is present in the application.

cat logs.txt | grep -i "token"

Conclusions

In this chapter, we explored the security vulnerabilities within the Android file system, focusing on the com.app.damnvulnerablebank application. Using the Objection tool, we gathered detailed information about various directories and highlighted the importance of understanding their roles. We demonstrated how to inspect and analyze these directories to uncover sensitive information, such as JWT tokens, that may be improperly stored in logs. By identifying these vulnerabilities, we underscored the need for secure data handling practices to protect against unauthorized access and potential security breaches.

In the next chapter, we will delve into the encryption algorithm used by the application. This will help us determine if we can exploit the JWTs to access data from other users, further assessing the security measures of the application.

References

1. OWASP Mobile Security Testing Guide: An essential resource for understanding the various aspects of mobile security testing. OWASP MSTG
2. JWT.io: A tool for decoding, verifying, and generating JSON Web Tokens. It also provides comprehensive documentation on JWTs. JWT.io
3. Objection - Runtime Mobile Exploration: A powerful tool used for assessing mobile application security. Detailed documentation and usage guides can be found on their official site. Objection Tool
4. Android Developer Documentation: Official documentation from Google on Android's file system and security practices. Android Developers
5. Hashcat - Advanced Password Recovery: A popular tool for cracking passwords, including JWTs. Hashcat
6. ADB (Android Debug Bridge) Documentation: Essential for understanding how to interact with Android devices via command line. ADB Documentation
7. Burp Suite Documentation: Comprehensive guide on using Burp Suite for web application security testing, including JWT manipulation. Burp Suite
8. NIST Guidelines on Secure Password Storage: Best practices for storing and managing passwords securely. NIST Guidelines
9. RockYou Wordlist: A commonly used wordlist for password cracking and security testing. RockYou Wordlist
10. Cybersecurity Blog on Mobile App Penetration Testing: A detailed blog that covers various aspects of mobile app security testing. Cybersecurity Blog

Chapters

Comprehensive Android Security Testing: Patching, Objection, and API Backend

Previous chapter

Cracking the Code: Exploring Reverse Engineering and MobSF for Mobile App Security

Next chapter

arrow_upward