[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