[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 Android OS expose information about the user’s device to all applications running on the device. This includes the WiFi network name, BSSID, local IP addresses, DNS server information and the MAC address. Some of this information (MAC address) is no longer available via APIs on Android 6 and higher, and extra permissions are normally required to access the rest of this information. However, by listening to these broadcasts, any application on the device can capture this information thus bypassing any permission checks and existing mitigations.

Because MAC addresses do not change and are tied to hardware, this can be used to uniquely identify and track any Android device even when MAC address randomization is used. The network name and BSSID can be used to geolocate users via a lookup against a database of BSSID such as WiGLE or SkyHook. Other networking information can be used by rogue apps to further explore and attack the local WiFi network.

All versions of Android running on all devices are believed to be affected including forks (such as Amazon’s FireOS for the Kindle). The vendor (Google) fixed these issues in Android P / 9 but does not plan to fix older versions. Users are encouraged to upgrade to Android P / 9 or later. CVE-2018-9489 has been assigned by the vendor to track this issue. Further research is also recommended to determine whether this is being exploited in the wild.

Amazon plans to address this issue as their transition devices to a new version of FireOS.

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:

Vulnerability Details

Android OS broadcasts information about the WiFi connection and the WiFi network interface on a regular basis using two intents: WifiManager’s NETWORK_STATE_CHANGED_ACTION and WifiP2pManager’s WIFI_P2P_THIS_DEVICE_CHANGED_ACTION. This information includes the MAC address of the device, the BSSID and network name of the WiFi access point, and various networking information such as the local IP range, gateway IP and DNS server addresses. This information is available to all applications running on the user’s device.

While applications can also access this information via the WifiManager, this normally requires the “ACCESS_WIFI_STATE” permission in the application manifest. Geolocation via WiFi normally requires the “ACCESS_FINE_LOCATION” or “ACCESS_COARSE_LOCATION” permissions. Also, on Android versions 6.0 and later, the real MAC address of the device is no longer available via APIs and will always return the address “02:00:00:00:00:00”. However, an application listening for system broadcasts does not need these permissions thus allowing this information to be captured without the knowledge of the user and the real MAC address being captured even on Android 6 or higher.

Screenshot of an app trying to obtain MAC address in Android 7.0:

We performed testing using a test farm of mobile device ranging across multiple types of hardware and Android versions. All devices and versions of Android tested confirmed this behavior, although some some devices do not display the real MAC address in the “NETWORK_STATE_CHANGED_ACTION” intent but they still do within the “WIFI_P2P_THIS_DEVICE_CHANGED_ACTION” intent. We also tested at least one fork (Amazon’s FireOS for the Kindle) and those devices displayed the same behavior.

Because MAC addresses do not change and are tied to hardware, this can be used to uniquely identify and track any Android device even when MAC address randomization is used. The network name and/or BSSID can be used to geolocate users via a lookup against a database like WiGLE or SkyHook. Other networking information can be used by rogue apps to further explore and attack the local WiFi network.

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 examples:

 

Steps to Replicate by Developers via Code

To replicate this in code, create a Broadcast receiver and register it to receive these actions (“android.net.wifi.WifiManager.NETWORK_STATE_CHANGED_ACTION” and “android.net.wifi.WifiP2pManager.WIFI_P2P_THIS_DEVICE_CHANGED_ACTION”). Sample code appears below:

public class MainActivity extends Activity {
@Override
public void onCreate(Bundle state) {
    IntentFilter filter = new IntentFilter();        
    filter.addAction(
	android.net.wifi.WifiManager.NETWORK_STATE_CHANGED_ACTION);
    filter.addAction(
	android.net.wifi.WifiP2pManager.WIFI_P2P_THIS_DEVICE_CHANGED_ACTION);
    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 Moderate, and provided a fix in Android P / 9. Because this would be a breaking API change, the vendor does not plan to fix prior versions of Android. Users are encouraged to upgrade to Android P / 9 or later.

Amazon has responded regarding their Android fork (FireOS) as follows:

We are planning to address the issue as devices transition to the new version of Fire OS

References

Android ID # 77286245
CVE ID: CVE-2018-9489
Google Bug # 77236217
GitHub: Internal Broadcasts Monitor

Bounty Information

This bug qualified for a bounty under the terms of the Google’s Android Rewards bounty program, and a bounty payment has been received.

Credits

We want to thank Vilius Kraujutis for developing the Internal Broadcasts Monitor application and making the source code available in GitHub.

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: Follow-up communication with the vendor
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: Pinged the vendor regarding CVE assignment and disclosure plans
2018-07-13: Information about the fix provided by the vendor; follow-up communication
2018-07-14: Additional information provided to the vendor
2018-07-17: Additional information provided to the vendor
2018-07-19: Additional information provided to the vendor, response received
2018-08-09: Fix confirmed
2018-08-16: Initial draft of the advisory provided to the vendor for review
2018-08-21: Follow-up communication with the vendor
2018-08-22: CVE assigned by the vendor, follow-up communication with the vendor
2018-08-23: Final version of the advisory provided to the vendor for review
2018-08-29: Public disclosure / advisory published; added information about Android forks
2018-09-05: Added Amazon’s response
2018-10-22: Added bounty information
2018-11-11: Added links to related bugs and presentation
2019-09-01: Fix listed as part of Android 10 fixes

Media Coverage

• BetaNews
• Bleeping Computer
• Boy Genius Report (BGR)
• Rambler.ru (Russian)
• Reddit (here and here)
• SC Magazine
• Security Week
• SlashDot
• Techno Nucleous (Spanish)
• Tom’s Guide
• ThreatPost
• ZDNet