Google patches bug that allows attackers to slip past two-factor authentication

Filed Under: Featured, Google

Bear and snakesGoogle's two-step verification, according to the company's ad campaign, isn't merely a bear guarding your home. It's a snake pit behind the bear guarding your home.

Unfortunately, it turns out, application-specific passwords allow attackers to bounce right past the bear and to hop over the vipers.

According to Duo Security, attackers could - until a fix was issued last Thursday, that is - bypass Google accounts' two-step login verification, reset a user's master password, and gain full profile control, just by capturing a user's application-specific password (ASP).

Duo Security first spotted the ASP bug in July 2012, Adam Goodman said in a blog posting on Monday.

Google pushed out a fix that prevents these ASP-initiated hijackings last Thursday.

The bug's existence points to how challenging it can be to set up wide-scale, comprehensive deployment of strong authentication, Goodman writes.

To make two-step verification usable for all, and to glue it onto what was already a complicated, sprawling ecosystem, all without breaking any moving parts, Google engineers had to compromise in a few spots.

That's how ASPs came to be.

When you turn on two-step authentication, Google asks you to create a separate ASP for any applications that don't support logins using the verification system. That includes most client applications not using a web-based login, Goodman says, including:

  • Email clients that use IMAP and SMTP (such as Apple Mail or Thunderbird),
  • Chat clients that communicate over XMPP (Adium, Pidgin, etc.),
  • Calendar applications that sync using CalDAV (iCal, etc.), and
  • Some of Google's own apps, which, at least in initial incarnations, required an ASP to, for example, enable Chrome's sync features or to set up a Google account on an Android device (most have since shifted to methods similar to OAuth [an open standard for authentication]).

When you first log in using a new application or device, you get an authorization prompt - including 2-step verification - in a webview. Once you're in, Google’s service gives you a limited-access token to authenticate the device or application in the future.

Google 2 step verification

The differences between OAuth tokens and ASPs are important here, Goodman says. Whereas OAuth tokens are created automatically, ASPs are a "thoroughly manual affair," requiring a user to log in to her Google account settings to create one, and to then manually input it into a given application.

Therein lies the crux, Goodman writes:

"OAuth tokens use a flexible authorization model, and can be restricted to accessing only certain data or services in your account. By contrast, ASPs are - in terms of enforcement - not actually application-specific at all!"

Thus, if you cook up an ASP to use in, say, an XMPP chat client, that same ASP can be used to read your mail over IMAP, or to seize your calendar events with CalDAV.

In fact, Goodman says, an ASP will get you just about anywhere you want to go in Googlelandia, neatly enabling you to slip right past the bear/snake pit combo of two-step verification:

" ASP can be used to log into almost any of Google’s web properties and access privileged account interfaces, in a way that bypasses 2-step verification!"

The crux of this was that an attacker exploiting the bug was able to hop straight to account recovery options, modify the email address required therein, and reset the victim's master password.

Google logoAn attacker could even access the settings for two-step verification, from which he could create or edit ASPs or turn it off altogether.

Google's February 21 fix is now identifying how users are authenticating - i.e., via two-step verification or via the sidestep of MergeSession URL that an attacker might employ with the bug.

Now, Google will only let you in to security-sensitive account settings if you pass through the two-step verification: no more sidestepping via MergeSession URL.

Should our faith in Google's two-factor verification be challenged?

Nah. Two-factor is and was still a good, solid security system, Duo says, even before Google patched this glitch.

That's because two-factor mitigates the possibility of attack in the face of users doing bad things, such as reusing the same passwords between sites, using weak passwords, or getting tricked into handing over passwords at phishing sites.

As it is, Google generates ASPs itself and doesn't intend users to memorize them, Goodman says, so such passwords are pretty unlikely to be spread around on other sites or punched into phishing sites.

Still, it's a relief that the ASP glitch has been fixed, given potential scenarios in which attackers could have exploited these overly powerful passwords.

, , , ,

You might like

4 Responses to Google patches bug that allows attackers to slip past two-factor authentication

  1. Nick Beacham-Watts · 949 days ago

    I can use my plasma tv with a bluRay player (both Panasonic to watch Utube and other internet material but lately I cannot use any Google related material because, even though my google credentials are accurate the IP seen by google is not that public IP of my ISP but that of Panasonic, so I get a message that it cannot connect. I then get messages from Google warning me that someone is trying to hack my account. I am sure this is happening to others but I find contacting anyone for help is so labyrinthine I just give up.

    Whereas if I connect my Android Galaxy GSII (rooted with 4.1 ) via HDMI, I can do anything I please. It is their loss ultimately and no I shall not be updating my hardware anytime soon.

  2. Mick · 948 days ago

    Why should I provide Google with my mobile phone number? I use Google apps only on my Nexus 7 (Wifi only). I don't want to give Google another item to sell and make profit on just because they're not able to offer een better security solution.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

About the author

I've been writing about technology, careers, science and health since 1995. I rose to the lofty heights of Executive Editor for eWEEK, popped out with the 2008 crash, joined the freelancer economy, and am still writing for my beloved peeps at places like Sophos's Naked Security, CIO Mag, ComputerWorld, PC Mag, IT Expert Voice, Software Quality Connection, Time, and the US and British editions of HP's Input/Output. I respond to cash and spicy sites, so don't be shy.