Android 5.0 Battery Information Broadcast Information Disclosure

`[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  
  
  
`