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

Google’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.

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:

"...an 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.

An 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.