How Google Authenticator made one company’s network breach much, much worse

A security company is calling out a feature in Google’s authenticator app that it says made a recent internal network breach much worse.

Retool, which helps customers secure their software development platforms, made the criticism on Wednesday in a post disclosing a compromise of its customer support system. The breach gave the attackers responsible access to the accounts of 27 customers, all in the cryptocurrency industry. The attack started when a Retool employee clicked a link in a text message purporting to come from a member of the company’s IT team.

“Dark patterns”

It warned that the employee would be unable to participate in the company’s open enrollment for health care coverage until an account issue was fixed. The text arrived while Retool was in the process of moving its login platform to security company Okta. (Okta itself disclosed the breach of one of its third-party customer support engineers last year and the compromise of four of its customers’ Okta superuser accounts this month, but Wednesday’s notification made no mention of either event.)

Most of the targeted Retool employees took no action, but one logged in to the linked site and, based on the wording of the poorly written disclosure, presumably provided both a password and a temporary one-time password, or TOTP, from Google authenticator.

Shortly afterward, the employee received a phone call from someone who claimed to be an IT team member and had familiarity with the “floor plan of the office, coworkers, and internal processes of our company.” During the call, the employee provided an “additional multi-factor code.” It was at this point, the disclosure contended, that a sync feature Google added to its authenticator in April magnified the severity of the breach because it allowed the attackers to compromise not just the employee's account but a host of other company accounts as well.

“The additional OTP token shared over the call was critical, because it allowed the attacker to add their own personal device to the employee’s Okta account, which allowed them to produce their own Okta MFA from that point forward,” Retool head of engineering Snir Kodesh wrote. “This enabled them to have an active GSuite session on that device. Google recently released the Google Authenticator synchronization feature that syncs MFA codes to the cloud. As Hacker News noted, this is highly insecure, since if your Google account is compromised, so now are your MFA codes.”

The post is unclear on a variety of things. For instance, by “OTP token,” did Kodesh mean a one-time password returned by Google authenticator, the long string of numbers that forms the cryptographic seed used to generate OTPs, or something else entirely? In an email seeking clarification, Kodesh declined to comment, citing an ongoing investigation by law enforcement.

Despite the ambiguity, what Kodesh seems to be saying is this: The employee was tricked into sharing a TOTP twice, first to log in to the employee’s Okta account and again to enroll Google Authenticator on an attacker device into the employee’s Okta account. Somewhere along the way, the attacker somehow also logged in to the employee’s Google Workspace account. From then on, the Google Authenticator feature allowed the attacker to generate TOTPs for all accounts accessible by the employee, including possibly VPNs, support portals, or other things.

Kodesh continued:

Unfortunately Google employs dark patterns to convince you to sync your MFA codes to the cloud, and our employee had indeed activated this “feature”. If you install Google Authenticator from the app store directly, and follow the suggested instructions, your MFA codes are by default saved to the cloud. If you want to disable it, there isn’t a clear way to “disable syncing to the cloud”, instead there is just a “unlink Google account” option. In our corporate Google account, there is also no way for an administrator to centrally disable Google Authenticator’s sync “feature”. We will get more into this later.

We use OTPs extensively at Retool: it’s how we authenticate into Google and Okta, how we authenticate into our internal VPN, and how we authenticate into our own internal instances of Retool. The fact that access to a Google account immediately gave access to all MFA tokens held within that account is the major reason why the attacker was able to get into our internal systems.

Getting access to this employee’s Google account therefore gave the attacker access to all their MFA codes. With these codes (and the Okta session), the attacker gained access to our VPN, and crucially, our internal admin systems. This allowed them to run an account takeover attack on a specific set of customers (all in the crypto industry). (They changed emails for users and reset passwords.) After taking over their accounts, the attacker poked around some of the Retool apps.

There’s a good argument to be made that Kodesh used the Google Authenticator issue to deflect attention away from Retool’s culpability in the compromise. (A separate and completely unverified claim—that the call used an AI-generated deepfake simulating the voice of an actual Retool IT manager—may be a similar ploy to distract readers as well.)

Deflection with a point

Retool’s biggest offense was using any type of MFA that relies on the secrecy of TOTPs alone. As has been obvious for years, these codes can be phished with only slightly more effort required than phishing a password alone. Forms of MFA compliant with the industry-wide FIDO2 specification are immune from credential phishing attacks like the one that hit Retool. The reason: The standard requires a hardware-based security key such as a smartphone or physical device that connects by USB or Bluetooth and is in close proximity to the device logging in. Kodesh acknowledged that FIDO2 provides resilience to such attacks but didn’t say why Retool didn’t use it or when the company might start.

That said, Kodesh is right that Google Authenticator syncing is much more lenient than syncing provided by other authenticator apps. The Authy Authenticator, for instance, doesn’t sync by default, and when a user turns syncing on, codes are end-to-end encrypted. When stored on Authy corporate parent Twilio’s servers, the codes are in the form of an E2EE blob. Without the password, the codes are unrecoverable.

What’s more, enrolling a new device in Authy requires both (1) access to either an already-enrolled device or control of the phone number associated with the Authy account and (2) the password that encrypts the codes. Authy also allows users to flip a switch that prevents any new devices from being enrolled. These protections are a key selling point for the app.

In an email, a Google representative didn’t challenge Kodesh’s description of the Authenticator backup feature and contended it provides a net positive to user security.

“We believe that, for most users, the benefits of cloud syncing outweighs the risks,” the representative wrote. “Consumers typically have no ‘administrator’ to go back to when they lose access to their OTPs, and they often have to fall back to more insecure methods when they inevitably switch devices. We do recognize that in certain enterprise environments it might be preferred to have the OTP codes stored purely locally, which is why Google Authenticator offers users the ability to use Google Authenticator without syncing codes to a Google Account.”