Android components are the building blocks for Android mobile applications; activities, for example, are used for creating the application’s user interface and a rich user experience (every screen in an Android application is an activity).
Components, however, are not only for building the application’s UI, but mainly for the purpose of process and inter-process communication (IPC), that is, for communication and data exchange within the application itself and with other applications as well.
There are four main components in the Android development environment: activities, content providers, broadcast receivers and services, each one with their own purpose and characteristics.
For now we will focus Android activities, suppose you have the following target application:
Once the application has been installed and, when running, you would see a login activity like the shown below:
Static code analysis
With the apk target application at hand, we proceed to reverse engineer the application, we first use apktool to extract and decode the application resources (which are put into a folder named equally to the apk file name minus the ‘apk’):
The AndroidManifest.xml, for instance, is one of the most important resources to inspect and analyze, since it is the main application configuration file:
We can see (and take note) of important information like the application package name as well as the components defined for this application, in this case we have three activities, one service, one provider and one receiver, but, we will be focusing on the activities, specifically on SendSMS.
We also note that these components are exported (they either have an <intent-filter> or the exported flag is set to true – android:exported=”true”).
We now disassemble the application code using d2j-dex2jar, which converts .dex executable files into .jar files.
With the .jar file ready, we now decompile the code using a java decompiler, in this case we are using jd-gui. After decompilation, if we wanted, for example, to analyze the code of the SendSMS activity, we would look for com.example.root.mobilesec.SendSMS in the decompiled code:
Going through the code we can see the onCreate() method (which is called whenever an intent is sent to an activity). We start by analyzing the code and note that the activity receives two extra parameters (phoneNo and message), which are then sent to the sendSMSMessage(…) as parameters:
The sendSMSMessage(…) method takes a phone number and a message as parameters to then use the SmsManager class to actually send the message. This can be abused by any application installed in the same device that wants to send SMS messages for their own benefit.
Exploiting the activity with drozer
Drozer is a great framework for these kind of situations, it is security tool for assessing Android applications and it comes in two parts; the drozer agent (installed on the Android device) and the drozer console client (installed on the workstation). Click the link below if you want to learn more about drozer.
This article describes basic steps to setup, install and use the drozer framework to identify possible vulnerabilities on Android-based applications. … Continue reading
Once both parts of drozer are setup, you should be able to connect to the agent from the workstation using the next command:
# drozer console connect
Before, when we decoded the AndroidManifest.xml file with apktool, we noted that the package name is com.example.root.mobilesec, now we are going to use that information within drozer. You would execute a command like the one below to find the applications attack surface:
dz> run app.package.attacksurface com.example.root.mobilesec
We can see there are several exported components (to attack a component with this approach, the component needs to be exported). For now we are going to focus on activities, so, we run the next command:
dz> run app.activity.info -a com.example.root.mobilesec
By fetching the activity info we can get a list of exported activities and we can see out target activity in the list. During static code analysis we found that the activity receives two extra parameters (phoneNo and message).
To exploit this user drozer, you would execute a command like the shown below in the drozer console:
dz> run app.activity.start -component com.example.root.mobilesec
com.example.root.mobilesec.SendSMS --extra string phoneNo 5555555
--extra string message "My Message"
*Note: extra parameters are in the form of <type> <key> <value>
The above command will send an intent to the specified activity as well as the required extra parameters. This will execute the onCreate(…) method, extract the parameters and call SendSMSMessage(…) passing the provided values as parameters. Check the below video for a demonstration:
Recent Comments