Debugging Android Applications

Debug Flag

In Android you can set a flag in the manifest file to tell the OS whether or not an application can be debugged. This flag is commonly set to true during the development process, if the flag is still set to true in production then this can be dangerous and can lead to insecurities such as sensitive file exposure 

 The attribute in the <application> element in the manifest file will look like this  -    

 android:debuggable["true"|"false"]

Checking Application Debug Flag

During a security review it is important to check if the application has debuggable="true". Fortunately, there is a module in drozer that will do the work for us. In order to check all the application packages on the device run the command below. As you can see the insecure bank application has debuggable on.

To see which applications are active and connected to the debugging socket (@jdwp-control) you can run the 'adb jdwp' command below.

The jdwp command gives us a list of PIDs of processes that can be debugged. We can find out what packages the PIDs are mapped to by using ps and grep commands. You can see below that we can debug the insecure bank application.

Exploiting Debuggable Applications

So what can we do now? We know that the application is debuggable but we don't have root on the device. You may or may not know that if the device is not rooted then you cannot access the private data of the application. If you do try and root the device and it has an MDM policy applied preventing root exploitation then the device may get quarantined.

 No problem ;). We can use run-as, this binary allows you to execute commands in the shell with the same permissions  owned by the app, basically you are placed inside the applications private data directory.

It is now possible to run any command to view or query the data. The command below shows the databases in insecure bank.

So lets pull back some data from the insecure bank application. Using run-as and sqlite3 we can query the applications database. We can use .tables to list all of the available tables 

Now lets dump the data in the names table, you can use .dump. You can also use "select * from names" instead of .dump to query the table.

Hopefully this demonstrates why it is important to set debuggable="false" before deploying to production.

Introduction - Reverse Engineering Android Applications

Reversing APK Files

The first step in the reverse engineering process is to retrieve the APK file. If the application is on the device and it has adb access you can run the command below to list all of the packages on the device. If you know the name of the application you can use grep to look for the specific application, in this case insecurebank.

To pull the application from the device you need to get the full path name of the APK file for the package.

Once you know the path you can run 'adb pull to retrieve the APK from the device.

Now that you have the APK file you can rename the file extension as a zip file and use the unzip command to decompress.

Building Android Applications

Developers create Android applications in the Java programming language. These files are then compiled into .class files. The class files are then given to the dx tool in order to generate .dex files.

These .dex files are then packaged as an APK with other files.

The classes compiled in dex format are understood by the Dalvik Virtual Machine and allows the application to be executed during runtime. Each application running on an Android device has its own Dalvik Virtual Machine

Decompiling Dex Files

In order to decompile the application we need to locate the classes.dex file, we want to convert this back into a Java JAR file. In Appie you can use the 'd2j-dex2jar classes.dex' command to convert.

The JAR file can now be decompiled into Java source code using JD-GUI.

Analyzing The Code

You can now go through the various classes to analyze the application logic, identify sensitive information etc. In the example below we can see the DoLogin class has a hardcoded developer backdoor.

If you login with the username - devadmin without a password it will give you access to the application.

We can confirm that the username 'devadmin' has allowed us to access the application.

The page below is the landing page post-authentication.

References: http://resources.infosecinstitute.com/android-hacking-and-security-part-18-introduction-to-reverse-engineering/

Android Unintended Data Leakage

Unintended data leakage occurs when a developer places sensitive information or data in a location that is easily accessible by other apps on the device.

Android Logs

Logging functionality is used for debugging purposes during development. Android has a class called Log that can be used from within the application to place debug information in a central log. Up until Android 4.1 Jelly Bean applications with the READ_LOGS permission could access log entries from other applications. Therefore any application running on a device that has a version below 4.1 or is rooted is still vulnerable.

This tutorial will demonstrate how sensitive information can be leaked via Android logs. For this demo I will use Insecure Bank, this application contains a number of Android vulnerabilities, if you want to find out how to install click on the link here

Once you have the app setup you should see a login page similar to below. The login credentials to access the app are:

• dinesh/Dinesh@123$
• jack/Jack@123$

Prior to logging in we want try and capture any sensitive information. There are a number of ways of doing this, you can use the logcat option in the Eclipse IDE or adb logcat. A very useful script that comes packaged in Appie is PID Cat, this script filters the logs by application package making it easier to identify information coming from that particular application.

In Appie simply type pidcat com.android.insecurebankv2 (package name). Then log in with the credentials above, you should now see the same credentials displayed in the log.

Another example using the insecure bank application is on the transfer amounts page. You can click on the 'Get Accounts' button and then enter an amount to transfer.

Once you hit the transfer button, the accounts and logs will show up on PID Cat. Again this could be read by other applications.

Logging is an essential feature during development but can inadvertently expose sensitive information. Although it seems trivial, it can lead to serious risk depending on the data that is leaked.

Clipboard Leakage

Another area were sensitive data leakage can occur is from the clipboard. Users tend to copy/paste quite a lot on mobile devices as its easier than typing. If the application allows for the copy/paste of sensitive information from one app to another then it is possible that a malicious application could read it also.

If you take the example below from Insecure Bank, the user can copy out transfer statement information.

We can then use the post-exploitation module in drozer to read the clipboard. To install this module type 'module install clipboard'. Then run the command below

References: https://www.owasp.org/index.php/Mobile_Top_10_2014-M4
                    https://github.com/dineshshetty/Android-InsecureBankv2
                    https://manifestsecurity.com/appie/

Android Insecure Data Storage

Insecure Data Storage

One of the biggest concerns for mobile device and application is loss or theft. If a  malicious user obtains a device then it is possible to explore the filesystem and data storage mechanisms.

For this tutorial we will use Appie and the GoatDroid Project. You can install the apk file on your device or emulator. To start the app using Appie simply type 'goatdroid'.

The GoatDroid interface should open up, you can select either of the two apps on the left hand-side, for this tutorial we will use Four Goats. In the main pane select 'start web service'.

Run the ipconfig command on your Appie instance to identify the IP address of your local machine.

Open up the Four Goats application on the device or emulator. Select 'Destination Info' from the dropdown menu, on this page enter the IP address of your local machine, the default port can remain the same.

You should now be able to login to the Four Goats application with goatdroid/goatdroid.

If successful you will see a page similar to below.

In Android application data resides in the /data/data folder. In order to access this folder type 'adb shell' in the Appie command prompt, then SU to get root privilege. Then type 'cd /data/data' to get to the folder, you will see a list of packages. 

Locate the Four Goats package -  org.owasp.goatdroid.fourgoats

Navigate to the shared_prefs folder, you will see a number of files. An obviously interesting file is credentials.xml, use the cat command to view the contents. You can see that the username-password pair is stored unencrypted in this file.

Android Best Practices - OWASP 

• For local storage the enterprise android device administration API can be used to force encryption to local file-stores using “setStorageEncryption”
• For SD Card Storage some security can be achieved via the ‘javax.crypto’ library. You have a few options, but an easy one is simply to encrypt any plain text data with a master password and AES 128.
• Ensure any shared preferences properties are NOT MODE_WORLD_READABLE unless explicitly required for information sharing between apps.
• Avoid exclusively relying upon hardcoded encryption or decryption keys when storing sensitive information assets.
• Consider providing an additional layer of encryption beyond any default encryption mechanisms provided by the operating system.

Android Hacking - Insecure Content Providers

Content Providers

In this post we will look at an example of an insecure content provider in the Sieve application. Content Providers act as an interface for sharing data between applications. Each content provider has a URI that begins with content://

This allows other applications that the know the URI to perform functions on the data such as insert(), query(), update() or delete(). If the content provider permission is not set correctly in the manifest.xml file then it can lead to sensitive data leakage.

Analyzing Insecure Content Providers

As we have seen in the previous post, the Sieve application  has 2 content providers exported.

We can run the app.provider.info -a command on the Sieve application to retrieve further information. The output reveals that there are two content providers DBContentProvider and FileBackupProvider that do not have any permissions assigned for read/write access. However it does reveal that the DBContentProvider/Keys path requires permissions to read/write.

Another method for returning content:// URIs is the finduri module. This can reveal other sensitive paths, in the screenshot below you can see a /Passwords path.

If we try to query it using app.provider.query it returns a password table containing sensitive information including passwords in base64.

This is a good example of how unprotected content providers can reveal sensitive information.

SQL Injection Issues 

Another associated insecurity with content providers is SQL Injection. Content providers are commonly connected to SQLite databases. Therefore if the data has not been suitably sanitized then SQL commands can be injected in order to return information.

There are a number of ways of identifying and exploiting SQLi using Drozer. You can manually inject SQL queries via the app.provider.query or by scanner.provider.injection modules.

It is also possible to use existing tools in conjunction with Drozer modules. In the example below we will use auxiliary.webcontentresolver - this module offers a web service interface to all installed content providers. This then allows us to use sqlmap to exploit.

Drozer and SQLmap

The first thing to do is start the module and select a specified port.

Next navigate to http://localhost:1234 in your browser. You should see a list of content providers on the web page.

If you select the DBContentProvider/Passwords URI, you can then start to manipulate any parameters that are passed through the web interface to the back-end services. The example below shows an SQL error being returned by injecting a quote into the projection parameter.

We can fire up SQLmap and query the URI. The command below takes the URI and tries to manipulate the projection parameter in order to return the tables.

The results show 3 tables have been returned from the SQLite_masterdb.

Finally we can dump the contents of the Passwords database.

References: https://labs.mwrinfosecurity.com/tools/webcontentresolver/
                    http://sqlmap.org/
                    http://blog.mdsec.co.uk/2015/02/the-mobile-application-hackers-handbook.html

Analyzing Android Applications Using Drozer

Before we start analyzing Android applications we need to understand the different aspects of the Android architecture.

Android applications communicate with each other using an IPC (Inter-Process Communication) kernel module known as binder. The applications can make use of four components that can be invoked via calls to binder.

 Android Components

• Activities - An activity represents a single screen with a user interface. An example of an activity would be a login page.
• Services - A service is a component that runs in the background to perform long-running operations, it does not provide a UI. An example of a service might be music playing in the background while the user is in a different application.
• Broadcast Receivers - A broadcast receiver is a component that responds to system-wide broadcast announcements. A broadcast may announce that the battery is low or a picture was captured. Apps can also initiate broadcasts - for example to let other apps know that some data has been downloaded to the device and is available for them to use.
• Content Providers - A content provider supplies data from one application to others on request. You can store data in the file system, an SQLite database or any other persistent storage location the app can access.

Defining Components

Each Android Package contains a file named AndroidManifest.xml. This file contains various information such as the minimum Android version and the list of activities, services, broadcast receivers and content providers. Only components defined in the manifest file are usable within the application, the one exception are broadcast receivers.

One of the important aspects of securing components in the manifest is to use strongly configured permissions. 

In Android a component is public when exported is set to true but it is also public if the manifest specifies an intent filter for it.

Attacking Components

In this tutorial we will use Drozer to analyze an Android application to determine what components are exported and if so how they can be attacked.

We will use a deliberately vulnerable Android application created by MWR InfoSecurity called Sieve . Sieve is a password manager that allows a user to save passwords and makes use of a master password and pin to encrypt the passwords in the database. 

Analyzing the Manifest File

After you install the application you can find the package name of the application by running the command below

Drozer allows for examination of the manifest file, the command below returns the whole manifest file

An easier way to check for exported components is to run the command below. We can see that there are 3 activities,2 content providers and 2 services exported. 

Exploiting Activities

As mentioned earlier activities are individual user interfaces. Developers need to be careful when defining the activities to be exported in the manifest file. The Sieve application demonstrates how the application authentication page can be bypassed due to a misconfigured activity.

We have determined that 3 activities have been exported, run the command below to identify the pages.

When a user opens the Sieve application they must enter a master password and pin via the authentication page. We can try to bypass this page (MainLoginActivity) by calling one of the other activities. We can try to invoke the other activities using drozer.

By invoking this activity we have bypassed the authentication page without having to enter a password or pin.