NFC Beaming Bypasses Security Controls in Android [CVE-2019-2114]

Summary

NFC beaming of applications between devices using Android OS bypasses some security controls (the “install unknown application” prompt). A rogue device like a payment terminal can use this vulnerability to infect devices with malware.

Affected versions of Android are version 8 (Oreo) and higher. The vendor assigned CVE-2019-2114 to track this issue and released a fix in the October 2019 security bulletin. Users are encouraged to update their devices to mitigate this vulnerability.

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. Most Android devices are restricted in which applications can be installed by users – in particular, they must originate from the Google Play Store. Prior to version 8 (Oreo) a system-wide setting existed in the OS which allowed users to override this control and grant them ability to install applications from any source (“Settings” -> “Security”). In Android 8 (Oreo) this has been changed, and users must grant permission to each application that is trying to perform such install as opposed to a system-wide setting. See example:

Some Android devices support NFC (Near Field Communication) – set of protocols that allow devices to communicate within a very short distance. This is used for applications like contactless payments, pairing of devices and access control. Android devices also support NFC for transferring data between two devices including contracts, photos and applications via a feature called Android Beam.

Vulnerability Details

In Android 8 (Oreo) a new feature was introduced that requires users to opt-in to the “Install unknown apps” permission on a app by app basis. However, it appears that any system application that is signed by Google will be automatically whitelisted and would not prompt the user for this permission. On a standard Android OS device, the NFC service is one such system application that has the permission to install other applications. This means, that an Android phone that has NFC and Android Beam enabled, then touching a malicious phone or a malicious NFC payment terminal to the device may allow malware to be installed by bypassing the “install unknown apps” prompt.

To see these permissions, use any Android phone with NFC and running v8 or higher, go to “Settings”, search for “Install unknown apps” to find the permission. Tap through to view apps, and make sure to select “Show system” in the dropdown menu. You will see that the “NFC Service” is listed as being allowed to install applications by default (since it is a system application). See example:

image

Steps to Replicate

To actually replicate a malicious drive-by install, do the following:

  1. Setup two phones with NFC and Android beam enabled.
  2. Download any APK file on the “sender” phone (something like
    this APK from GitHub).
  3. Go to the file manager in the “sender” phone, tap the file and select “Share”. Then select “Android Beam” as the sharing method,
  4. Bring two phones together and complete the transfer.
  5. After this is done, go to the receiver phone, tap the “Beam completed” notification, and tap the file. It will skip directly to the install prompt, bypassing the “Install unknown apps” check.

Tested on Android 9 and Android 8.10.

Vendor Response and Mitigation

The vendor (Google) classified this issue as High and assigned CVE-2019-2114 to track this issue. A fix was released in the October 2019 security bulletin. Users are encouraged to update their devices to mitigate this vulnerability. After applying the update, users are encouraged to check the “Install unknown apps” permission in settings to make sure the NFC Service is listed as “not allowed” to install applications.

This issue only affects Android version 8 (Oreo) or higher.

References

Android bulletin: October 2019 (2019-10-06)
CVE ID: CVE-2019-2114
Google Bug # 123651515 (Android ID # A-123700348)
Google Blog: Blog post about the changes in the “install unknown apps” permission

Bounty Information

This issue satisfied the requirements of the Android Security Rewards Program and a bounty payment has been paid by the vendor.

Credits

This advisory was written by Y. Shafranovich.

Timeline

2019-01-30: Initial report submitted to the vendor
2019-01-31: Vendor response received – issue under investigation
2019-02-01: Issue rated as High by the vendor
2019-03-02: Checking bug status, vendor communication
2019-04-06: Checking bug status, vendor communication
2019-04-29: Checking bug status, fix is still being worked on
2019-06-29: Checking bug status, vendor communication
2019-07-01: Vendor indicating that a patch is forthcoming, CVE assigned
2019-07-08: Notified vendor about upcoming talk
2019-07-10: Vendor informing that the fix has been delayed by a month
2019-07-28: Draft blog post sent to the vendor for review
2019-07-31: Blog post comments received from the vendor
2019-09-04: Follow-up communication with the vendor
2019-10-07: Fix released
2019-10-24: Public disclosure

Media Coverage

See:

Fixes for CVE-2018-9581 and CVE-2018-9489 in Android 10

Two privacy issues with broadcasts in Android OS are expected to be fixed in Android Q / 10 which will be released in early September of 2019. You can see the details in Google’s security bulletin available here. Some of these fixes were not available for earlier version of Android.

We originally discovered these in the Spring of 2018 and they were disclosed via a talk at BSides DE late last year. Details are available as follows:

 

 

Brief Notes on Gmail for Android and Confidential Mode

Recently Google launched “Confidential Mode” for Gmail which seeks to protect sensitive information from unauthorized access – details here.

Some brief notes:

  • On the web version of Gmail, when replying to a confidential message, the reply is also sent as confidential. However, when using Gmail for Android that is not true – instead you get a warning that the message will not be sent with confidential mode.
  • When viewing confidential mode emails with Gmail for Android, FLAG_SECURE is not used (see our post here). That means other applications on the same device with the screen capture permissions can capture this content as well. This was reported to Google (issue # 112838515) and they do not consider it a security issue.

Upcoming Advisory for an Android OS Vulnerability – CVE-2019-2114

We will be releasing an advisory on a security vulnerability that was reported to the Google, specifically in Android OS. This issue is being tracked under CVE-2019-2114. The advisory is expected to be published later this year once a fix is released by the vendor.

UPDATE: The advisory and fix for this issue have been released – see our blog post here.

Two Bugs in Google Chrome

Summary

Google Chrome has two places (credits pages and default sites) where HTTP links are used instead of HTTPS, which can lead to MITM attacks on a hostile network. The vendor doesn’t consider these to be security bugs and they remain unfixed.

Bug Details – Default Sites

On startup, Chrome for Android displays a search bat and 8 icons of commonly accessed sites. If the browser has not yet collected any history data, those icons default to the ones provided by a Google-hosted service (“https://www.gstatic.com/chrome/ntp/suggested_sites_DEFAULT_5.json“). These default sites are country specific. However, not all of these links use HTTPS – some use HTTP. As the result if a user is on a hostile network and taps any of these sites, the connection can be intercepted by an MITM attacker.

While this issue was seen in Android, it may affect other platforms.

Screenshots:

Screenshot_20171122-215523 Screen Shot 2019-05-27 at 12.37.41 PM

Bug Details – Credits Page

Chrome has a credits page (“chrome://credits“) that contains licensing information and links to various open source projects. Not all of these links use HTTPS, instead some use HTTP. As the result if a user is on a hostile network and taps any of these sites, the connection can be intercepted by an MITM attacker. This can be seen by going to the URL (“chrome://credits“) or going to “Help”, “About”, “Open Source Licenses”.

This impacts all platforms that Chrome supports including Linux, Windows, Android, iOS, MacOS and ChromeOS.

Screenshots:

Screenshot_20190527-123241 Screenshot_20190527-123253  Screenshot_20190527-123307

Vendor Response

The vendor doesn’t consider these to be security bugs and they remain unfixed.

References

Chromium Bugs: 788055 and 927139

Credits

Advisory written by Y. Shafranovich.

Timeline

2017-11-22: Default sites bug (#788055) reported to the vendor
2017-11-23: Initial vendor response (#788055), not considered a security bug
2017-11-23: Vendor response (#788055)
2019-01-30: Credits bug (#927139) reported to the vendor
2019-01-30: Initial vendor response (#927139), not considered a security bug
2019-01-30: Vendor response (#927139)
2019-04-01: Checking with vendor regarding disclosure (#788055)
2019-05-27: Public disclosure for both

Third Party Android App Storing Facebook Data Insecurely (Facebook Data Abuse Program)

Summary

A third-party Android application with Facebook API access was found to be copying user data into storage outside of Facebook, and storing it insecurely in two separate locations. This issue was reported to Facebook via their Data Abuse Bounty program and the insecure storage locations have been secured on November 12th, 2018. The Facebook app associated with this application has been removed from the Facebook platform but the Android application remains available in Google’s Play Store. The number of affected users is unknown. [ADDED: 02/15/2019 – Google has been notified].

Background

In April 2018, FaceBook announced a new Data Abuse Bounty program that rewards “people with first-hand knowledge and proof of cases where a Facebook platform app collects and transfers people’s data to another party to be sold, stolen or used for scams or political influence“.

In September 2018, we found an Android application in the Google Play store that purports to provide additional functionality to Facebook users that is not available through the platform. At the time of writing, the application had more than 1,000,000 downloads. After downloading the application, and examining it using JADX, we found that the application was using Facebook APIs to access data for the logged in user and copying to several storage locations outside of Facebook. Upon further examination, it was clear that at least two of such locations (a Firebase database and an API server) were making this data available without any authentication and without HTTPS. This would allow an attacker to mass download the user data accumulated by the application from its users.

We do not know for sure how many users have been impacted or exposed, but one of the databases accessed contained over 1,000,000 records. [ADDED: 02/15/2019 – The application purported to provide additional statistical information about the logged-in user’s Facebook account. There is a privacy policy within the application but it is ambiguous about the transfer of data].

Issue #1 – Storing user data in an public Firebase database

During our examination of the application, we located a Firebase database that the application was communicating with. The database was configured in test mode, which allowed anonymous public access by visiting the URL of “https://DATABASE.firebaseio.com/.json“. As seen in the attached screenshot, the database contained data obtained from Facebook. Aside from confirming the initial permission issue, we did not access or explore this database any further.

Screenshot:

likulator1

Issue #2 – Storing user data in a non-SSL server without authentication

During our examination of application, it become clear that the server that the application was communicating with, did not use SSL and was being accessed without authentication. As seen below, this would allow an attacker to download the data collected by the application from Facebook via a regular browser as well as spy on any connections between the application and the server. Aside from confirming the initial permission issue, we did not access or explore this database any further.

likulator2

likulator3

Vendor Response and Mitigation

We contacted the Facebook Data Abuse Bounty program but did not contact the vendor directly. After Facebook completed its review, the two insecure locations have been secured on November 12th, 2018. The Facebook app associated with this application has been removed from the Facebook platform but the Android application remains available in Google’s Play Store. [ADDED: 02/15/2019 – Google has been notified].

This discovery qualified under the terms of the Facebook Data Abuse Bounty Program and a bounty payment has been received.

References

Facebook report # 10101718616795015
Google reference # 8-7487000025062

Credits

This advisory was written by Yakov Shafranovich.

Timeline

2018-09-17: Initial report submitted to Facebook, initial response received
2018-11-12: Issued fixed
2018-11-27: Bounty decision received; sent disclosure request
2018-11-30: Facebook asked for additional time before disclosure
2019-01-15: Investigation has been finalized, FaceBook asked for a copy of the disclosure
2019-02-03: Draft disclosure shared for review
2019-02-14: Public Disclosure
2019-02-15: Minor updates; notification sent to Google

Content Injection in Amazon Kindle’s FireOS [CVE-2019-7399]

Summary

The FireOS operating system provided by Amazon for Fire tablet devices can be injected with malicious content by an MITM attacker. An attacker can also capture the serial number of the device. The root cause is lack of HTTPS for legal content (terms of use and privacy policy) within the settings section.

The issue was discovered in FireOS v5.3.6.3 and fixed by the vendor in v5.3.6.4 that was released in November 2018. Devices will automatically update to the latest version. CVE-2019-7399 has been assigned by MITRE to track this issue.

Vulnerability Details

FireOS is an operating system provided by Amazon for the Fire tablet devices.  It is a customized fork of Android. While monitoring network traffic on a test device, we observed that several calls from the settings section (terms of use and privacy policy) are done without HTTPS and can be injected with malicious content by an MITM attacker. It is also possible for the attacker to observe this traffic and capture the serial number (DSN) of the device.

Screenshots of the captured traffic:

Screenshot_2018-09-03-13-11-20 Screenshot_2018-09-03-13-11-26

Steps To Replicate (on Ubuntu 18.04)

1. Install the application on the Android device but do not start it.

2. Install dnsmasq and NGINX on the Linux host:

sudo apt-get install dnsmasq nginx

3. Modify the /etc/hosts file to add the following entry to map the domain name to the Linux host:

192.168.1.x www.kindle.com
192.168.1.x kindle.com

4. Configure /etc/dnsmasq.conf file to listen on the IP and restart DNSMASQ

listen-address=192.168.1.x
sudo /etc/init.d/dnsmasq restart

5. Add a file with malicious content (you may need to use sudo):

cd /var/www/html
mkdir support
echo powned >support/privacy
echo powned >support/terms

6. Modify the settings on the Kindle device to static, set DNS to point to “192.168.1.x”. AT THIS POINT – the Kindle device will resolve DNS against the Linux computer and serve the large servers file

7. Tap “Settings”, “Legal and Compliance”, and tap either “Terms of Use” or “Privacy”. Observe injected content.

Vendor Response and Mitigation

The issue was discovered in FireOS v5.3.6.3 and fixed by the vendor in v5.3.6.4 that was released in November 2018. Devices will automatically update to the latest version. MITRE assigned CVE-2019-7399 to track this issue.

References

Amazon tracking # PO135449968
CVE-ID: CVE-2019-7399

Credits

Text of the advisory written by Yakov Shafranovich.

Timeline

2018-09-03: Initial report to the vendor
2018-09-04: Report triaged and being reviewed by the vendor
2018-09-17: Communication from the vendor, issue still being reviewed
2019-01-10: Fix confirmed, communication regarding disclosure
2019-01-30: Vendor pinged about CVE assignment
2019-02-03: Draft advisory sent for review
2019-02-04: CVE issued by MITRE
2019-02-07: Public disclosure; minor syntax updates

Wickr Me for Android Allowed Screen Capture

Wickr offers a suite of applications which provide secure instant messaging, voice and audio calls. The Android version of Wickr Me Messenger allowed screenshots to be taken by other apps on the device because FLAG_SECURE option wasn’t used.

To replicate, try the following:

  1. Open the application.
  2. Press Power + Volume Down at any sensitive screen and observe a screenshot being taken.

The underlying reason is because the app is not using “FLAG_SECURE” for such screens (more information on FLAG_SECURE can be found in our earlier blog post). By contrast, many Android apps with higher security requirements use it.

Vendor Response and Mitigation

This issue was reported in May 2016 against version 2.6.4.1, and was fixed in September 2018 in version 4.55.1. A bounty has been paid.

References:

  • Google Play Link to the app – see here
  • Our earlier blogpost about FLAG_SECURE on Android – see here

 

Sensitive Data Exposure via RSSI Broadcasts in Android OS [CVE-2018-9581]

[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 WiFi signal strength information (RSSI). Any application on the device can capture this information without additional permissions. Rogue applications can potentially use this information for indoor positioning in order to locate or track users within a small area near the WiFi router. Same issue also applies to the underlying Android API, although an additional permission is required.

All versions of Android are believed to be affected. The vendor (Google) has not yet fixed this issue, The vendor (Google) has fixed this issue in Android 10 / Q, however on Android 9 / P one of the two broadcast types is no longer revealing sensitive data (as part of the fix for CVE-2018-9489). The vendor assigned CVE-2018-9581 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 “Intents” as one of the ways for inter-process communication. A broadcast using an “Intent” 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 “uses-permission” tag in the application manifest (“AndroidManifest.xml”). Depending on the type of permission (“normal”, “dangerous”, etc”) 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.

Screenshots of application permissions in Google Play and at run-time:

pic3 pic4 pic6

Vulnerability Details

The Android OS broadcasts the WiFi strength value (RSSI) system-wide on a regular basis. No special permission is needed to access this information. The RSSI values represent the relative strength of the signal being received by the device (higher = stronger) but are not directly correlated to the actual physical signal strength (dBm). This is exposed via two separate intents (“android.net.wifi.STATE_CHANGE” prior to Android 9; and “android.net.wifi.RSSI_CHANGED” in all versions of Android).

While applications can also access this information via the WifiManager, this normall requires the “ACCESS_WIFI_STATE” permission in the application manifest. For the WiFi RTT feature that is new to Android 9 and is used for similar geolocation, the “ACCESS_FINE_LOCATION” is required. But, when listening for system broadcasts, no such permissions are required allowing applications to capture this information without the knowledge of the user.

There are two separate security issues present:

  1. RSSI values are available via broadcasts, bypassing the permission check normally required (“ACCESS_WIFI_STATE”).
  2. RSSI values, via broadcasts or WifiManager can be used for indoor position without the special location permission.

Steps to Replicate by Regular Users

For Android device users, you can replicate these issues as follows:

  1. Install the “Internal Broadcasts Monitor” application developed by Vilius Kraujutis from Google Play.
  2.  Open the application and tap “Start” to monitor broadcasts.
  3.  Observe system broadcasts, specifically “android.net.wifi.STATE_CHANGE” (prior to Android 9) and “android.net.wifi.RSSI_CHANGED” (all versions).

Screenshot example:

screen1

Steps to Replicate by Developers via Code

To replicate this in code, create a Broadcast receiver and register it to receive the actions “android.net.wifi.STATE_CHANGE” (Android version v8.1 and below only) and “android.net.wifi.RSSI_CHANGED”.

Sample code appears below:

public class MainActivity extends Activity {
@Override
public void onCreate(Bundle state) {
    IntentFilter filter = new IntentFilter();        
    filter.addAction(android.net.wifi.STATE_CHANGE);
    filter.addAction(android.net.wifi.RSSI_CHANGED);
    registerReceiver(receiver, filter);
}
    
BroadcastReceiver receiver = new BroadcastReceiver() {
@Override
public void onReceive(Context context, Intent intent) {
    Log.d(intent.toString());
    ….
}
};

Testing Methodology

Our test used the following devices:

  • Pixel 2, running Android 8.1.0, patch level July 2018

  • Nexus 6P, running Android 8.1.0, patch level July 2018

  • Moto G4, running Android 7.0, patch level April 2018

  • Kindle Fire HD (8 gen), running Fire OS 5.6.10, which is forked from Android 5.1.1, updated April 2018

  • Router used was ASUS RT-N56U running the latest firmware

(We included the Kindle Fire to show that forks of Android inherit this functionality)

The following steps were performed:

  1. Install Broadcast Monitor app.
  2. Put the phone into airplane mode.
  3. Walk into the room.
  4. Turn off airplane mode (to trigger the RSSI broadcasts).
  5. Get the RSSI values from the following broadcasts:
    1. android.net.wifi.RSSI_CHANGE – newRssi value
    2. android.net.wifi.STATE_CHANGE – networkInfo / RSSI
  6. Repeat steps 3-4 for each room.

Results of the testing cleared showed that each room had a unique range of RSSI values when using a particular device.

Range of values collected during testing:

Room #

Pixel

Nexus

Moto G4

Kindle Fire

1

39 – 43

44

39 – 42

59 – 60

2

45 – 49

49 – 56

48 – 52

45 – 46

3

42 – 44

50

51 – 53

49 – 50

4

54 – 56

60 – 63

60 – 62

66

Vendor Response and Mitigation

The vendor (Google) classified this issue as Moderate and assigned CVE-2018-9581 to track this issue. No fix is available yet A fix is available on Android 10 / Q, however on Android 9 / P one of the two broadcast types (“android.net.wifi.STATE_CHANGE”) is no longer revealing sensitive data (as part of the fix for CVE-2018-9489). It is unknown if this issue is being exploited in the wild.

References

Android ID # 111698366
CVE ID: CVE-2018-9581
Google Bug # 111662293
GitHub: Internal Broadcasts Monitor
Presentation given at BSides DE: see here

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 locating users via RSSI values, including the following papers:

This advisory was written by Yakov Shafranovich.

Timeline

2018-03-28: Initial report submitted to the vendor re: CVE-2018-9489
2018-07-19: Separate report created for this issue as per vendor request; testing results provided
2018-07-20: Vendor response received – issue under investigation
2018-08-09: Provided results of Android 9 testing
2018-08-14: Draft advisory provided for review
2018-08-28: Asking about disclosure
2018-09-14: Vendor response receiving, still pending
2018-09-19: Pinged vendor
2018-09-21: Vendor response receiving, issue under investigation
2018-10-14: Notified vendor about upcoming talk
2018-10-15: Vendor response receiving, issue under investigation
2018-10-25: Asking for CVE assignment
2018-10-30: Asked again about CVE assignment
2018-11-01: Asked MITRE for CVE assigment
2018-11-05: CVE assigned by the vendor, notified MITRE
2018-11-06: Slides provided for review
2018-11-09: Public disclosure during a presentation at BSides DE
2018-11-11: Advisory published
2019-09-01: Fix listed as part of Android 10 fixes

Sensitive Data Exposure via Battery Information Broadcasts in Android OS [CVE-2018-15835]

[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 “Intents” as one of the ways for inter-process communication. A broadcast using an “Intent” 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 “uses-permission” tag in the application manifest (“AndroidManifest.xml”). Depending on the type of permission (“normal”, “dangerous”, etc”) 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.

Screenshots of application permissions in Google Play and at run-time:

pic3 pic4 pic6

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 “android.intent.action.BATTERY_CHANGED” intent and is only available on Android 5.0 or later. The same information is also available via Android’s BatteryManager without a special permission.

A similar capability existed in browsers via W3C’s Battery Status API. However, extensive research by Łukasz 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 Regular Users

For Android device users, you can replicate these issues as follows:

  1. Install the “Internal Broadcasts Monitor” application developed by Vilius Kraujutis from Google Play.
  2.  Open the application and tap “Start” to monitor broadcasts.
  3.  Observe system broadcasts, specifically “android.net.wifi.STATE_CHANGE” and “android.net.wifi.p2p.THIS_DEVICE_CHANGED”.

Screenshot example:

text

Steps to Replicate by Developers via Code

To replicate this in code, create a Broadcast receiver and register it to receive the action “android.intent.action.BATTERY_CHANGE”). 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());
    ….
}
};

Vendor Response and Mitigation

The vendor (Google) classified this issue as “NSBC” = “Not Security Bulletin Class” – meaning ““It was rated as not being a security vulnerability that would meet the severity bar for inclusion in an Android security bulletin.” CVE-2018-15835 was assigned by the vendor for tracking. No fix is yet available.

References

Android ID # 77286983
Android Power information: see here
CVE ID: CVE-2018-15835
Google Bug # 77236216
GitHub: Internal Broadcasts Monitor
Presentation given at BSides DE: see here

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:

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