Exploiting Android Architecture
Written by Yuval Batan on
Exploiting Android Architecture
Written by Yuval Batan on
Introduction
The Android operating system powers millions of smartphones worldwide, offering users an excessive number of applications responsible for every aspect of our lives, from personal organization to online banking applications. Many Android applications contain hidden vulnerabilities that attackers can exploit, exposing users to data leaks, unauthorized actions, and other threats. This article explores key components of Android application architecture and demonstrates common vulnerabilities in intentionally vulnerable apps found in the wild.
The Android App’s Key Components
Most Android applications are built with Java or Kotlin programming languages. However, regardless of the programming language, all applications use the following key components:
- Activities
- Intents
- Services
- Content Providers
- Broadcast Receivers
These components work together seamlessly to implement Android applications’ core functionalities, including displaying user interfaces, handling background tasks, responding to system events, and managing data.
Tools
While many tools can achieve the same impact, the following will be used to demonstrate the vulnerabilities:
- Android Debug Bridge (ADB) – A desktop command-line tool for developers to communicate with Android devices. It can be used for many options, such as installing applications, debugging, etc.
- Jadx – An open-source tool used to decompile Android applications (APKs) into readable Java and Smali source code.
- Android Studio – An Integrated Development Environment (IDE) and code editor for building Android applications.
Activities
The Activity is a Class that represents the application’s user interface (UI) and facilitates an entry point for the users to interact with the application’s functionalities. Activities follow a defined lifecycle to ensure smooth transitions and efficient resource management. An Android application includes an Activity for each screen.
One of the vulnerabilities usually related to Activities is Improper Exportation:
The AndroidManifest.xml, a default file in Android applications, contains information and specifications about the different components of the application, including the Activities. Among several specifications, the option exists to mark an Activity as exported, allowing access from other applications. When a sensitive Activity is configured with exported=true, it can be accessed directly without going through application validation, leaving it open to manipulation. This vulnerability can be more common in old applications (API level 17 and above) where the default value of the exported parameter will be true if not mentioned in specific.
In the following scenario, user credentials are expected to be validated by the login screen before proceeding to the next step.
An improperly configured sensitive activity will allow bypassing the login screen and fetching the flag without validating any credentials. The following steps will exploit this misconfiguration:
- View the AndroidManifest.xml file in the application’s Java code and notice that SecondActivity, the Activity responsible for storing the flag, can be exported.
- To bypass the login screen, directly export and trigger the SecondActivity Activity using the following ADB command, leading to unauthorized access:
adb shell am start -n {Package Name}/.{Activity Name}
Mitigation
To mitigate this vulnerability, sensitive components should be set to exported=false or left unconfigured when updates default the exported value to false.
Intents
Many components interact and pass data in the application using the Intent mechanism. There are two types of Intent: Explicit and Implicit. The main difference between these two is how they specify the target recipient of the information or action. Explicit Intents define the target component to handle the Intent, providing a precise destination for the data or action.
In contrast, Implicit Intents declare a general action rather than a specific target, allowing the system to select the appropriate component based on its Intent filters. Each of the Intent types has its vulnerabilities which occur because of their behavior:
1. Implicit Intent
Implicit Intent does not declare a specific component to handle the action, leading to the main issue that can occur if a malicious actor hijacks an Intent using another application on the same device. The attacker’s custom application can register Intent filters to intercept the Intent, resulting in reading sensitive information and executing unauthorized actions on the targeted app.
For example, in the following scenario, the application uses Implicit Intent to load the http://example.com website to the application with the user’s session token passed in the URL.
The vulnerable application can be exploited by following these steps:
- Open the application’s Java code, access the MainActivity Activity, and find the code responsible for accessing the example.com website.
- Notice that the application uses a vulnerable Implicit Intent that does not specify the destination of the data.
- Exploit this code to hijack the user’s session token and build another application on the same device. This is done by writing the following code:
- AndroidManifest.xml – add the ExploitActivity Activity and allow other applications to launch this Activity (exported=true) directly. Also, specify that the Activity should view specifically WEBVIEW actions on the OVAA app.
- ExploitActivity Activity – extract the url parameter value from the vulnerable application’s Intent and log the session token.
- Build and run the exploit application on the same device, which will hijack and log the user’s token in every use of the vulnerable application:
Mitigation
To mitigate this vulnerability, avoid sending sensitive information, such as tokens, passwords, etc., through Implicit Intent and limit its use as much as possible.
2. Explicit Intent
As mentioned, Explicit Intent specifies the target component to get the information, making it safer to use. However, if not configured correctly, Explicit Intent can also be vulnerable and exploited by malicious actors.
Mitigation
It is recommended that the information received from any resource and its permissions be validated, and the components’ entire path must be specified to avoid attacks such as intent hijacking and more.
Services
Services are background-running components in Android applications. Unlike Activities, which provide a user interface, services handle long-running operations or tasks that don’t require direct user interaction. They operate in the background, independent of the Activity lifecycle, and even run when the user navigates away from the application. Some of the vulnerabilities that can occur in these components are:
- Services require specific permissions to access certain resources or functionalities. Improper permission handling, like using unnecessary permissions or granting them to untrusted components, can expose sensitive data or functionalities to malicious actors.
- If services rely on insecure methods for communication, attackers might intercept or manipulate data being exchanged.
Mitigation
To mitigate this vulnerability, grant services only the essential permissions they need to function. Also, secure methods for communication between services and other application components should be used.
Content Providers
Content providers mediate data sharing between Android applications based on multiple options, such as local and remote databases. They are also responsible for ensuring that only authorized applications can access the data, which, when not implemented properly, can result in the retrieval of sensitive information, unauthorized actions, and more.
In the following scenario, the Android application receives a username as input and adds it to the SQLite database using the Content Provider component without any input validation.
- To further explore this functionality and find the vulnerable code, it is possible to fetch the application’s Java source code:
- This code is vulnerable to SQL Injection attacks, allowing SQL queries to be injected into the username field without sanitization.
- Exploit this vulnerability by injecting the ‘ or 1=1;– – basic SQL query into the username field, which will reveal all users in the database as follows:
Mitigation
To mitigate this vulnerability, sanitize user input using well-known libraries before inserting it into the Content Provider’s query.
Broadcast Receivers
Broadcast Receivers are used to send and receive event messages from other applications, the device, and more. These can include system events like battery level changes or user actions such as connecting headphones. If implemented incorrectly, they can introduce vulnerabilities that enable unauthorized access, malicious actions, and exposure of sensitive information.
In this scenario, the application uses an exported Broadcast Receiver to receive device information, including battery events and a custom event for validating the user’s message. Due to the exported attribute, the application’s logic can be exploited by sending values from outside the app.
- To investigate the vulnerable application further, we will examine its estimated source code and find out that the Broadcast Receiver is set to exported and that the correct value is hardcoded as an MD5 hashed value.
- Fetching the correct message value, “summer,” from the hardcoded MD5 algorithm hash is possible.
- Because of the exported Broadcast Receiver, it is possible to send the correct value and retrieve the response from outside the application using ADB, as follows:
adb shell am broadcast -a {Broadcast Receiver Path} –es {Parameter Name} {Value}
Mitigation
This vulnerability can be mitigated by securing all Broadcast Receivers to prevent external access. Custom permissions should be explicitly defined to restrict access to authorized components only.
Conclusion
As the Android ecosystem expands, the importance of secure development practices cannot be overstated. Comprehensively understanding and effectively utilizing the core components of Android applications: Activities, Intents, Services, Content Providers, and Broadcast Receivers will significantly reduce their attack surface. This proactive approach safeguards user data and privacy and fosters trust within the Android ecosystem, benefiting developers, users, and the platform.
Organizations should prioritize cyber security risk assessments and penetration tests to mitigate risks in Android application deployments. Clear Gate, a trusted cybersecurity provider, offers in-depth manual penetration tests to help organizations strengthen their mobile applications’ security and protect valuable data from potential threats.