[NOTE: This bug is part of a series of three related Android bugs withthe same root cause: CVE-2018-9489, CVE-2018-9581 and CVE-2018-15835.A presentation covering all three bugs was given at BSides DE in thefall of 2018.]

SUMMARY

System broadcasts by the Android operating system expose detailedinformation about the battery. Prior research has demonstrated thatthe same charging information - when exposed via browser batterystatus API - can be used to uniquely identify and track users. As theresult, the battery API was removed from most browsers.

On Android however, this information is made available with highprecision. Furthermore, no special permission is required by anyapplication to access this information. As the result, this can beused to uniquely identify and track users across multiple apps. Thiswas verified via limited testing to be possible within a short periodof time.

Android versions 5.0 and later are affected. The vendor (Google) doesnot classify this bug as a security issue and has not released any fixplans. CVE-2018-15835 has been assigned by MITRE to track this issue.Further research is also recommended to see whether this is beingexploited in the wild.

BACKGROUND

Android is an open source operating system developed by Google formobile phones and tablets. It is estimated that over two billiondevices exist worldwide running Android. Applications on Android areusually segregated by the OS from each other and the OS itself.However, interaction between processes and/or the OS is still possiblevia several mechanisms.

In particular, Android provides the use of aIntentsa as one of theways for inter-process communication. A broadcast using an aIntentaallows an application or the OS to send a message system-wide whichcan be listened to by other applications. While functionality existsto restrict who is allowed to read such messages, applicationdevelopers often neglect to implement these restrictions properly ormask sensitive data. This leads to a common vulnerability withinAndroid applications where a malicious application running on the samedevice can spy on and capture messages being broadcast by otherapplications.

Another security mechanism present in the Android is permissions.These are safeguards designed to protect the privacy of users.Applications must explicitly request access to certain information orfeatures via a special auses-permissiona tag in the applicationmanifest (aAndroidManifest.xmla). Depending on the type of permission(anormala, adangerousa, etca) the OS may display the permissioninformation to the user during installation, or may prompt againduring run-time. Some permissions can only be used by systemapplications and cannot be used by regular developers.

VULNERABILITY DETAILS

The Android OS broadcasts information about the battery system-wide ona regular basis including charging level, voltage and temperature. Nospecial permission is needed to access this information. This isexposed via the aandroid.intent.action.BATTERY_CHANGEDa intent and isonly available on Android 5.0 or later. The same information is alsoavailable via Androidas BatteryManager without a special permission.

A similar capability existed in browsers via W3Cas Battery Status API.However, extensive research by Aukasz Olejnik et al. showed that thisAPI can be used to fingerprint devices, thus leading to tracking ofusers. Additional research revealed this being used in the wild bymultiple websites, and the API was removed from most web browsers asthe result.

In our limited testing we were able to distinguish devices locatedbehind the same NAT device within a short period of time, thus leadingto session re-spawning, but we were not yet able to replicate all theprior research regarding the HTML5 battery status API. This testingwas based on the uniqueness of the current battery charging counter asbeing different across defines.

As the result, the same privacy issues that applied in the originalBattery Status API should apply for Android applications resulting inapplications being able to fingerprint and track users, and re-spawnsession across multiple apps on the same device. Further research isneeded to see if this is being actively exploited in the wild.

STEPS TO REPLICATE (BY USERS):

For Android device users, you can replicate these issues as follows:1. Install the aInternal Broadcasts Monitora application developed byVilius Kraujutis from Google Play.2. Open the application and tap aStarta to monitor broadcasts.3. Observe system broadcasts, specificallyaandroid.net.wifi.STATE_CHANGEa andaandroid.net.wifi.p2p.THIS_DEVICE_CHANGEDa.

STEPS TO REPLICATE (VIA CODE):

To replicate this in code, create a Broadcast receiver and register itto receive the action aandroid.intent.action.BATTERY_CHANGEa). Samplecode appears below:

The vendor (Google) classified this issue as aNSBCa = aNot SecurityBulletin Classa - meaning "aIt was rated as not being a securityvulnerability that would meet the severity bar for inclusion in anAndroid security bulletin.a CVE-2018-15835 was assigned by the vendorfor tracking. No fix is yet available.

2018-03-28: Initial report submitted to the vendor2018-03-29: Initial response from the vendor received - issue being investigated2018-04-03: Vendor classified this as "NSBC"; follow-up communication2018-04-04: Follow-up communication with the vendor2018-05-02: Checking on status, response from vendor - issue stillunder investigation2018-06-05: Checking status, no response from the vendor2018-07-01: Checking status, no response from the vendor2018-07-10: Response from vendor - issue still under investigation;pinged for a timeline2018-07-12: Vendor still classifies this as "NSBC"; asking about disclosure2018-08-09: Additional information sent to the vendor re: Android 92018-08-14: Draft advisory provided for review2018-08-21: Vendor is looking in future improvements but the bug isstill "NSBC"; communication regarding CVE assigned2018-08-23: CVE assigned by MITRE2018-08-28: Another draft of the advisory provided for review2018-09-19: Pinged vendor for status2018-10-14: Notified vendor regarding upcoming talk2018-11-06: Slides provided for review2018-11-09: Public disclosure during a presentation at BSides DE2018-11-11: Advisory published