Android Hacking and Security, Part 2: Content Provider Leakage

In the previous article, we discussed how an attacker exploits vulnerable Activity Components and ways to secure them. In this article, we will discuss “Content Provider Leakage.”

What are Content Providers?

As per Google’s inbuilt security model, application data is private to an application, hence it is not possible for an application to access another 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(), and 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 the database of the provider app.

There may be some cases where content providers might not be implemented for sharing data with other apps, or the 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.

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

You can download the sample application used in this article by filling out the form below:

InfoSec File Download

Prerequisites to follow the steps

  • Computer with Android SDK installed
  • A non-rooted mobile device to install the app

Testing the application’s functionality

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

It can be (Read more...)

*** This is a Security Bloggers Network syndicated blog from InfoSec Resources authored by Srinivas. Read the original post at: http://feedproxy.google.com/~r/infosecResources/~3/ydNeoHNcoaY/