https://wwws.
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:
https://bugs.chromium.org/p/
https://bugs.chromium.org/p/
https://bugs.chromium.org/p/
https://bugs.chromium.org/p/
Chrome Rewards bounty details:
https://www.google.com/about/
Private networking API:
https://developer.chrome.com/
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
Komentarų nėra:
Rašyti komentarą