0day.today - Biggest Exploit Database in the World.
![](/img/logo_green.jpg)
- We use one main domain: http://0day.today
- Most of the materials is completely FREE
- If you want to purchase the exploit / get V.I.P. access or pay for any other service,
you need to buy or earnGOLD
Administration of this site uses the official contacts. Beware of impostors!
![We DO NOT use Telegram or any messengers / social networks!](/img/no_telegram_big.png)
Please, beware of scammers!
- Read the [ agreement ]
- Read the [ Submit ] rules
- Visit the [ faq ] page
- [ Register ] profile
- Get [ GOLD ]
- If you want to [ sell ]
- If you want to [ buy ]
- If you lost [ Account ]
- Any questions [ admin@0day.today ]
- Authorisation page
- Registration page
- Restore account page
- FAQ page
- Contacts page
- Publishing rules
- Agreement page
Mail:
Facebook:
Twitter:
Telegram:
We DO NOT use Telegram or any messengers / social networks!
You can contact us by:
Mail:
Facebook:
Twitter:
Telegram:
We DO NOT use Telegram or any messengers / social networks!
Android RSSI Broadcast Information Disclosure Vulnerability
Author
Risk
![](/img/risk/critlow_2.gif)
Security Risk Medium
]0day-ID
Category
Date add
CVE
Platform
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/ # 0day.today [2024-06-30] #