Attacking Android Components – Content Providers
In this blog, I’ll be showing you how we can exploit the android component-based content providers’ vulnerability.
What are Content Providers and Why it is used:
Content Provider components visualize access to shared data resources, like local or remote databases. They all have a unique URI for identification.
- Content Provider component supplies data from one application to another application on request.
- You’ll be able to store the data in the file system, an SQLite database, on the web, or any other persistent storage location your app can access.
- Through the content provider, other apps can query or even modify the data (if the content provider allows it).
- It is useful in cases when an app wants to share data with another app.
- It is much similar to databases and has four methods.
For more clarification about content providers follow the Content Provider
Fig 1: Content Provider Flow
I’m using vulnerable Sieve.APK for demonstration purposes. To exploit this vulnerability we need to install drozer into your both devices (Mobile as well as Local System).
What is Drozer:
Drozer (formerly Mercury) is the leading security testing framework for Android. It provides tools to help you use, share, and understand public android exploits. It helps you to deploy a Drozer Agent to a device through exploitation or social engineering. We can read more about this here Drozer.
Let’s get started,
First, we have to decompile this apkto analyze code android manifest.xml file into that we have to check provider exported attributes and URI (android:name=”DBContentProvider” and android:exported=”true”)
Fig 2: Android Manifest.XML
Run drozer after configuring both the devices to find the attack surface parameter.
Fig 3: Drozer attack surface
So, you can see there are two content providers exported found. Now we must check this into the source code of this application.
Fig 4: Source code of DBContentProvider
We can see that in the code there are two URIS used in the application:
Let’s try to query each of them.
Fig 5: DBContentProvider/Keys
So now you can see in the screenshot we have the master password and pin of the App which manages other Apps password.
Let’s try to change the value of Password from “12345678912345test” to “12345678912345content”
Fig 6: Changing Password Done
Now you can see in the screenshot password is updated.
Fig 7: Password Updated
We can also access the password saved in this Password Manager App by query content://com.mwr.example.sieve.DBContentProvider/Passwords exported URI.
Fig 8: DBContentProvider/Passwords
How to Mitigate:
- If you are using the content provider just for your app’s usage then you should set it to be android:exported=false, in the android manifest. If you are intentionally exporting the content provider then you should also specify one or more permissions for reading and writing data.
- If you are using a content provider for sharing data between only your own apps, it is preferable to use the android: protection level attribute set to “signature” protection.
- When accessing a content provider, use parameterized query methods such as query(), update(), and delete() to avoid potential SQL injection from untrusted sources.
Attack & Pentest Team
Varutra Consulting Pvt. Ltd.