We all know our smartphones contain a lot of sensitive information about us, from credit card details through WhatsApp correspondence, our location, pictures and more.
Today we see serious development of the telephony field; banks and credit card companies are developing account management telephone applications, chat applications which hold a history of our conversations, and much more important information of ours is managed by the smartphone.
The Android operating system (OS) architecture allows the programmer to broadly manage the information; to create components which are accessible to other applications on the device, to save data in dangerous locations and so information can easily be managed incorrectly. In addition, many programmers who have always developed server-side applications are now faced with the need to develop client-side applications and are not aware of the possible risk – which, in turn, increases the known attacking surface available to the attacker.
When a tester performs a penetration test to an Android application, it is divided into to two main areas:
- Client-Side Attacks – include client-side vulnerabilities such as saving sensitive information in a dangerous manner, saving passwords in the code, manipulation of activities, broadcast receivers, etc.
- Server-Side Attacks – include applicative server-side vulnerabilities such as XSS, SQLi, Authorization Bypass, Authentication Bypass, etc.
It is possible to write an entire thesis on each of these, and so in this article I will focus only on the way the attacker can receive the most information about the server-side through the Android application, on how he can use this information and demonstrate how was attack the application’s server-side using another application. In addition, sometimes we discover web services that are only for mobile applications and this is the only way to find them.
To understand this article, basic knowledge of Android applications or work experience with the emulator is required.
If a deeper explanation is required about the different techniques, threats and/or mitigation methods, we (AppSec Labs) regularly teach courses on Android application hacking and on Android secure coding. For more information, please email us: email@example.com.
Setting Up a Work Environment
In order to carry out a penetration test on an Android application, a tester will use the Android SDK, which contains the Android emulator which performs full emulation on the Android OS. In addition, there are many powerful tools which help in performing the application penetration test such as:
- And many more…
AppUse – an Android Work Environment
AppSec Labs has developed a tool called AppUse. AppUse is a Virtual Machine (VM) which provides the tester with a pre-configured environment containing all of the necessary tools. We have added scripts and adaptations which save the tester a lot of time during the test. In addition, the AppUse Dashboard enables simple and fast activation of the tools, making the testes work substantially more efficient! I strongly recommend that everyone who works in this field downloads AppUse from the following address: https://appsec-labs.com/AppUse
In this article I will explain how to carry out a server-side attach using the AppUse dashboard, as well as manually by using the relevant tools.
A Little About the Emulator
The emulator, as its name suggests, does exactly that – it emulates the Android OS. It was created in order to enable the development and testing of applications without the physical need for a smartphone.
The emulator comes with a number of tools which allow different actions, I won’t go over each of them, but there are many sources which explain about each of them:
- Emulator – http://developer.android.com/tools/help/emulator.html
- ADB – http://developer.android.com/tools/help/adb.html
Stages of the Attack
The server-side attack of the Android application is made up of a number of stages:
- Achieving the target application – how does the attacker achieve the designated application? What are the steps required to do so?
- Android manifest – what can the attacker learn from the manifest file of the attacked application?
- Decompiling APK and investigating the code – how does one decompile and application? And how will we research the code to collect important data (which server does the application communicate with? Through which port?)
- Intercepting the proxy transport – what options does the attacker have to intercept the proxy transport?
- Exploiting the existing server-side vulnerability – once the transport has been intercepted, an example of detection of an applicative vulnerability and an explanation of how we can take advantage of it.
Reaching the Target Application
The tester has a number of options when it comes to reaching the targeted application:
- Reaching the application through its name or package name from Google Play – if the application is available on Google Play, it is possible to download it to an actual device or to use websites which enable downloading the APK directly from Google Play (these services can be used in the AppUse dashboard by clicking the button located at Tools > Download APK from Google Play), such as:
- Reaching the application which is already installed on a device – if the application is installed on an available device, the tester can invoke the application from the device.
The ADB tool which comes with the SDK enables the tester to interact with the emulator. A number of important commands and an explanation of each of them can be found here:
I will assume that the readers of this article already know how to use standard commands such as ADB shell/pull/push.
In addition, it is important to note that the Android OS contains two types of applications:
- User applications – the normal applications we all download and install from Google Play, such as bank applications which allow the user to manage his account. These applications are located in the /data/app/ folder.
- System applications – the ROM applications, which are in charge of the complete function of the ROM. These applications usually have higher permissions and cannot be deleted, such as the SystemUI application which presents the user with the OS GUI. These application are located in the /system/app folder.
Initial Diagnosis and Research – Android Manifest
Every Android application contains a manifest file in XML format called AndroidManifest.xml.
The manifest file contains a lot of information about the application, such as the application name (package name), a list of the system components (activities, broadcast receivers, and content providers), a permission-usage statement, a personal permission statement, and more. In order to view an applications’ manifest file we need to use decoding tools on the application files. The two most common tools are apktool and apkparser:
To view the manifest using apktool we will use the following command:
apktool decode <apk name>
Then, a folder with the APK name will be created, from which we will access the AndroidManifest.xml file.
To view the manifest using apkparser we will use the following command:
java -jar APKParser.jar <apk name>
If we would like to export the manifest to a file and view it in the browser, we can use the command:
java -jar APKParser.jar APK_NAME.apk > AndroidManifest.xml
The easiest way to view the application manifest is using AppUse, by loading the APK into AppUse using the Load APK button, and clicking View Manifest under the Reversing section:
The manifest file can teach us a lot about the application, it provides the attacker a lot of information about the application without performing any complex actions.
The following image shows a part of the manifest file for the HackMePal application (a hack-me application developed by AppSec Labs for tests and exercise, which simulates a rich environment for credit and financial transactions):
Viewing the above image shows us that the application uses permissions to access the internet and to read and write files to the SDCard. We can see this by reading the permissions the application is requesting with the uses-permission tag. We can also see that it has two exported activities (which can be activated through other applications), which can pose an information security threat because malicious applications will be able to communicate with the application’s activities and perform different attacks. As we can see, we do receive a lot of information from the application.
As stated, the application uses internet permissions, which means it can communicate with an external server. If the application hadn’t used this permission, we couldn’t perform server-side attacks because it wouldn’t exist. In other words, the existence of this permission teaches us that there probably is a server-side.
Once we have confirmed that the application seemingly does communicate with an external server, we will want to intercept its traffic, in order to manipulate the incoming and outgoing requests. There are a number of options to do this by diverting the traffic through a proxy.
The Android OS provides a very limited built-in proxy service, and so a number of proxy applications have been created for rooted devices. A very well-known application is ProxyDroid, which provides the user with the ability to easily and conveniently configure proxy settings on the device.
As you can see, the HOST (the proxy IP address) is 10.0.2.2 – this address shows the emulator its host address (the computer from which the emulator is running).
In addition, you can see that the application cannot configure the transport in specific ports which will be redirected to the proxy, the set ports are 443 and 80. This means that if we want to intercept traffic originating from a different port, we will not be able to use this application to do so. Also, this application only supports HTTP protocols and does not support binary protocols, so we will not be particularly effective.
Once we activate the proxy server (for example, Burp Suite) and switch on the ProxyDroid proxy in order to intercept the traffic from the emulator to Burp, we will try to login with the HackMePal application (admin/admin) in order to catch the login request and manipulate it.
The following image shows that we successfully logged in (bottom-right square) although Burp is configured to intercept the requests (rectangle in the left image) and that the ProxyDroid is properly configured (cloud shape in the top right square):
This helps us conclude that the application does not communicate with the server through port 443 or 80, but through a different port which isn’t supported by ProxyDroid.
There are two issues we need to investigate:
- Which port does the application communicate with the server through?
- How can we instruct the emulator to redirect requests to proxy on specific ports?
We will start with the first issue.
Diagnosis and Investigation of the Application Code
Every Android application contains a classes.dex file. After writing the Java code and compiling the code to bytecode, it is converted into a code which the JVM (Java Virtual Machine) recognizes in .class format.
When writing an Android application, this code is converted to a file which the Dalvik recognizes in .dex format, in order to run on an Android device. This file contains the entire application’s code and the actual application logic.
In order to view the source code we will need to perform a number of actions; we will extract the classes.dex file, which contains the application’s Java code, from the APK. Then, we will convert the .dex file to a .jar file and decompile it using existing tools which can return a readable source code in .jar files – which will provide us with a code that is very similar to the application’s source code.
In order to extract and convert the classes.dex file to .jar format, we will use the dex2jar tool:
unzip <apk name> classes.dex
Now we have access to the application’s source code. The fact that an attacker can reach the application’s source code exposes him to a lot of information about the application and its functionality such as passwords stored in the code, which files the application writes to and what it writes, how and where it saves sensitive data and access to the components which are dynamically written into the code and are not in the manifest (for example, dynamic broadcast receiver).
Having investigated and explored the code, we can see that the tested application communicates through port 6543:
Now that we know which port that application communicates through, we can get on to the second matter.
When we came across the problem, that the ProxyDroid doesn’t intercept transport other than to ports 443 and 80, we tried searching for a different tool which does with no success. So, we built a tool ourselves. The AppUse application, which is installed in AppUse, currently does not have a GUI and it allows the user to configure the proxy and which ports will be redirected to it from the dashboard. The following image shows the proxy settings screen in the dashboard. As you can see, the redirection ports can be configured through a comma-separated port list:
Now we have added the required port to the list and entered our proxy details, we will root the device by clicking the Root Device button in the Android Device section (since a rooted device is a prerequisite for proxy activation). Next, we will activate the proxy on the emulator by clicking the Proxy is Off button. We will try to connect to our application; in doing so we will be able to intercept the request and manipulate it.
Exploiting Server-Side Vulnerabilities
Once we successfully redirected the traffic to our proxy, it is time to manipulate requests that are sent from the client to the server-side and we can attempt server-side attacks such as:
- Authentication/Authorization bypass
- Parameter tampering
- DoS attacks
- And more…
I will only give one example of exploiting a vulnerability and will not go into too much detail because I don’t want to discuss the different attacks, but simply to demonstrate how to reach a situation in which we can attack the server-side.
After investigating the requests leaving the application, we can see the following request when opening a private chat window for the application user:
As you can see, the application sends a request to the server to receive the chat history for the two users. You can see that the current user’s username and his chat-buddy are sent as parameters to the server (ids=peter,fids=appsec).
The structure of the request leads us to the quick conclusion that it is likely there is a vulnerability and we will try to manipulate the parameters in order to get around the authorization mechanism and view chats from other users in the system.
We will change the username parameter values and try to see a chat between user admin and user david, and we will see if the server enforces an authorization mechanism:
As you can see from the above image, the server responded and supplied us with the message history between adminand david, so we figured out that either the application does not enforce an authorization mechanism, or that we simply managed to override it :).
It is important to point out that the above example is a part of the HackMePal application, which was designed to be as vulnerable as possible to attacks by AppSec Labs. Having said that, I have come across similar situations in a lot of the many penetration testing I performed. This is likely due to the fact that the developers were not aware of this and hadn’t taken into account that the data received by their application could be tampered with by an attacker, a basic assumption which is completely wrong in the field of application security.
To sum up, in this article I explained all of the stages an attacker performs when performing server-side attacks from an Android application. I explained how we reach the targeted application and confirm it communicates with an external server by exploring the manifest, how we obtain the application code and investigate it, what the disadvantages are of the Android proxy and how we configure it correctly.
Attackers and testers coming from the applicative world and try to perform server-side attacks through a mobile application understand that performing a server-side attack from the application isn’t always easy, as demonstrated.
I strongly advise that anyone performing or trying to get into the world of Android application security uses AppUse. This is a strong platform, often updated, which will save a lot of time in handling and performing tests on Android applications.
Link to AppUse: https://appsec-labs.com/AppUse