Test

Powered by Blogger.

Friday 21 November 2014

Pentesting of Content providers in Android apps


What are content Providers?

As per Google's inbuilt security model, Application data is private to an application and hence it is not possible for an application to access other application's data by default. When applications want to share their data with other applications, Content Provider is a way which acts as an interface for sharing data between applications. Content providers use standard insert(), query(), update(), delete() methods to access application data. A special form of URI which starts with "content://" is assigned to each content provider. Any app which knows this URI can insert, update, delete and query data from database of the provider app. 

There may be some cases where content providers might not be implemented for sharing data with other apps, or developer may want to give access only to those apps which have proper permissions. In such cases, if proper security controls are not enforced in the app, that leads to leakage of information.

   

Inbuilt SMS application in Android devices is a classic example of content providers. Any app can query the inbox from the device using it's URI content://sms/inbox.   But, READ_SMS permission must be declared in the app's AndroidManifest.xml file in order to access SMS app's data.

Prerequisites to follow the steps:

Computer with Android SDK Installed

A Non Rooted mobile device to install the app.

Test Application's functionality:

Once after downloading the test application, install it in the non rooted android device in order to test and exploit it. 

It can be installed with adb using the following command

adb install <name of the apk>.apk

It has a feature to store data inside the application. When we launch it, it appears as shown in the figure. 

The Goal is to find out if there are any content providers implemented in this app and if YES, We need to check and exploit if they are vulnerable to data leakage.

Topics Involved:

Information gathering

Attacking Vulnerable Content Providers

Securing the applications

Information gathering

Like any other pentest, let's start with information gathering. We assume that we have the APK file with us. So, decompile the downloaded apk file as shown in the previous article and check AndroidManifest.xml file for any registered content providers. We should also check the smali files for all the URIs used in the app.

Content Providers are generally registered in AndroidManifest.xml file in the following format.

So let's go ahead and examine the manifest file.

We got one content provider registered in the AndroidManifest.xml file and good news is, it is exported to be accessed by all other apps. 

Attacking Vulnerable Content Providers

This is the most interesting part. Let's now try to query the content provider we found. If it returns any data, then it is vulnerable. This can be done in multiple ways.

1. Using adb shell

2. Using a Malicious app to query

3. Using Mercury Framework

Using adb:

To query the content provider from adb, the app should be installed on the device. 

Get an adb shell on the device and type the following command to query the content provider. In my case, I am going to query the URI I found in MyProvider.smali file which is extracted by APK tool.

Content –query –uri content://com.isi.contentprovider.MyProvider/udetails

We should now see all the details stored into the app's db as show in the figure below.





Using a Malicious app to query:

We can even write a malicious app to query the data from its content provider. Following is the code snippet to query the inbox from a mobile device. 


Using Mercury Framework:

The entire process can be carried out using Mercury framework in even more efficient and simple way.

Securing the Applications:

1. Setting android:exported attribute's value to false:

In the AndroidManifest.xml file of our application, we should add the following attribute to the content provider to be secured. In our case com.isi.contentprovider.MyProvider is the content provider.

If we try to query the content provider whose android:exported value is set to false, it will throw an exception as shown below.

Note: The Default value of android:exported is true for all the applications using API Level lower than 17.

2. Limiting access with custom permissions

We can also impose permission-based restrictions by defining custom permissions for an activity. This is helpful if the developer wants to limit the access to his app's components to those apps which have permissions.

Other issues with Content Providers:

SQL Injection: If security controls are not properly implemented, content providers can lead to Client Side attacks like SQL Injection. This works similar to traditional SQL Injection attacks.

Path Traversal: This is one more attack which can be carried out, if a content provider is not properly implemented. This is similar to the path traversal attacks on Web Applications. It allows an attacker to traverse and view the local file system. Sensitive files can be transferred from the device to the local machine using an app vulnerable to Path Traversal attack.

No comments:

Post a Comment

RSS

Categories

Followers

Blog Archive

Friday 21 November 2014

Pentesting of Content providers in Android apps


What are content Providers?

As per Google's inbuilt security model, Application data is private to an application and hence it is not possible for an application to access other application's data by default. When applications want to share their data with other applications, Content Provider is a way which acts as an interface for sharing data between applications. Content providers use standard insert(), query(), update(), delete() methods to access application data. A special form of URI which starts with "content://" is assigned to each content provider. Any app which knows this URI can insert, update, delete and query data from database of the provider app. 

There may be some cases where content providers might not be implemented for sharing data with other apps, or developer may want to give access only to those apps which have proper permissions. In such cases, if proper security controls are not enforced in the app, that leads to leakage of information.

   

Inbuilt SMS application in Android devices is a classic example of content providers. Any app can query the inbox from the device using it's URI content://sms/inbox.   But, READ_SMS permission must be declared in the app's AndroidManifest.xml file in order to access SMS app's data.

Prerequisites to follow the steps:

Computer with Android SDK Installed

A Non Rooted mobile device to install the app.

Test Application's functionality:

Once after downloading the test application, install it in the non rooted android device in order to test and exploit it. 

It can be installed with adb using the following command

adb install <name of the apk>.apk

It has a feature to store data inside the application. When we launch it, it appears as shown in the figure. 

The Goal is to find out if there are any content providers implemented in this app and if YES, We need to check and exploit if they are vulnerable to data leakage.

Topics Involved:

Information gathering

Attacking Vulnerable Content Providers

Securing the applications

Information gathering

Like any other pentest, let's start with information gathering. We assume that we have the APK file with us. So, decompile the downloaded apk file as shown in the previous article and check AndroidManifest.xml file for any registered content providers. We should also check the smali files for all the URIs used in the app.

Content Providers are generally registered in AndroidManifest.xml file in the following format.

So let's go ahead and examine the manifest file.

We got one content provider registered in the AndroidManifest.xml file and good news is, it is exported to be accessed by all other apps. 

Attacking Vulnerable Content Providers

This is the most interesting part. Let's now try to query the content provider we found. If it returns any data, then it is vulnerable. This can be done in multiple ways.

1. Using adb shell

2. Using a Malicious app to query

3. Using Mercury Framework

Using adb:

To query the content provider from adb, the app should be installed on the device. 

Get an adb shell on the device and type the following command to query the content provider. In my case, I am going to query the URI I found in MyProvider.smali file which is extracted by APK tool.

Content –query –uri content://com.isi.contentprovider.MyProvider/udetails

We should now see all the details stored into the app's db as show in the figure below.





Using a Malicious app to query:

We can even write a malicious app to query the data from its content provider. Following is the code snippet to query the inbox from a mobile device. 


Using Mercury Framework:

The entire process can be carried out using Mercury framework in even more efficient and simple way.

Securing the Applications:

1. Setting android:exported attribute's value to false:

In the AndroidManifest.xml file of our application, we should add the following attribute to the content provider to be secured. In our case com.isi.contentprovider.MyProvider is the content provider.

If we try to query the content provider whose android:exported value is set to false, it will throw an exception as shown below.

Note: The Default value of android:exported is true for all the applications using API Level lower than 17.

2. Limiting access with custom permissions

We can also impose permission-based restrictions by defining custom permissions for an activity. This is helpful if the developer wants to limit the access to his app's components to those apps which have permissions.

Other issues with Content Providers:

SQL Injection: If security controls are not properly implemented, content providers can lead to Client Side attacks like SQL Injection. This works similar to traditional SQL Injection attacks.

Path Traversal: This is one more attack which can be carried out, if a content provider is not properly implemented. This is similar to the path traversal attacks on Web Applications. It allows an attacker to traverse and view the local file system. Sensitive files can be transferred from the device to the local machine using an app vulnerable to Path Traversal attack.

No comments:

Post a Comment