It is fun to report those things to Google Project Zero and then find that people on that side obviously do not understand that security bypasses are... well... security issues.
full submission reproduced below, just in case they radar-disappear the item... duping items is apparently what Project Zero does so that the items disappear from Google results...
---
PREAMBLE
Thank you for an amazingly solid looking ChromeOS. Happy that I picked up a nice little Acer CB3-111, thought about plonking GalliumOS/QubesOS or heck OpenBSD on it, but with the TPM model and the disk wiping, not going to.
Just wanted to note this discovery so that you are aware of it and hopefully can address the problem as it would improve the status quo. Keep up the good work!
Greets,
Jeroen Massar <jeroen@massar.ch>
VULNERABILITY DETAILS
By disabling Wireless on the login screen, or just not being connected, only a username and password are required to login to ChromeOS instead of the otherwise normally required 2FA token.
This design might be because some of the "Second Factors" (SMS/Voice) rely on network connectivity to work and/or token details not being cached locally?
But for FIDO U2F (eg Yubikeys aka "Security Key"[1]) and TOTP no connectivity is technically needed (outside of a reasonable time-sync). The ChromeOS host must have cached the authentication tokens/details though to know that they exist.
The article at [2] even mentions "No connection, no problem... It even works when your device has no phone or data connectivity."
First the normal edition:
- Take a ChromeOS based Chromebook (tested with version mentioned above)
- Have a "Security Key" (eg Yubikeo NEO etc) enabled on the Google Account as one of the 2FA methods.
- Have Wireless enabled
- Login with username, then enter password, then answer the FIDO U2F ("Security Key") token challenge
All good as it should be.
Now the bad edition:
- Logout & shutdown the machine
- Turn it on
- Disconnect the wireless from the menu (or just make connectivity otherwise unavailable)
- Login with username, then password
- Do NOT get a question about Second Factors, just see a ~5 second "Please wait..." that disappears
- Voila, logged in.
That is BAD, as you just logged in without 2FA while that is configured on the account.
Now the extra fun part:
- Turn on wireless
- Login to Gmail/GooglePlus etc, and all your credentials are there, as that machine is trusted and cookies etc are cached.
And just in case (we are now 'online' / wireless is active):
- Logout (no shutdown/reboot)
- Login with username, password.... and indeed asks for 2FA now.
Thus showing that toggling wireless affects the requirement for 2FA.... and that is bad.
EXPECTED SITUATION
- Being asked for a Second Factor even though one is not "online".
As now you are walking through say an airport with no connectivity, and even with the token at home, just the username and password would be sufficient to login.
SIDE NOTE
For the Google Account (jeroen@massar.ch) I have configured:
- "strong" password
and as Second Factors:
- FIDO U2F: Two separate Yubikeys configured
- TOTP ("Google Authenticator") configured
- SMS/Voice verification to cellphone
- Backupcodes on a piece of paper in a secure place.
Normally, when connected to The Internet(tm), one will need username(email), password and one of the Second Factors. But disconnect and none of the Second Factors are needed anymore.
SIDE NOTE2
The Google Account password changer considers "GoogleChrome" a "strong" password.... might want to check against a dictionary that such simple things cannot be used, especially as 2FA can be bypassed that easily.....
Likely they’ll just ban your account for some "vulnerability abuse" or "hacking", even though they themselves said just days ago "this is not a vulnerability".
I’ve seen it before, reported a vulnerability to Google, got a "not a vulnerability, not eligible for anything" back, published the PoC on my website, and Google subsequently blacklisted my domain, IP range, and everything.
https://bugs.chromium.org/p/chromium/issues/detail?id=718831 https://bugs.chromium.org/p/chromium/issues/detail?id=696378 etc...
It is fun to report those things to Google Project Zero and then find that people on that side obviously do not understand that security bypasses are... well... security issues.
full submission reproduced below, just in case they radar-disappear the item... duping items is apparently what Project Zero does so that the items disappear from Google results...
--- PREAMBLE
Thank you for an amazingly solid looking ChromeOS. Happy that I picked up a nice little Acer CB3-111, thought about plonking GalliumOS/QubesOS or heck OpenBSD on it, but with the TPM model and the disk wiping, not going to.
Just wanted to note this discovery so that you are aware of it and hopefully can address the problem as it would improve the status quo. Keep up the good work!
Greets, Jeroen Massar <jeroen@massar.ch>
VULNERABILITY DETAILS
By disabling Wireless on the login screen, or just not being connected, only a username and password are required to login to ChromeOS instead of the otherwise normally required 2FA token.
This design might be because some of the "Second Factors" (SMS/Voice) rely on network connectivity to work and/or token details not being cached locally?
But for FIDO U2F (eg Yubikeys aka "Security Key"[1]) and TOTP no connectivity is technically needed (outside of a reasonable time-sync). The ChromeOS host must have cached the authentication tokens/details though to know that they exist.
The article at [2] even mentions "No connection, no problem... It even works when your device has no phone or data connectivity."
[1] https://support.google.com/accounts/answer/6103523?hl=en [2] https://www.google.com/intl/en/landing/2step/features.html
VERSION
Chrome Version: 59.0.3071.35 dev Operating System: ChromeOS 9460.23.0 (Official Build) dev-channel gnawty Blink 537.36 V8 5.9.211.16
REPRODUCTION CASE
First the normal edition: - Take a ChromeOS based Chromebook (tested with version mentioned above) - Have a "Security Key" (eg Yubikeo NEO etc) enabled on the Google Account as one of the 2FA methods. - Have Wireless enabled - Login with username, then enter password, then answer the FIDO U2F ("Security Key") token challenge
All good as it should be.
Now the bad edition: - Logout & shutdown the machine - Turn it on - Disconnect the wireless from the menu (or just make connectivity otherwise unavailable) - Login with username, then password - Do NOT get a question about Second Factors, just see a ~5 second "Please wait..." that disappears - Voila, logged in.
That is BAD, as you just logged in without 2FA while that is configured on the account.
Now the extra fun part: - Turn on wireless - Login to Gmail/GooglePlus etc, and all your credentials are there, as that machine is trusted and cookies etc are cached.
And just in case (we are now 'online' / wireless is active): - Logout (no shutdown/reboot) - Login with username, password.... and indeed asks for 2FA now.
Thus showing that toggling wireless affects the requirement for 2FA.... and that is bad.
EXPECTED SITUATION
- Being asked for a Second Factor even though one is not "online".
As now you are walking through say an airport with no connectivity, and even with the token at home, just the username and password would be sufficient to login.
SIDE NOTE
For the Google Account (jeroen@massar.ch) I have configured: - "strong" password
and as Second Factors: - FIDO U2F: Two separate Yubikeys configured - TOTP ("Google Authenticator") configured - SMS/Voice verification to cellphone - Backupcodes on a piece of paper in a secure place.
Normally, when connected to The Internet(tm), one will need username(email), password and one of the Second Factors. But disconnect and none of the Second Factors are needed anymore.
SIDE NOTE2
The Google Account password changer considers "GoogleChrome" a "strong" password.... might want to check against a dictionary that such simple things cannot be used, especially as 2FA can be bypassed that easily.....