[NOTE: This bug is part of a series of three related Android bugs with the 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 the fall of 2018.] SUMMARY System broadcasts by the Android operating system expose detailed information about the battery. Prior research has demonstrated that the same charging information - when exposed via browser battery status API - can be used to uniquely identify and track users. As the result, the battery API was removed from most browsers. On Android however, this information is made available with high precision. Furthermore, no special permission is required by any application to access this information. As the result, this can be used to uniquely identify and track users across multiple apps. This was verified via limited testing to be possible within a short period of time. Android versions 5.0 and later are affected. The vendor (Google) does not classify this bug as a security issue and has not released any fix plans. CVE-2018-15835 has been assigned by MITRE to track this issue. Further research is also recommended to see whether this is being exploited in the wild. BACKGROUND Android is an open source operating system developed by Google for mobile phones and tablets. It is estimated that over two billion devices exist worldwide running Android. Applications on Android are usually segregated by the OS from each other and the OS itself. However, interaction between processes and/or the OS is still possible via several mechanisms. In particular, Android provides the use of aIntentsa as one of the ways for inter-process communication. A broadcast using an aIntenta allows an application or the OS to send a message system-wide which can be listened to by other applications. While functionality exists to restrict who is allowed to read such messages, application developers often neglect to implement these restrictions properly or mask sensitive data. This leads to a common vulnerability within Android applications where a malicious application running on the same device can spy on and capture messages being broadcast by other applications. 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 or features via a special auses-permissiona tag in the application manifest (aAndroidManifest.xmla). Depending on the type of permission (anormala, adangerousa, etca) the OS may display the permission information to the user during installation, or may prompt again during run-time. Some permissions can only be used by system applications and cannot be used by regular developers. VULNERABILITY DETAILS The Android OS broadcasts information about the battery system-wide on a regular basis including charging level, voltage and temperature. No special permission is needed to access this information. This is exposed via the aandroid.intent.action.BATTERY_CHANGEDa intent and is only available on Android 5.0 or later. The same information is also available 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 this API can be used to fingerprint devices, thus leading to tracking of users. Additional research revealed this being used in the wild by multiple websites, and the API was removed from most web browsers as the result. In our limited testing we were able to distinguish devices located behind the same NAT device within a short period of time, thus leading to session re-spawning, but we were not yet able to replicate all the prior research regarding the HTML5 battery status API. This testing was based on the uniqueness of the current battery charging counter as being different across defines. As the result, the same privacy issues that applied in the original Battery Status API should apply for Android applications resulting in applications being able to fingerprint and track users, and re-spawn session across multiple apps on the same device. Further research is needed 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 by Vilius Kraujutis from Google Play. 2. Open the application and tap aStarta to monitor broadcasts. 3. Observe system broadcasts, specifically aandroid.net.wifi.STATE_CHANGEa and aandroid.net.wifi.p2p.THIS_DEVICE_CHANGEDa. STEPS TO REPLICATE (VIA CODE): To replicate this in code, create a Broadcast receiver and register it to receive the action aandroid.intent.action.BATTERY_CHANGEa). Sample code appears below: public class MainActivity extends Activity { @Override public void onCreate(Bundle state) { IntentFilter filter = new IntentFilter(); filter.addAction( android.intent.action.BATTERY_CHANGE); registerReceiver(receiver, filter); } BroadcastReceiver receiver = new BroadcastReceiver() { @Override public void onReceive(Context context, Intent intent) { Log.d(intent.toString()); a|. } }; VENDOR RESPONSE AND MITIGATION The vendor (Google) classified this issue as aNSBCa = aNot Security Bulletin Classa - meaning "aIt was rated as not being a security vulnerability that would meet the severity bar for inclusion in an Android security bulletin.a CVE-2018-15835 was assigned by the vendor for tracking. No fix is yet available. REFERENCES Android ID # 77286983 Android Power information: https://source.android.com/devices/tech/power/device CVE ID: CVE-2018-15835 Google Bug # 77236216 GitHub: Internal Broadcasts Monitor - https://github.com/ViliusKraujutis/AndroidBroadcastsMonitor Presentation given at BSides DE: https://wwws.nightwatchcybersecurity.com/2018/11/05/speaking-bsidesde-this-friday-on-android-privacy-bugs-cve-2018-9489-cve-2018-9581-and-cve-2018-15835/ CREDITS We want to thank Vilius Kraujutis for developing the Internal Broadcasts Monitor application and making the source code available in GitHub. We would like to thank multiple academic researchers who have previously published research on the HTML5 Battery API including the following papers: - aThe Leaking Batterya (2015); by Aukasz Olejnik, Gunes Acar, Claude Castelluccia, and Claudia Diaz; - aOnline tracking: A 1-million-site measurement and analysisa (2016); by Steven Englehardt and Arvind Narayanan - aBattery Status Not Included: Assessing Privacy in Web Standardsa (2017); Aukasz Olejnik, Steven Englehardt, Arvind Narayanan; see also this blog post: This advisory was written by Yakov Shafranovich. TIMELINE 2018-03-28: Initial report submitted to the vendor 2018-03-29: Initial response from the vendor received - issue being investigated 2018-04-03: Vendor classified this as "NSBC"; follow-up communication 2018-04-04: Follow-up communication with the vendor 2018-05-02: Checking on status, response from vendor - issue still under investigation 2018-06-05: Checking status, no response from the vendor 2018-07-01: Checking status, no response from the vendor 2018-07-10: Response from vendor - issue still under investigation; pinged for a timeline 2018-07-12: Vendor still classifies this as "NSBC"; asking about disclosure 2018-08-09: Additional information sent to the vendor re: Android 9 2018-08-14: Draft advisory provided for review 2018-08-21: Vendor is looking in future improvements but the bug is still "NSBC"; communication regarding CVE assigned 2018-08-23: CVE assigned by MITRE 2018-08-28: Another draft of the advisory provided for review 2018-09-19: Pinged vendor for status 2018-10-14: Notified vendor regarding upcoming talk 2018-11-06: Slides provided for review 2018-11-09: Public disclosure during a presentation at BSides DE 2018-11-11: Advisory published