Exploiting Android Architecture
Clear Gate | Cyber Security & Research
In-Depth, Manual Penetration Tests
Written by Yuval Batan, Penetration Tester at Clear Gate Cyber Security and Research.
This article is also available on our blog:
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 can be manipulated, putting many users at risk for leaking sensitive information, unauthorized actions, and more. In this article, we will explore the key components of the Android application architecture and demonstrate common vulnerabilities for each relevant component on several intentionally vulnerable applications that can be 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:?
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 various tools can be used to achieve the same impact, we will use the following tools for demonstrating the various vulnerabilities:
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, there is the option to mention if the Activity will be exported, which means other applications can access it. When configuring a sensitive Activity with exported=true, the application can be manipulated by accessing the sensitive Activity directly without passing via any application validation. 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, a login screen is supposed to validate the users’ credentials 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:
adb shell am start -n {Package Name}/.{Activity Name}
Mitigation
To mitigate this vulnerability, configure all sensitive components in the application as exported=false or without any configuration when the application is updated and the default exported parameter value is 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 do not specify a particular target component and instead declare a general action to be performed, allowing the system to determine 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 https://example.com website to the application with the user’s session token passed in the URL.
Exploiting the vulnerable application can be done by performing the steps below:
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.
领英推荐
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:
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.
Mitigation
To mitigate this vulnerability, sanitize user input using well-known libraries before inserting it into the Content Provider’s query.
Broadcast Receivers
The Broadcast Receivers are used to send and receive event messages called broadcast messages from other applications, the device itself, and more. These messages include various events, from system events like battery level changes to user actions like connecting headphones. If not implemented correctly, several vulnerabilities can occur, leading to unauthorized access and actions as well as the retrieval of sensitive information. In the following scenario, the application uses an exported Broadcast Receiver component to receive information from the device, including checking for battery events and a custom event to check if the user enters the correct message value. Because of the exported attribute, it is possible to exploit the application’s logic and send the value from outside the app.
adb shell am broadcast -a {Broadcast Receiver Path} –es {Parameter Name} {Value}
Mitigation
To mitigate this vulnerability, ensure all Broadcast Receivers are properly secured and not accessible from outside the application. This can be achieved by explicitly defining custom permissions for Broadcast Receivers, thereby restricting 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.
References