Local SQL Injection In ‘com.android. providers. telephony’ version 10 (CVE-2020-0060)

Vulnerability discovered by Perspective Risk’s Senior Security Consultant, Calum Hutton.

Summary

A local SQL injection vulnerability was found in a Content Provider provided by the ‘com.android.providers.telephony ’ package (version 10). This application provides core Android functionality related to MMS and SMS messages, amongst other things. Exploitation of this vulnerability allows injection and execution of arbitrary SQL statements within the context of the target package. It also provides access to sensitive information within database tables which should be restricted. This can be exploited by any other app installed on the device with permission to read SMS messages.

Background

One of the components provided by the Android framework is Content Providers, which provide access to an apps database, usually stored within SQLite database files within the apps data directory. Content Providers are accessed via special URIs called Content URIs, an example is shown below:

content://sms/attachments/1

 

Access Control

Content Providers are designed to be accessible both internally to the package hosting the provider and/or to other apps installed on the device. There are various access controls that restrict or allow access to a Content Provider:

  • The provider must be enabled and exported within the app manifest file for it to be exposed to external apps.
  • Different permissions can be required for read and write operations on the provider, including null. Null permissions allow access to any app. Without the appropriate read or write permission (or null), external applications cannot perform the read or write operation on the provider.
  • Different permissions can also be required for read and write operations on specific sub-paths of the provider URI (path permissions).

 

Existing Tools?

Tools already exist that can be used to test apps for SQL injection vulnerabilities in their content providers, however they usually concentrate on only two injection vectors, (projection and selection) and may only perform heuristic tests, leading to false positives.

Due to the limitations of current tools in this space, it was decided that a new tool would be created, with the following requirements:

  • Core functionality exists within Android module
  • Test injection vectors:
    • Projection
    • Selection
    • URI
    • Sort order
    • Content values (key)
  • Use heuristic tests and multiple payloads to confirm injection:
    • Projection
    • Union
    • Boolean blind
  • Also test for path traversal vulnerabilities
  • Store test results in JSON for import/export

CPMap

CPMap was developed to address these requirements, and consists of an Android module and wrapper app, with the idea being that the core scanning functionality exists in the module and can be easily re-used in other Android apps. The wrapper app exists to provide a user interface and background services etc that interact with the functionality provided by the module.

The tool is fully automated, with some customisable options to control the scan. A high-level overview of the discovery scan process is as follows:

  • An app package name is provided, used as the target of the scan. Only content providers hosted by the target are checked in the scan.
  • CPMap checks for available content providers in the target app (based on provider permissions and the current app context).
  • If available content providers are found, CPMap attempts to brute force valid content URI’s within the app using various methods.
  • Valid content provider URIs from the brute force are used in the scan. Vectors are generated from the URIs and heuristic tests are conducted on each injection vector.
  • Injection vectors with positive heuristic results are used in further injection tests, multiple payloads are used on each vector to confirm the injection vulnerability.
  • If injection vectors and payloads are found, a HashMap of vulnerable vectors and payloads is returned.

The Vulnerability

The target package was reviewed, and some content providers were found to require the Android permission android.permission.READ_SMS in order to be accessible. This permission was added to the tools manifest file to ensure that it had permission to interact with the restricted providers.

CPMap was then used to scan ‘com.android.providers.telephony’ version 10 and found several issues within the following content providers hosted by the app.

  • android.providers.telephony.HbpcdLookupProvider
  • android.providers.telephony.MmsSmsProvider
  • android.providers.telephony.SmsProvider
  • android.providers.telephony.CarrierProvider

Of particular interest are the MmsSmsProvider and SmsProvider as these are likely to contain sensitive content.

An example of some of the identified injection vectors and payloads are shown below:

android vulnerability code

The payloads listed above prove that it was possible to inject and execute arbitrary SQL queries in the context of the target package. From the positive heuristic tests, CPMap can identify the original query (via an error message from the provider), as shown in the output above.

Impact

The impact of this issue is minimal if it were contained to a single database table (we have READ_SMS permission, so we should be able to read SMS/MMS at least), however it is the possibility of reading other unrelated tables via SQL injection which increases the risk and impact of this issue. By querying the sqlite_master table, it is possible to determine all other database tables which are accessible via injection. The list of accessible tables is shown below:

  • pdu
  • sms_restricted
  • attachments
  • part
  • mcc_lookup_table
  • pending_msgs
  • rate
  • sms
  • words_content
  • nanp_area_code
  • words_segments
  • addr
  • mcc_sid_range
  • arbitrary_mcc_sid_match
  • sqlite_sequence
  • drm
  • android_metadata
  • sr_pending
  • mcc_idd
  • mcc_sid_conflict
  • carrier_key
  • words
  • raw
  • canonical_addresses
  • threads
  • pdu_restricted
  • words_segdir

Disclosure Timeline

  • Oct 23rd 2019: Issue reported to vendor (Google)
  • Oct 30th 2019: Initial assessment performed by vendor, issue confirmed
  • December 19th 2019: Patch implemented
  • March 10th 2020: CVE-2020-0060 published