Android Application Assessment

Introduction: Mobile applications are gaining popularity day by day as the no. of users with mobile devices is increasing exponentially. Now almost every task performed on PCs could be performed using mobile devices. They are handy, lightweight and can be used on the go. Several mobile technologies are being used these days to develop certain kind of applications ranging from weather information to banking sites. Android, iOS and Blackberrys are amongst most popular mobile platforms today. This paper focuses one of the dominant mobile technologies in the market, ‘Android’. With much acceptance from users and the increasing no. of Android mobile devices, almost every organization is creating their own app for Android platform. Background: Android is developed by Google and is a Linux based platform. It uses its own virtual machine called Dalvik Virtual Machine (DVM) to run .dex files, which is very similar to .class files of Java. This paper discusses the assessment on a Windows machine. The requirements to setup the test bed:

Android SDK tools, from http://developer.android.com/sdk/index.html , which consists of Android avd manager and adk manager

Java 5, 6, or 7

Eclipse for code review purpose

MITM proxy tools, such as Burp to capture communication

We’ll be using an android emulator to test the application instead of a real mobile device. Our strategies for going ahead with the assessment will be based on the following approaches:

Penetration testing

Code review and configuration review

ADB shell

Setting up the environment: Setting up the AVD (android virtual machine) and emulator should not be any issue, as it’s sufficiently written and explained at http://developer.android.com/sdk/index.html . Once the AVD is setup, we can start it by going to Start-> All Programs-> Android SKD tools-> AVD manager or by entering the following command: C:Program FilesAndroidandroid-sdktools>emulator.exe –avd TestAVD It will start as shown in Fig-1. We can create several AVDs using the AVD manager by click on the ‘New’ button and providing a name, size and other inputs to it [Fig-2]. But we have already created our AVD as ‘TestAVD’, as you can see in the Fig-2. Now clicking on the Start button launches the emulator as shown in Fig-3. The emulator is nothing but a soft replica of the mobile device, which functions in the same way as real mobile devices do.

[Figure-1: Android Virtual Device]

[Figure-2: AVD Creation]

[Figure-3: Emulator started] Our next step will be to install the application which needs to be tested. Android applications are in .apk format. Go to C:Program FilesAndroidandroid-sdkplatform-tools or tools, depending on the version of your SDK, and then enter the following command: adb install <path-to-.apk file> This command installs our application in the emulator and we can see it appearing at the screen as shown in Fig -4.

[Figure-4: Installed SecureBank app] Penetration testing the app: In this approach, we’ll be doing penetration testing of the installed application as we do in normal web applications to uncover potential vulnerabilities. Here, the approach is called a black box approach as we don’t know much about the internal structure of the application, such as codes and configurations. We have to capture the communication between the client and server then edit and modify it to observe the server’s response using web proxies such as Burp. Since the application is a web based tool, we can use web proxies. However, in case of a thick client, we need to use other tools for interception such as Echomirage. Configuring the proxy: We need to set up local web proxies (e.g. Burp, Paros) to intercept the traffic by modifying the Internet setting in Android by clicking on Settings->Wireless & Network Settings-> Mobile Networks -> Access Point Names-> Internet-> Proxy Name (PC’s IP address) & Port [Fig-5]. The same settings we need to specify in Burp as well: provide the host IP and port no. as above. Now the proxy should be up and running and successfully captures any request [Fig-6]. Now we launch our application and the proxy captures all the requests/responses to and from the server [Fig-7]. Now while the proxy can intercept the request/responses, the application can be tested as per normal web application penetration techniques to uncover issues like, authentication, authorization, injection flaws, etc…

[Figure-5: Proxy settings for capturing web traffic]

[Figure-6: The proxy is successfully configured and intercepting the communication]

[Figure-7: Intercepting request/ response of the application] Code review and configuration review: Now this way of assessment is done through decompiling it back to source code and do code review. This is also helpful in situations where the application is a native app and doesn’t communicate over HTTP. Decompiling gives you source code and access to configuration files as well, which are the source of permissions assigned to the app. The structure of a sample android app is shown in Fig- 8 (http://securitycompass.com )

[Figure-8] There are couples of other methods of decompiling the .apk file, but this is what I follow and it’s a little easier:

Covert the .apk file into .zip file

Extract the zipped file

Under extracted folder we find classes.dex file along with other files [Fig-9]

The .dex files are Dalvik executable files format, and are not human readable.

So, we need to convert it back to some human eye friendly language. We will use a tool called dex2jar which can be used to convert .dex to JAR files (http://code.google.com/p/dex2jar/ ).

Run the command: dex2jar classes.dex which converts the classes.dex to classes.dex.dex2jar.jar [Figure-10].

Now use any Java Decompiler such as JD (http://java.decompiler.free.fr/?q=jdgui ) to open the JAR file. Now you can review the Java Source Code. You can also save the source files as File> Save All Sources [Figure-11].

Now since it’s in Java source code format, it’s easy to do a code review.

[Figure-9: Decompiled APK file]

[Figure-10: Classes.dex converted to jar file]

[Figure-11: Java source code] Modifying and recompiling back to APK: We can save all the above source codes by Choosing File-> Save All Sources. What we get are Java source codes which may be editable. So suppose we want to make some changes in the source file and pack it back to apk, we need to follow these steps [Fig-12]:

Go to File-> Save all sources

Save the source codes to local folder

Edit the source code as per your wish such as, changing credentials

Now in order to use this changed source code we need to pack it back to apk file:

Replace the older file with modified one in the original folder

Compile the source files to .class and archive them into .jar file

Now the .jar file can be converted back to .dex file by using dx.bat which is available under Android SDK tool, under ‘platform-tools’ folder: dx –dex –output=”c:/classes.dex” “c:/classes.jar”

Replace the above modified classes.dex file in the original apk file.

[Figure-12: Modifying class files] Reviewing the configuration file for permissions: The same extracted folder contains one xml file called AndroidManifest.xml. It contains all the properties settings of the application installed such as, permissions to access other apps, other apps’ permissions to access this app, intents, etc… The problem here is this xml file couldn’t be read easily as normal xml files because this is in binary format. We need a special tool to convert it to a human friendly format. For that purpose, we will use a tool called AXMLPrinter2.jar (http://code.google.com/p/android4me/downloads/detail?name=AXMLPrinter2.jar& ). Once installed enter the following command: java -jar AXMLPrinter2.jar AndroidManifest.xml> AndroidManifest.txt Now it’s easy to review the manifest file [Fig-13]. We can now review the different settings such as permissions to access and to be accessed, services, activities, etc… of the application. Refer to http://developer.android.com/guide/topics/manifest/manifest-intro.html for info on reviewing permissions contained in the AndroidManifest.xml file. We should review the permissions carefully, as what permission the application is requesting and other permissions which this application is granting to other applications on the Android device. Also, check the intent-filter tag, which specifies the types of intents that an activity, service, or broadcast receiver can respond to. There are many other settings which differ based on application to application.

[Figure13: Android Manifest file] Verifying Android app sign: Signing an application provides authenticity assurance, which has come from a reliable source. To verify if the application is signed or not, we can use a java tool found in the bin directory of Java installation, called jarsigner: Enter the following command: jarsigner -verify App.apk If the .apk is signed properly, Jarsigner prints “jar verified” For a more detailed view, enter the following command [Figure-14]: jarsigner -verify -verbose -certs App.apk>details.txt

[Figure-14: Signed components] We may also see the details about the certificate used to sign such as issuer, validity, algorithms, etc [Figure-15]… Enter the following command against the certificate. The certificate is placed under the ‘Meta-INF’ file: keytool -printcert -file MyCert.cer > CertDetails.txt

[Figure-15: Certificate details] Apart from all these methods, a few others also exist, such as using some android based tools- adb. Unleashing the poser of ADB: ADB or Android Debug Bridge is a very powerful tool. It’s a part of the sdk and used for running different commands. But this in itself is a very nice tool for assessment, if used. It has got its own set of commands to explore. We will see couple of them and see how then can be useful.

List down the no. of emulators currently running [Fig-16]:

[Figure-16]

To dump entire system data, we can use the following commands. They could show many interesting security information bits. Enter the following command: adb shell dumpsys

‘Currently running services’ are among the other critical information dumped over the screen [Fig-17]. You may need to see the entire dump. For readability, they should be dumped into a text file.

[Figure-17] adb shell dumpsys ‘Currently running services’ are among the other critical information dumped over the screen [Fig-17]. You may need to see the entire dump. For readability, they should be dumped into a text file.

Now enter the following command: adb shell dumpstate [Fig-18]

[Figure-18]

We can use another command in SQLite3 to query databases used by apps to store tables and data. We can verify to see if any sensitive information such as passwords, credit card numbers, and so on are stored in clear text. Enter the following commands as shown in the following figure [Fig-19]:

[Figure-19: searching for databases] We can choose any the applications listed above and look into its database to find some information. For example, we may be interested to see what info the browser is storing (just for example) [Fig-20]:

[Figure-20: Searching for tables and records under databases and results]

The next command is procrank. It shows the running processes and their respective PIDs [Fig-21]:

[Figure-21: List of processes running]

Another command which is used for discovering system calls made by the process. So for example, if we want to show what system calls the alarm clock makes to the system, we run the following command. We need to provide the process id of the application [Fig-22].

[Figure-22: Strace command in action]

So, in this article we saw several external and inbuilt tools that could be helpful in android penetration testing.

[Figure-18]

[Figure-20: Searching for tables and records under databases and results] [Figure-21: List of processes running] [Figure-22: Strace command in action]