A couple of days ago, Amos, also known as
@fasterthanlime,
experienced a password extraction event by hackers and as a result was left out of pocket by a couple of hundred Euros as a result. However, this attack was facilitated by the fact that the attackers were able to turn off two-factor authentication on Google's passwords.google.com without needing to confirm by the two-factor authentication mechanism, which defeats the point of enabling two-factor authentication. In addition, the subsequent investigation suggested that passwords stored in passwords.google.com can be easily extracted leading to a bigger question regarding the security of the service. InfoQ has
reached out to Google's security engineer who responded and will update this article when we receive further information.
The entry point to the vulnerability was an exposed remote VNC-like session, which gave attackers access to the macOS windowing system that was being used at the time. The service was using NoMachine, which exposed the port on 4000 to the internet with no authentication, which as Amos notes, was their mistake.
However, the bigger problems arose because Amos had used Safari on macOS to log into their account. Safari 'helpfully' remembered the password with auto-fill, and this is what let hackers subsequently access Amos' details.
Since Amos had recently logged in on that machine, Google had cached a recent session token on their machine (presumably with a 2FA check). This allowed the attackers, some time later, to re-use the cached password in Safari auto-fill, to refresh the session token, and with it, the power to disable 2FA on the account. This is
apparently by design in that if you're logged into a computer, and you know the password, then you must surely be the same person who isn't attacking your machine at the moment. If you've logged on recently, you have a blessed session, and all you need is a single factor – the password – to refresh the blessed session token, and you are good to go.
This would seem security 101, but apparently in order to make it easier for users, and to avoid them having to type their 2FA token in frequently, it is sufficent to have logged in recently to a machine to satisfy to Google that you can make security level changes, if you know the password. In other words, it's 2FA, unless you're logged on, in which case it's 1FA. The argument is: well, you logged on to your machine, it's
bound to be secure, right?
@mrisher: @fasterthanlime Maybe terminology difference? Touch/face unlock in addition to the password? I fully admit there are gaps on screen locks — shoulder surfing, eyes closed, etc — but it’s still a second factor, right?
@mrisher: @fasterthanlime Correct, in our model, device lock is a second factor in addition to the cloud password. Do you disagree?
Well yes, I disagree. The whole point of 2FA is that should be, well, a second factor authentication. If you can change the security settings with just a single password, that's called 1FA. The fact that this is the advice of a
security engineer at Google makes it all the more worrying.
Furthermore, once the attackers had disabled 2FA, they were able to attack the session remotely, and used passwords.google.com to extract a number of passwords that had been autoamtically saved by Chrome in the past. Amos told InfoQ that he had been a happy user for 1Password for a while, and that these passwords captured by Chrome were old or expired services, but a sufficient number of them were still valid that the attackers managed to order some hardware and run up some other bills that Amos is now facing having to pay off.
In fact, it wasn't until a service with real 2FA notified Amos in the middle of the night that he noticed something was wrong.
The other aspect that came out of Amos' investigation was that passwords.google.com seems to store your passwords in an encrypted from
that uses your google login password. This allows anyone who knows your password – say, because Safari auto-filled it for you – to be able to decrypt your cloud passwords. This is similar to Apple's keychain manager, which allows you to decrypt the contents of the keychain provided you know the keychain password; so Chrome's synchronisation of passwords via the central service and any Chrome instance can access them and decrypt the password. But it's also what Google's
Password Checkup service uses; it can use your account password to decrypt all of the passwords in your account to determine if they've been hacked, or are particularly weak. This allows an attacker, with control of a machine's session, to use the
online psasword manager to easily extract passwords. It is possible to opt out of this by using a "choose as passphrase" encryption password, which disables the password checker functionality but prevents Google from being able to decrypt your passwords online.
