Once you've found a URI, you'd query using the commands detailed in the previous recipe, namely:

run app.provider.info –-permission null
run app.provider.finduri [package]

The preceding commands will give you some pretty useful URIs to target; you can then execute the following command to extract some data:

dz> run app.provider.query [URI]

The following is a simple example; the drozer help documents about a lot of the content-provider-related scripts use this very example:

dz> run app.provider.query content://settings/secure

Here's an example from a sample vulnerable content provider. In this example, the attacker uses drozer-extracted information about a user's banking transactions; see the following screenshot for the output from the query command:

Some content providers support the querying of files, especially those of file-manager-type applications. If the content provider makes no restrictions over the kinds of files and paths that applications are allowed to read from, it means that the attacker may be able to either perform the path traversal of directories outside the files that the content provider actually intends to offer or in many cases, allow attackers to extract files from sensitive directories on the victim's device. To extract files, you can use the following command:

dz> run app.provider.download [URI]

In the preceding command, URI would be the URI to the file that you want to extract from the content provider. If there is no protection or filtering of input performed in the actual implementation of the part of the content provider that handles these kinds of queries, you could inject file paths and abuse the lack of protection to enumerate files and files' contents in other areas of the device's filesystem; you would do this by trying different file paths as follows:

dz> run app.provider.download content://[valid-URI]/../../[other file path]    [local-path]

In the preceding command, [valid-URI] would be a URI that the vulnerable content provider has authority over or has been registered to handle, [other file path] would be the path to the file you wish to extract, and [local-path] would be a file path to the place you would like this file to be "downloaded". The following is an example:

dz> run app.provider.download content://vulnerabledatabase/../../../system/etc/hosts /tmp/hostsFileExtracted.txt

For those of you who have any experience in hacking/auditing web applications, this is quite similar to path traversal and local file inclusion vulnerabilities in web applications. It also exposes Android applications to many of the same risks. A couple of practical examples of this vulnerability have been reported against very popular applications; see the See Also... section of the recipe for examples.

If your content provider sets path level permissions using the PATTERN_LITERAL matching type, the Android permissions framework will only enforce checks to protect your content provider if the paths requested match yours exactly! The following screenshot an example:

This current example is taken from MWR labs' Sieve Android app, which was developed with certain vulnerabilities built into it; see the See also section for a link to the download page.

In the previous screenshot, we can see that this app uses PATTERN_LITERAL-type matching to protect the Keys path, which means that if we try to query it using drozer, the result will be as follows:

run app.provider.query content://com.mwr.example.sieve.DBContentProvider/Keys

The following screenshot shows the output from previous command:

The preceding screenshot shows how a permission denial is caused because drozer doesn't have the required permissions to interact with the provider. But, if we simply append / to the path, it will still be valid, the result is as follows:

run app.provider.query content://com.mwr.example.siever.DBContentProvider/Keys/

The following screenshot shows the output of the preceding command:

A forward slash was added to the path, so the PATTERN_LITERAL check failed to find the content://com.mwr.example.sieve.DBConentProvider/Keys path and found the content://com.mwr.example.sieve.DBConentProvider/Keys/ path instead. This means that the application querying the content provider would then need permissions for the /Keys/ path, which was not defined and thus required no permissions, allowing the query to be resolved without a hitch. In the previous screenshot, we can see that in this instance, a malicious application would be able to extract details of a user's login pin for the Sieve password manager application.