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

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

pic3 pic4 pic6

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:

pic7

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:

pic1  pic2

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

Media Coverage

Gmail for Android Allows Screenshots in Confidential Mode

Google recently added confidential mode for Gmail that allows the sender to restrict how their email gets by the recipients including forbidding printing, etc. However, it looks like that Gmail for android still allows screenshots to be taken for such emails. To replicate, try the following:

  1. Send a confidential email to another Gmail user.
  2. Open the email, press Power + Volume Down. A screenshot will be taken.

The underlying reason is because the Gmail 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. For example, Chrome for Android prohibits screenshots when browsing in anonymous mode on Android.

We did file a bug report with Google and here is their response:

We can not prevent someone from taking a photograph of their phone, using a second camera for example. Preventing taking photos of the content is not part of the feature.

References:
Google bug report # 112838515

Android OS Didn’t use FLAG_SECURE for Sensitive Settings [CVE-2017-13243]

Summary

Android OS did not use the FLAG_SECURE flag for sensitive settings, potentially exposing sensitive data to other applications on the same device with the screen capture permissions. The vendor (Google) fixed this issue in 2018-02-01 Pixel security update. Google has assigned CVE-2017-13243 to track this issue.

Details

Android OS is a mobile operating systems for phones and tablets developed by Google. The OS has multiple screens where sensitive information maybe shown such as the device lock screen, passwords in the WiFi settings, pairing codes for Bluetooth, etc.

FLAG_SECURE is a special flag available to Android developers that prevents a particular screen within an application from being seen by other application with screen capture permissions, having screenshots taken by the user, or have the screen captured in the “Recent Apps” portion of Android OS. We have published an extensive post last year discussing this feature is and what it does.

During our testing of various Google mobile applications, we found that the lock screen, password entry screen for WiFi, and the screen for entering pairing codes for Bluetooth devices did not use FLAG_SECURE to prevent other applications for capturing that information. By contrast other Google applications like Android Pay and Google Wallet use this flag to prevent capture of sensitive information. Exploiting this bug requires user cooperation in installing a malicious app and activating the actual screen capture process, thus the likelihood of exploitation is low.

To reproduce:
1. Lock the device, OR go to WiFi settings and try to add a network, or try to pair a Bluetooth device.
2. Press Power and volume down to capture screenshot.
3. Confirm that a screenshot can be taken.

All testing was done on Android 7.1.2, security patch level of May 5th, 2017, on Nexus 6P. Vulnerable versions of Android include: 5.1.1, 6.0, 6.0.1, 7.0, 7.1.1, 7.1.2 and 8.0.

Vendor Response

This issue was responsibly reported to the vendor and was fixed in the 2018-02-01 Pixel bulletin. The vendor assigned CVE-2017-13243 to track this issue.

Bounty Information

This issue satisfied the requirements of the Android Security Rewards program and a bounty was paid.

References

Android ID # A-38258991
CVE ID: CVE-2017-13243
CVSS scores: 7.5 (CVSS v3.0) / 5.0 (CVSS v2.0)
Google Bug # 38254822
Google Pixel Bulletin: 2018-02-1

Credits

Advisory written by Yakov Shafranovich.

Timeline

2017-05-12: Initial report to the vendor
2017-06-15: Follow-up information sent to the vendor
2017-06-19: Follow-up communication with the vendor
2018-01-02: Vendor communicates plan to patch this issue
2018-01-29: Bounty reward issued
2018-02-01: Vendor publishes a patch for this issue
2018-05-24: Public disclosure / advisory published

Multiple Instances of Download Protection Bypass in Google’s Chrome

Summary

We have found several instances of files bypassing the download protection offered by Google’s Chrome browser. All of these have been reported to the vendor, and whichever were accepted by the vendor were fixed in Chrome M51 and M52.

Background

The Chrome and Chromium browsers are an open-source based web browser offered by Google. Among it’s features it includes a safety feature that detects unsafe downloads to protect the user. This feature works in multiple ways but is controlled via a file in Chrome’s source code (“download_file_types.asciipb”) which defines several options based on what the file extension of the downloaded files are:

  • Platform/OS
  • What kind of warning to show the user
  • Whether this file type is an archive
  • Whether the file can be opened automatically by clicking on it in the download area
  • Whether a ping get sent back to Google for every download of this type (FULL), some downloads (SAMPLED) or not sent at all. This checksum check is used to check against a server-side blacklist of known bad files.

The Chrome Rewards bug bounty program includes a separate section covering download bypass that was added in March of 2016. To be eligible, it needs to be on a supported platform (MacOS or Windows), be dangerous by being clicked and not send a full ping back to Google. In December of 2016, the scope of this was changed to only include file extensions already in the source code for Chrome.

As part of our testing in scope of this program, we tested all file extensions that are included in a default on MacOS v10.11 (El Capitan)  and Windows 2012 R2 / 7 Enterprise. This advisory lists all of the bypasses that we located, reported to the vendor, and the status of whether they were accepted and fixed, or rejected. Most of these were reported prior to the scope change in December 2016, and included patches whenever feasible.

Details

The following extensions were reported but were rejected as being out of scope and were not fixed:

  • ChromeOS: APK
  • Linux: AFM, PFA, TIF
  • MacOS: APP, CONFIGPROFILE, DFONT, ICC, INTERNETCONNECT, MOBILECONFIG, NETWORKCONNECT, OTF, PREFPANE, PROVISIONPROFILE, QTZ, SAFARIEXTZ, SAVER, TTF, WEBBOOKMARK, WEBLOC
  • Windows: CAMP, CDMP, DESKTHEMEPACK, DIAGCAB, DIAGPKG, GMMP, ICC, IMESX, MOV, MSU, OTF, PFB, PFM, PRF, RAT, QDS, QT, RDP, SEARCH-MS, THEMEPACK, THEMES, TTC, TTF, WCX

The following extensions were reported, confirmed to be dangerous and fixed, all on MacOS (the underlying issue has been described in a separate blog post here).

  • AS, CDR, CPGZ, DART, DC42, DISKCOPY42, DMGPART, DVDR, IMG, IMGPART, ISO, MPKG, NDIF, PAX, SMI, SPARSEBUNDLE, SPARSEIMAGE, TOAST, UDIF, XIP

These issues were fixed in Chrome M51 and M52.

References

Chrome Bug Reports (rejected): 671382, 671385, 624224, 596342, 605386, 601255, 601250, 600910, 600615, 600609, 600606, 600601, 600597, 600592, 600590, 600587, 600581, 599880

Chrome Bug Reports (fixed): 596354, 600613, 600907, 600908

Bounty Information

The issues that were fixed qualified for the Chrome Rewards security bounty program and a bounty has been paid.

Credits

Advisory written by Yakov Shafranovich.

Timeline Summary

2016-03-20: First report submitted
2016-03 to 2016-12: multiple other reports submitted, and fixed applied
2016-12-06: Last report submitted
2018-02-26: Public disclosure

 

RCE in DuoLingo’s TinyCards App for Android [CVE-2017-16905]

Summary

The TinyCards Android application provided by DuoLingo can be injected with malicious content by an MITM attacker. Because this application is a web-app framed in an Android WebView, this can lead directly to remote code execution (RCE) within the app. The root cause is lack of SSL being used on app startup when the initial web content is loaded into the WebView.

The vendor has fixed this issue in v1.0 (version code 10) that was released via Google Play Store on November 20th, 2017 and users should install the latest version. MITRE has assigned # CVE-2017-16905 to track this issue.

Vulnerability Details

TinyCards is a flashcard application for preparing for tests and memorizing vocabulary. It is made by DuoLingo, which provides a platform for learning new languages. While monitoring network traffic of a test device running Android, we observed that during application startup an initial HTTP call is made to a non-HTTPS site, which then redirects to an HTTPS version. Further research into the application revealed that the application is essentially a thin browser wrapper using Android’s WebView around a web application loaded remotely.

Because the initial call is done without HTTPS, it is possible for an MITM attacker to intercept this traffic and inject their own content.  Since this is a web app, this can result in remote code execution within the application since all the content is web based.

Screenshots of the captured traffic and relevant source code:

screenshot1screenshot2

Steps To Replicate (on Ubuntu 17.10)

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 tinycards.duolingo.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
echo powned >index.html

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

7. Open the app on the Android device and observe injected content.

All testing was done on v1.0 (version code 9)  of the Android application using a Linux host running Ubuntu v17.10 and Android test device running Android v7.

Vendor Response and Mitigation

To fix this issue, the vendor has changed the initial URL for web content being loaded within the app to use SSL. The vendor has fixed this issue in v1.0 (version code 10) that was released via Google Play Store on November 20th, 2017 and users should install the latest version.

Bounty Information

DuoLingo doesn’t currently offer bounties, however, this bug has fulfilled the requirements of Google Play Security Reward Program and a bounty has been paid from that program.

References

CVE-ID: CVE-2017-16905
HackerOne Reports: 281605 (DuoLingo) and 293444 (Google Play Rewards)

Credits

We would like to thank the vendor for the quick turnaround and fix for this  vulnerability. Text of the advisory written by Yakov Shafranovich.

Timeline

2017-10-21: Report opened with the vendor via HackerOne to clarify scope
2017-11-06: Technical details of vulnerability provided to the vendor via HackerOne
2017-11-07: Report triaged and being reviewed by the vendor
2017-11-20: Vendor patched the issue and asked for testing of the fix
2017-11-20: Fix confirmed, communication regarding disclosure
2017-11-28: Report submitted to Google’s Play Rewards program via HackerOne
2017-11-29: Rejection received due to scope, follow-up communication with Google regarding scope
2017-12-04: Follow-up conversation about disclosure with Google and the vendor
2017-12-05: Disclosure requested from DuoLingo via HackerOne
2018-01-04: Public disclosure on HackerOne, and publication of this advisory

ChromeOS Doesn’t Always Use SSL During Startup [CVE-2017-15397]

Summary

ChromeOS did not use SSL in all network calls originating from the ChromeVox component during startup. This could potentially have allowed an MITM attacker to inject content into ChromeOS or crash the device. The vendor (Google) fixed this issue in Chrome M62. Google has assigned CVE-2017-15397 to track this issue.

Details

ChromeOS is the operating system developed by Google that runs on ChromeBook devices. It is build on top of Linux and around the Chrome browser.

By monitoring network traffic using a proxy we noticed that some network calls originating from the ChromeVox component did not use SSL. These calls occured during the startup process before a user logged in. Because these calls did not use SSL, it would be possible for an MITM attacker, in theory, to either inject their own content into ChromeOS, or crash the device by sending a very large packet. We did not conduct any follow-up testing to confirm either of these two possibilities.

To reproduce:
1. Setup a proxy with WiFi.
2. Switch ChromeOS device to use proxy.
3. Restart the device and on the login screen enable ChromeVox.
4. Observe calls to HTTP without SSL.

All testing was done on an Acer ChromeBook, running Chrome version 51.0.2704.106 *stable) and ChromeOS version 8172.62.0 (stable).

Vendor Response

This issue was responsibly reported to the vendor via the Chromium bug tracker. The vendor fixed this issue in ChromeOS release M62 and assigned CVE-2017-15397 to track it.

References

CVE ID: CVE-2017-15397
Chromium Bug # 627300

Bounty Information

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

Credits

Advisory written by Yakov Shafranovich.

Timeline

2016-07-12: Initial report to the vendor
2017-09-18: Issue patched by the vendor
2017-10-26: CVE assigned by the vendor
2018-01-01: Public disclosure

Chrome for Android Didn’t Use FLAG_SECURE for Credit Card Prefill Settings [CVE-2017-5082]

Summary

Chrome for Android did not use the FLAG_SECURE flag in the credit card prefills settings, potentially exposing sensitive data to other applications on the same device with the screen capture permissions. The vendor (Google) fixed this issue in Chrome M59. Google has assigned CVE-2017-5082 to track this issue.

Details

Chrome for Android is a version of the Chrome browser for Android platforms. It used to be part of the Android OS, but is now a separate application deployed by Google through the Google Play store. Chrome has a credit card pre-fills section in settings where users can store credit card information that can be used to pre-fill certain forms.

FLAG_SECURE is a special flag available to Android developers that prevents a particular screen within an application from being seen by other application with screen capture permissions, having screenshots taken by the user, or have the screen captured in the “Recent Apps” portion of Android OS. We have published an extensive post last year discussing this feature is and what it does.

During our testing of various Google mobile applications, we found that the credit card prefills section in Chrome for Android did not use FLAG_SECURE to prevent other applications for capturing that information. By contrast other Google applications like Android Pay and Google Wallet use this flag to prevent capture of sensitive information. Exploiting this bug requires user cooperation in installing a malicious app and activating the actual screen capture process, thus the likehood of exploitation is low.

To reproduce:
1. Open Chrome.
2. To go Settings, Autofill and payments, Credit Cards.
3. Tap on “Add credit card”.
4. Press Power and volume down to capture screenshot.
5. Confirm that a screenshot can be taken.

 

All testing was done on Android 7.1.2, security patch level of May 5th, 2017, on Chrome v58.0.3029.83 (stable).

Vendor Response

This issue was responsibly reported to the vendor via the Chromium bug tracker. The vendor fixed this issue in Chrome release M59 and assigned CVE-2017-5082 to track it.

References

CVE ID: CVE-2017-5082
Chromium Bug # 721579

Credits

Advisory written by Yakov Shafranovich.

Timeline

2017-05-11: Initial report to the vendor
2017-05-15: Issue patched by the vendor
2016-05-30: CVE assigned by the vendor
2016-06-05: Fixed version released
2016-07-16: Request for public disclosure sent to the vendor
2017-07-26: Permission to disclose received
2017-07-27: Public disclosure

Advisory: Google’s Android News and Weather App Doesn’t Always Use SSL [CVE-2017-9245]

Summary

Google News and Weather Application for Android does not use SSL for some server calls, exposing authentication tokens (OAuth) to anyone monitoring the network. It is not clear if the tokens belong to the user’s account or a service account. The vendor (Google) fixed the issue in v3.3.1 of the application and users should install the latest version. MITRE has assigned CVE-2017-9245 to track this issue.

Details

The Google News and Weather application for Android is an application developed by Google which aggregates news from multiple sources. This application was originally included as part of the stock Android operating system but was separated into its own application around August 2014.

While performing network level testing of various Google applications, we discovered that some of the calls made by the application to Google’s server did not use SSL. Furthermore, analysis of the captured traffic showed that an authentication token (OAuth) was sent as part of those calls, thus exposing it to an attacker that is monitoring the network. It is not clear from our testing whether this token belonged to the user using the application, or was some sort of a service account.

We also did not test earlier versions of the application, so it is also unclear whether this issue affects older versions of Android where this is part of the stock operating system.

To replicate the issue on v3.1.4:

  1. Install the application and open it.
  2. Flick away the application.
  3. Setup the proxy without an SSL certificate and point the Android device to it.
  4. Go back to the application and select any news feed, and then click on a news article from a site that doesn’t use SSL.
  5. Go back to the proxy and observe captured traffic.

All testing was done on Android 7 and application v3.1.4. Network captures were performed using an on-device proxy (PacketCapture) without a trusted SSL certificate.

Screenshots below – note that sensitive data has been blanked out:

s2   s3

Vendor Response

This issue was responsibly reported to the vendor and fixed in version 3.3.1 which was released in late June 2017. It is not clear if older versions of Android that include this as part of the OS are affected and/or fixable.

References

CVE ID: CVE-2017-9245
News and Weather App: Google Play Store

Bounty Information

This bug satisfied the rules of the Google Vulnerability Reward Program (VRP) program and a bounty was paid.

Credits

Advisory written by Yakov Shafranovich.

Timeline

2017-05-11: Initial report to the vendor
2017-05-11: Report triaged by the vendor and bug filed
2017-05-26: Bounty decision received from vendor
2017-06-29: Fixed version released by the vendor
2017-07-12: Fixed version tested to confirm the fix
2017-07-12: Draft advisory sent to vendor for comment
2017-07-18: Public disclosure

Advisory: Google I/O 2017 Android App Doesn’t Use SSL for Some Content [CVE-2017-9045]

Summary

Google I/O 2017 Application for Android does not use SSL for retrieving some information to populate the app. This would allow an MITM attacker to inject their own content into the application. The vendor (Google) fixed the issue in v5.1.4 of the application.

Details

The Google I/O 2017 application for Android is a companion app produced by Google for their annual I/O conference that takes place in May. This particular version was produced for I/O conference in May of 2017.

While performing network level testing of various Google applications, we discovered that the content for the application did not use SSL. This would allow an MITM attacker to inject their own content into the application using a method like ARP spoofing, DNS takeover, etc.

To replicate the issue on v5.0.3:

  1. Install the application
  2. Setup the proxy without an SSL certificate and point the Android device to it.
  3. Go to the application and select the “feed” option (middle icon on the bottom).
  4. Go back to the proxy and observe captured traffic.

Screenshots of the feed before and after the data is loaded:

Screenshot_20170516-205242  Screenshot_20170516-220959

Network traffic captures appear as follows:

Screenshot_20170511-202707   Screenshot_20170511-202713

The specific URL was “http://storage.googleapis.com/io2017-festivus/manifest_v1.json” which then causes the device to download additional URLs. The following URLs are downloaded:

This can also be seen in the source code of the I/O 2016 application on Github as follows:

google_github

All testing was done on Android 7, Google I/O version 5.0.3. Network captures were performed using an on-device proxy (PacketCapture) without a trusted SSL certificate.

Proof of Concept

All testing was done on Ubuntu v17.04 and Android 7:

  1. Install nginx – “sudo apt-get install nginx”.
  2. Install dnsmasq – “sudo apt-get install dnsmasq”
  3. Find out the IP address of your computer via ifconfig.
  4. Add the IP address mapping to the hosts file: “192.168.1.x  storage.googleapis.com”
  5. Create and download the files from Google to the NGINX directory:
    1. cd /var/www/html
    2. mkdir io2017-festivus
    3. cd io2017-festivus
    4. wget http://storage.googleapis.com/io2017-festivus/manifest_v1.json
    5. wget http://storage.googleapis.com/io2017-festivus/blocks_v4.json
    6. wget http://storage.googleapis.com/io2017-festivus/map_v4.json
    7. wget http://storage.googleapis.com/io2017-festivus/session_v1.70.json
  6. Modify “blocks_v4.json” to add your content.
  7. Install version 5.0.3 of the application on the Android device.
  8. Change DNS on the device to point to the Ubuntu machine.
  9. Open the app, skip sign in, and on the main screen choose the feed icon.
  10. Switch back to the first section and observe injected content:

Screenshot_20170516-223446

Vendor Response

This issue was responsibly reported to the vendor and fixed in version 5.1.4.

References

CVE ID: CVE-2017-9045

Google I/O 2016 source code: https://github.com/google/iosched

Bounty Information

Pending…

Credits

Advisory written by Yakov Shafranovich.

Timeline

2017-05-11: Initial report to the vendor
2017-05-11: Report triaged by the vendor and bug filed
2017-05-13: Fixed version released by the vendor
2017-05-16: Draft advisory sent to vendor for comment
2017-05-17: Public disclosure

Advisory: ChromeOS / ChromeBooks Persist Certain Network Settings in Guest Mode

Summary

Certain network settings in ChromeOS / ChromeBooks persists between reboots when set in guest mode. These issues have been reported to the vendor but will not be fixed since the vendor considers them to be WAI (Working As Intended). These attacks require physical access to the device in order to execute them but future avenues of research looking at network vectors should be undertaken.

Background

ChromeOS is the operating system developed by Google that runs on ChromeBook devices. It is build on top of Linux and around the Chrome browser. The OS has a guest mode which runs Chrome in anonymous mode on top of a temporary guest account. The data within that account is stored in RAM and is erased upon reboot. However, it appears from our research that some settings, especially network related ones, reside elsewhere and do persist between reboots.

Our original interest in this area was prompted by a standing $100,000 USD bounty offered by Google to an exploit “that can compromise a Chromebook or Chromebox with device persistence in guest mode (i.e. guest to guest persistence with interim reboot, delivered via a web page)”. While we have not been able to deliver these attacks via a web page, we did achieve some persistence in network settings in guest mode via physical access. Further research is needed to achieve remote exploitation.

Details

The following network settings were observed in guest mode as persisting between reboots if the change is made by a guest user while the Chromebook is in guest mode:

  • Details of WiFi network such as password, authentication, etc.
  • Preferred WiFi network
  • DNS settings on the currently connected WiFi network

To replicate, do the following:

  1. Login as a guest into the Chromebook.
  2. Click on settings, and:
    • Try to remove a WiFi network and add a new preferred network;
    • Or change settings for an existing network;
    • Or change DNS servers for an existing network
  3. Reboot, re-enter guest mode and observe settings persisting

The following settings only persist when changes are made on the login screen. If a user logs in as a guest user or a Google account, this goes away:

  • Proxy settings

To replicate:

  1. Start the Chromebook until Login prompt appears. DO NOT login.
  2. Click on settings, change the proxy settings in the current network.
  3. Reboot and go back to the login screen, confirm settings for proxy do persist.
  4. Login to an existing account or as guest, check settings again and observe that proxy settings are now greyed out.

Implications of this are most important in scenarios where a shared Chromebook is used in a public environment such as a library, school, etc. Using these attacks, a malicious user can modify the settings on a public ChromeBook to point to malicious DNS (like DNS Changer virus) or malicious WiFi hotspot, and subsequent users will not realize that their sessions are affected.

We have not been able to achieve remote exploitation, but an existing private Chrome API (chrome.networkingPrivate) would provide access to these settings even in guest mode. This API is not normally available via the Web, so an additional browser exploit would need to be chained to the issues described here to achieve a complete exploit. Another thing to note is that while guest mode normally runs under a RAM disk which is erased after the device is rebooted, the network settings appear to reside elsewhere within the device. That can be used as a further area of possible attacks.

All testing was done in 2016 on the following system, and it is not clear if other ChromeBook hardware is affected:

  • Device: Acer C7 Chromebook
  • Chrome Versions: 49.0.2623.95, 49.0.2623.111 and 51.0.2704.106 (stable)
  • ChromeOS Versions: 7834.60.0, 7834.66.0 and 8172.62.0 (stable parrot)

Vendor Response

The vendor has rejected all of these issues as WAI – working as intended. The vendor has provided the following explanation:

First of all, note that there are quite a few ways for network settings to propagate into sessions. DNS and proxy (per issue 627299) settings are just two of them. You can go further and just join the device to a malicious WiFi network that it’ll pick up again after rebooting (this is possible from the login screen, no need to start a guest session). Edit: There are more issues filed for these cases, cf. issue 600194 and issue 595563.

If we were to crack down on propagation of (malicious) network settings into sessions, we’d take quite a UX hit, as we’d have to prompt the user to reconfirm their network settings whenever the device is connected to a network that user hasn’t yet approved (and it’s quite unlikely for this to be effective). The alternative of only allowing the device owner to configure networks doesn’t fly either as it has the potential to lock out legitimate users.

Regarding programmatic injection of network settings, there is (1) device policy, which is already properly locked down (i.e. only open to enterprise admins, and settings aren’t Chrome-writable) and (2) chrome.networkPrivate, which is used by the settings screens and (3) direct DBus communication to shill. #2 and #3 require a Chrome browser exploit.

Even if malicious network config gets picked up by a session, it’s not entirely game over – TLS will flag maliciously redirected requests (assuming the attacker doesn’t have forged certs). There’s a chance of information leakage via insecure connections and/or observing the network though.

Given the above, the currently implemented trade-off is reasonable, so I’ll close this (and related bugs) as WAI. I’ve also updated the chromiumos sites page mentioned above – networks were never part of the protected device settings anyways, so the cited half-sentence was inaccurate from the start AFAICT.

Additional comments from the vendor:

It may be worth noting, as per your original interactions, that the current behavior is by design.  Networks may be marked shared or unshared by users, but networks added before sign-in are necessarily global in nature.  The default behavior is one meant to minimize unintended side effects — such as one user changing the proxy on another using the same shared network.  Beyond that, there is very little difference between connecting to a malicious upstream network and connecting to a non-malicious upstream network.  The security of the OS and its communications, using TLS, should remain unperturbed.  Guest mode itself does not provide stronger transit privacy guarantees by default as there are few default options for offsetting normal information leakage, such as DNS resolution or IP traffic.

References

Chrome Bugs: 595563, 600194, 600195 and 627299
Chrome Rewards bounty details: see here
Private networking API: see here

Credits

Advisory written by Yakov Shafranovich.

Timeline

2016-03-17: Bug 595563 reported
2016-03-21: Bug 595563 rejected
2016-04-03: Bugs 600194 and 600195 reported
2016-07-12: Bug 627299 reported
2016-08-09: Bugs 600194, 600195, 627299 rejected and opened to the public
2016-10-02: Bug 595563 opened to the public
2017-03-08: Copy of this advisory provided to Google for comment
2017-04-07: Final comments received from Google
2017-04-09: Public disclosure