Android RSSI Broadcast Information Disclosure

`[Blog post here:  
https://wwws.nightwatchcybersecurity.com/2018/11/11/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, 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 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 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 (aandroid.net.wifi.STATE_CHANGEa  
prior to Android 9; and aandroid.net.wifi.RSSI_CHANGEDa in all  
versions of Android).  
  
While applications can also access this information via the  
WifiManager, this normall requires the aACCESS_WIFI_STATEa permission  
in the application manifest. For the WiFi RTT feature that is new to  
Android 9 and is used for similar geolocation, the  
aACCESS_FINE_LOCATIONa 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 (aACCESS_WIFI_STATEa).  
2. RSSI values, via broadcasts or WifiManager can be used for indoor  
position without the special location permission.  
  
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 (prior to Android 9) and  
aandroid.net.wifi.RSSI_CHANGEDa (all versions).  
  
STEPS TO REPLICATE (IN CODE):  
  
To replicate this in code, create a Broadcast receiver and register it  
to receive the actions aandroid.net.wifi.STATE_CHANGEa (Android  
version v8.1 and below only) and aandroid.net.wifi.RSSI_CHANGEDa.  
  
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());  
a|.  
}  
};  
  
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:  
- android.net.wifi.RSSI_CHANGE - newRssi value  
- android.net.wifi.STATE_CHANGE - networkInfo / RSSI  
  
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.  
  
VENDOR RESPONSE  
  
The vendor (Google) classified this issue as Moderate and assigned  
CVE-2018-9581 to track this issue. No fix is available yet, 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 -  
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 locating users via RSSI values,  
including the following papers:  
- "Algorithms for Location Estimation Based on RSSI Sampling." (2008);  
Papamanthou C., Preparata F.P., Tamassia R.; In: Fekete S.P. (eds)  
Algorithmic Aspects of Wireless Sensor Networks. ALGOSENSORS 2008.  
Lecture Notes in Computer Science, vol 5389. Springer, Berlin,  
Heidelberg  
- "Comparison of RSSI techniques in Wireless Indoor Geolocation,"  
(2012); G. A. Naik, M. P. Khedekar, M. Krishnamoorthy, S. D. Patil and  
R. N. Deshmukh,; 2012 NATIONAL CONFERENCE ON COMPUTING AND  
COMMUNICATION SYSTEMS, Durgapur, 2012, pp. 1-5.  
- "Theoretical facts on RSSI-based geolocation,"; (2012) J. S. Picard  
and A. J. Weiss; 2012 IEEE 27th Convention of Electrical and  
Electronics Engineers in Israel, Eilat, 2012, pp. 1-5.  
- "Adversarial WiFi Sensinga (2018); Yanzi Zhu, et al; arXiv:1810.10109;  
  
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  
  
  
`