As a mobile app tester, I have encountered numerous varied vulnerabilities. During one of my mobile engagements, I was able to achieve an Authentication Bypass by simply invoking each exposed Activity component of the Android application. The purpose of this post is to highlight this type of vulnerability that still exists in every Android application. While this type of issue isn’t widespread, understanding how this technique was used can help you understand how certain Android apps can leak critical information that can potentially lead to a compromise or breach.
Android Components
Every Android app has three primary components:
- Activities: Activities are the user interface components that the user sees and interacts with while using the application.
- Services: Services are background processes that handle the underlying operations within the application.
- Broadcast Receivers: Broadcast Receivers are components that listen for system messages or broadcast announcements.
Android Intents
Usually, Activities are called using Intents. An Intent is a messaging object used by the application to communicate with the different components. These components can be Activities, Services, or Broadcast Receivers. Intent Filters are typically defined in the AndroidManifest.xml file within the application. There are two types of Intent Filters:
- Explicit Intents: These Intent Filters detail the application that will satisfy the Intent by providing the target application’s package name or a fully-qualified component class name. Explicit Intents are generally used to start a component within the application itself. For instance, a user trying to download a file within an app would trigger an Activity in the visible app that would start a Service to download a file in the background via Explicit Intent between the Activity and the Service.
- Implicit Intents: These Intents Filters do not name a specific component, but instead declare a general action to perform. This allows a component from another app to handle the component. For example, if the app wants to show a user a specific location on a map it could use an implicit intent to request another capable application to show this location.
When looking for Intents we can take advantage of we first have to examine the AndroidManifest.xml of the application. Every Android application has an AndroidManifest.xml, this is where you can see the important information about your app, such as package name and application ID, permissions, components, and device compatibility. Tools like “Apktool” (https://ibotpeaches.github.io/Apktool/) allow you to pull the manifest from an Android app “apk” file.
The screenshot below shows the AndroidManifest.xml of the app I was auditing. It shows the exported Activities being used in the application. One of the most common problems with Android components is the exported Activities, which often lead to malicious activity, remote code execution, and fake notifications just to name a few.
Figure 1: AndroidManifest.xml
First, here's a brief background about this specific application. The mobile app is an internal messaging app developed specifically for communication within the company. It is designed to connect employees across the organization with the features of one-on-one messaging, group chat, and voice calls. The image below shows the login screen of the application. We will now try to invoke one of the Activities shown in the AndroidManifest.xml in Figure 1, by sending an Intent to the Activity and see what happens.
Figure 2: Login page
We will do this by using a root ADB shell connected to a device running the app and then running the command below. This will execute the Activity that you specified. For example, when looking at the listed Activities, MyChatRoomActivity is a UI that is intended for authenticated users. So, we are going to use MyChatRoomActivity to see if we can access it directly without logging in at all.
adb shell
su
generic_x86:/ $ am start -n com.app.uc/com.app.uc.ui.MyChatRoomActivity
Starting: Intent { cmp=com.app.uc/.ui.MyChatRoomActivity }
After executing the command from a root ADB shell, MyChatRoomActivity led us to the “My groups” chat panel of the app without providing any credentials (see Figure 3. Since this direct authentication bypass occurs by invoking one command which means the application activities do not check for a valid user session.
Figure 3: Logged in with no authentication
Conclusion
By using information contained in the AndroidManifest.xml via an adb shell anyone can explore an Android app for unintended behavior. While the Authentication Bypass here is an extreme example of the type of insecurities that can be found, this technique has been used to find and exploit Android app vulnerabilities for years.
Recommendations
App Developers should only export components that need to be exposed to other applications. This will limit what Activities are exposed in the AndroidManifest.xml. They should also stringently validate all data received in Intents. Where the application expects data to be passed from other applications, consider applying permissions to restrict which applications are allowed to do so. Developers can disable external exposure of any components by specifying android:exported=”false” in the application manifest.
References
https://developer.android.com/guide/topics/manifest/manifest-intro.html#perms
https://cwe.mitre.org/data/definitions/926.html
