[Off topic] Google Authenticator article

alexgrutza
Contributor III

Interesting read about how a company believes Google Authenticator Sync was to blame for customer breach, at least in part during their transition to a new SSO platform

https://www.bleepingcomputer.com/news/security/retool-blames-breach-on-google-authenticator-mfa-clou...

--
CISSP | LinkedIn | @Phyxiis
11 REPLIES 11

Kim_Nilsson
Admin Moderator

Well, if you let yourself be fished... then you have already lost the game.

Useless to point fingers after they failed the first rule of never giving out your credentials to third-parties.

"Third-parties" includes anything that isn't yourself, or the actual service the credentials are for.

If you input them into a third-party app or service, then you are the only one to blame.

--
https://wheretofind.me/@NoSubstitute

Unfortunately not all of our users can be trusted not to click phishing links, or even helpdesk folks not to be tricked (arstechnica..../a-phone-call-to-helpdesk-was-likely-all-it-took-to-hack-mgm/). 

I think they have a valid point (definitely speculation at this point as to the true cause), that if an attacker gets access to someone who has the Google Auth Sync set up, that they may also have full access to all of that persons Google Auth codes for other systems.

--
CISSP | LinkedIn | @Phyxiis

Something true to be said about back in the day learning that a good security practice is to not have your direct route all provided by the same vendor (or even version of firmware/software)

Example: Cisco ASA XYA firewall, Cisco Switches, Cisco USC appliance, Cisco VoIP appliance...

More likely to be an easier target if a compromised function on the Firewall happens to also work on every other device all the way to the end-data...

Having your Google account (Gmail, Drive, etc.) also be the password/TOTP/etc. "vault" which is synced? Similar shortcoming in security it would seem from my perspective. Your Google account compromised now possibly opens up your entire Google portfolio to the attacker.

@Kim_Nilsson "that's why they should use passkeys" - I can here it now lol

--
CISSP | LinkedIn | @Phyxiis

😎

--
https://wheretofind.me/@NoSubstitute

rdnixon
Contributor

So this is largely mitigated by 2 step verification, content filtering that block malicious websites and context aware access. On Windows a robust Applocker policy and attachsurfacereduction rules will also help.  The default blocking of any form of Google login page will also help - whitelist only.

However, a well crafted web hook attack from your own country, could in theory, still cause you issues even if the above is in place.

panderson
Contributor III

I don't think Google had any blame.  When they said how it happened (below) it's pretty obvious.

"The attack used a URL impersonating Retool's internal identity portal and was launched during a previously announced migration of logins to Okta.

While most of the targeted employees ignored the phishing text message, one clicked the embedded phishing link that redirected to a fake login portal with a multi-factor authentication (MFA) form.

After signing in, the attacker deepfaked an employee's voice and called the targeted IT team member, tricking them into providing an additional MFA code, which allowed the addition of an attacker-controlled device to the targeted employee's Okta account."

I would agree that the Google Auth wasn't the problem, or the point of entry. I think that was a targeted and directed (probably insider to some degree knowing the transition of platforms and being more common apparently) attack. I think when it comes to the companies internal systems, that's where they're blaming Google Auth Sync for syncing the OTP across devices.

I think they're saying (and maybe it is/was/will be a policy to not tell employees to not use Google Auth Sync now for this company) that if the account was compromised, and they used a different OTP authenticator platform (or just didn't sync to their Google account), their internal systems wouldn't have been compromised as well because the attackers wouldn't have access to them all in one account. I think that's the blame they're putting on Google. I don't think that's a difficult ask to have Google give Admins the ability to enable/disable the Sync functionality for their organization.

 

Edit: the end-user shouldn't have provided the additional MFA code. However, they did, so then the attacker would have been able to add the Google Auth Sync to a hostile device and sync all codes in the future. 

--
CISSP | LinkedIn | @Phyxiis

panderson
Contributor III

Is it possible to have Google ask for two different authentications like Yubikey and/or Google Authenticator, and something else (SMS, voice call, etc.)? 

 

No.

But I think there's a way to force 2FA even when using a Passkey, so accomplishing almost the same.

--
https://wheretofind.me/@NoSubstitute

Not Google related but more SSO platform related (not Google SSO), the system may be able to be configured to ask for two. 

For example our SSO platform requires MFA to sign into the platform, and each app could be individually configured to require an additional MFA prompt (possibly SMS or Yubi) to access it.

--
CISSP | LinkedIn | @Phyxiis

BrandonB
New Contributor II

TOTP apps syncing is always a slippery slope, but as noted in this post, they are not the initial source of compromise. Besides Google, password managers Lastpass and Bitwarden also have TOTP apps embedded in their tools. Are there safer ways to backup your TOTP apps? Yes. Before Google Authenticator synced (yes, I use it), I backed up my codes to an old phone (no cell service) that lives in a drawer at home. Some print out the QR codes and put in a binder. This is a good example of ease of use vs security.