Date: Thu, 30 Aug 2018 00:34:33 GMT
From: research@...htwatchcybersecurity.com
To: bugtraq@...urityfocus.com
Subject: Sensitive Data Exposure via WiFi Broadcasts in Android OS
 [CVE-2018-9489]

[Blog post here:
https://wwws.nightwatchcybersecurity.com/2018/08/29/sensitive-data-exposure-via-wifi-broadcasts-in-android-os-cve-2018-9489/]

TITLE

Sensitive Data Exposure via WiFi Broadcasts in Android OS [CVE-2018-9489]

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.

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.

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.

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
[https://play.google.com/store/apps/details?id=lt.andro.broadcastlogger].
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”.

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 fixed these issues 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.

REFERENCES

Android ID # 77286245
CVE ID: CVE-2018-9489
Google Bug # 77236217
GitHub: Internal Broadcasts Monitor
[https://github.com/ViliusKraujutis/AndroidBroadcastsMonitor]

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

Powered by blists - more mailing lists