chromebook

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

nightwatchcyber Advisories , , ,

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

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

nightwatchcyber Advisories , , ,

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

Research: Hacking the Chromebook (Part 1)

nightwatchcyber Research ,

By now many in the bounty arena have heard of Google’s new Chromebook bounty totalling $100,000. While not as big as the infamous Zerodium one million bounty for iOS9, this one comes with a crucial difference – it is being offered by the manufacturer of the device in question instead of a security company with possibly shady customers.

In this series of posts, we will explore our attempts to break into the Chromebook, beginning with some basic exploration of the Chromebook while in guest mode.

What is the Bounty For?

According to Google, the bounty is being offered for the following:

participants 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)

This would preclude any kind of physical access methods, or exploits delivered while logged in using a non-guest account. This also would preclude exploits delivered while in developer mode which provides shell access.

Background

Chromebooks run Chrome OS, which is essentially a stripped down version of Linux with Chrome browser as its main interface. Most apps are either Chrome apps, or Chrome extensions, and can be installed from the app store. There is a main Linux user named “chronos” that runs most of the underlying system, with some specialized users for certain services, and individual user accounts are located in the “/home/chronos/u-XXXXX/” folder including the guest user. A fuller description of the security system can be found in this paper from MIT .

While in guest mode, only default apps/extensions are available, and new ones cannot be installed. Another important point is that guest mode uses tmpfs file system for storage, which is RAM based and does not persist.

Poking Around Chrome

At this initial stage, we have explored the Chromebook to see what possible avenues of attack may be possible. We started with looking at the Chrome browser itself. Here are some interesting things we found:

  • Chrome is running in incognito mode
  • Only the default plug-ins are loaded (chrome://plugins/) including: Chrome’s PDF Reader, Native Client, Widevine decryption, and Adobe Flash. This is basically the same as Chrome out of the box on other platforms. Screenshot below:
chromebook1.png
  • No extensions are listed (chrome://extensions/), HOWEVER, that isn’t really true. If you try to open certain files, it is clear from the URLs that there are hidden extensions installed. We did not look into listing them, but they should be easy to find on the Chromium source. Screenshot below:
chromebook2.png
  • Extensions cannot be installed via the Chrome store, OR manually by downloading and dragging them in. For the Chrome store, the install button is simply not there. For manual installs, message “Installation is not enabled” comes up.
  • Access and changes to flags is allowed (chrome://flags), but does not persist across reboots. Flags can be changed and take effect by restarting Chrome for the current session.
  • History, bookmarks, caches, etc. do not persist across reboots.

Download and Opening Files

You can download all files and open some of them:

  • Safe browsing is enabled and checks downloads against a blacklist.
  • Downloaded Office files (doc, xls, etc) open via an extension inside the browser that looks like a scaled down version of Google Docs
  • Downloaded Image files open in the browser but also can be opened with Gallery
  • Downloaded text and HTML files open in the browser
  • Downloaded sound and video files open via a dedicated sound and video player apps that pop up above the taskbar
  • Needless to say that possibly malicious files like shell scripts, JS files, etc. do not open although we haven’t explored any possible holes there yet
  • There is no editor of any kind in Guest mode, full users can install apps to edit
  • File URLs are used for local files and it is possibly to introspect SOME directories (/tmp and /media)

Poking around the Desktop

Chromebooks also have a desktop of sorts which is really Chrome underneath. There isn’t much available other than Chrome itself, the Files application and Help.

  • The Files application gives access to the Downloads folder and any USB drives that get plugged in. It can rename, move and delete files and folders but not much more than that. Because it is restricted to the Downloads folder only, it is not possible to see the rest of the files system. It is also clear via the Files application that RAM is being used, since the space available is less than 1 GB versus much more for regular users (no quotas are enabled).
  • As mentioned earlier, Gallery, video and sound players are available by clicking on the right files.
  • There is screenshot functionality available via a hot key
  • Lower right corner provides access to settings such as Bluetooth, WiFi, etc.
  • There is a very basic and restricted shell (crosh) available by pressing CTRL-ALT-T but it is another Chrome extension with very few commands (in developer mode, it provides access to bash). Below is an example of top running in the shell (interestingly enough the W command in top can write files):
chromebook3.png

Possible Avenues of Attack

First of all, as stated above, the guest user’s home directory is using tmpfs, which does not persist. This would mean that we would need actually execute some code that would persist in the system OUTSIDE that directory and come back upon reboot. Here are some possible entry points:

  • Default Chrome plugins – via malicious PDFs, Flash files, video/audio with DRM or native client apps
  • Default extensions – these can be targeted via malicious files for the Office extension. Another possibility is to use Chrome’s built-in developer tools but that would probably be out of scope.
  • Chrome browser itself
  • Javascript APIs
  • Video/Sound can target the built-in audio or video player
  • Malicious images can target Gallery
  • The various settings available to the user can be exploited across multiple users
  • Possibly via other processes running in the system and their users

Second, even if we manage to break in and execute code, it would still only execute in the context of the chronos user. We would then need to figure out how to elevate privileges to reach root access.

Third, we would need to figure out how to get past verified boot. Google outlines some potential ways this may happen ONCE attacker has gained super-user privileges.

Conclusion

In this post, we have briefly explored some of the pieces of the Chromebook software with the eye towards exploitation. In followup posts, we hope to continue digging in further.