Android hacking and security, part 1: Exploiting and securing application components
This is the very first part of Android hacking and security.In this article we will learn about Exploiting and securing application components.
Android hacking and security:
Mobile app security is one of the hottest segments in the security world because security is really a big concern for growing mobile apps.
In this article, we will go through attacks related to Android application components.
What are Android app components?
App components are the basic building blocks of an Android app. Each application is built as a combination of some or all of these components that can be invoked individually. Android has four main components which are explained below.
Activity: An activity provides a screen that users can interact with to do something. Users can perform operations such as calling, sending SMS, etc.
Example: The login screen of your Facebook app.
Service: A service can perform long-running operations in the background and does not provide a user interface.
Example: Playing music
Content providers: A content provider presents data to external applications as one or more tables. In other words, content providers can be thought of as interfaces that connect data in one process to code running in another process.
Example: Using content providers, any app can read SMS from the SMS app’s built-in storage on our device.
*The RED_SMS permission must be specified in the application’s AndroidManifest.xml file to access SMS application data.
Broadcast receivers: A broadcast receiver is a component that responds to broadcast notifications such as low battery, boot completion, headset plug, etc. Although most broadcast receivers originate from the system, applications can also announce broadcasts.
This article focuses on demonstrating the attack methodology and security of vulnerable application Activity components.
Background:
You can download the sample application used in this article and follow the steps along with us.
Fill out the form below to download the APK file and source code.
As shown in the image below, this application has two activities. The first activity takes a password as input. If the user enters the correct password, they will be taken to a page labeled “Private Area”, otherwise they will receive a “Wrong Password” message. For testing purposes, the login password is set to “password”. Ideally, the first screen should use an intent and invoke the second screen if a valid password is entered. We need to do black box testing on this app to see if we can bypass the authentication by directly calling up the welcome screen.
Prerequisites for performing the steps
A computer with the Android SDK installed
A non-rooted mobile device to install the app.
Topics covered:
Collection of information
Attacking vulnerable activity components
Application security
Collection of information
Decompile the app using the APK tool.
Parse the AndroidManifest.xml file for exported activity components.
Every Android app has a package name and every activity has its own class name in the package. The first step is to find out the name of the package and the names of the available sensitive activities. While there are other ways to get this information, looking at AndroidManifest.xml is a good approach. We can get the AndroidManifest.xml file by decompiling the app using APKTOOL.
Download APKTOOL from the link: https://code.google.com/p/android-apktool/downloads/list
Place the test app in the same folder as in APKTOOL.
Now decompile the APK file using the following command as shown in the image:
apktool d testapp.apk
Now we need to find the name of the package and its activities.
All activities will be registered in the AndroidManifest.xml file using tags. So anything inside those tags will be an activity. Looking at the AndroidManifest.xml file we see two activity components and the package name as shown in the image below.
By examining the above image, it is clear that we have obtained the following information about the application.
com.isi.testapp is the package name.
com.isi.testapp.Welcome could be the activity we get after entering the correct password.
Attacking vulnerable activity components
Our task now is to start the welcome activity without entering a password on the first screen.
We can perform attacks on vulnerable activity components in several ways, as shown below.
Running sensitive activities using the Activity Manager Tool.
Using a malicious application to trigger the activities of other applications.
We can also use the Mercury framework to perform these attacks, which we will cover later.
Running sensitive activities using Activity Manager
Activity Manager is a tool that comes pre-installed with Android SDK and can be used along with “adb shell”. This tool can be used to run application activities and services. We can even convey intentions with it.
So, let’s begin.
Connect the device to the computer and get a shell on the device using the following command:
adb shell
To start the welcome activity, enter the following command:
am start –n com.isi.testapp/.Welcome
We should now see the splash screen launch without entering a password.
Using a malicious application to trigger the activities of other applications
Another way to invoke the activities of another application is to write a malicious application and add the name of the package and the activity to be executed. The image below is the code snippet to run the activity where in com.isi.testapp.Welcome is the activity to be run. In our case, the malicious app does not require any permission to run the “Welcome” activity of the vulnerable app.
Using the Mercury framework
The same attack can be reproduced using the Mercury frame. We will discuss the Mercury frames later in this series.
Application component security
- Setting the value of the android:exported attribute to false
- In our app’s AndroidManifest.xml file, we should add the following attribute to the app component to be secured. In our case com.isi.testapp.Welcome
- is an activity to be secured.
The above code restricts access to this activity to other applications or any system component other than the current application. Only apps that have the same user ID as the current app will have access to this activity.
Related articles:IPL Bootkits :Rovnix and Carberp-by Blackhat Pakistan 2023
Restrict access using custom permissions
The android:exported attribute isn’t the only way to limit activity exposure to other apps. We can also impose permission-based restrictions by defining custom permissions for the activity. This is useful if a developer wants to restrict access to their application’s components to applications that have permissions.
Note: The above security controls can be used for any other application component that we discussed at the beginning of the article.
