A Google 2-step verification vulnerability

Early this year Google started rolling out their new two-factor authentication procedure, which they refer to as 2-step verification. On their corporate blog they provided a few hints on why they were rolling out a new authentication procedure — mentioning risks associated with password reuse and phishing attacks. 2-step verification is now widely deployed, by June it was available in 150 countries, and in 40 different languages.

Of course, I took interest in how the two-step verification was designed and I discovered a couple of design issues. In addition I discovered a security flaw that qualified for Google's vulnerability reward program, so I engaged in a responsible disclosure process with Google. Now they've fixed the bug, my reward has been donated to charity, and I've received my 19 bytes of fame, so I guess it's time to blog about this. I'll focus on the security bug here, and blog about the design issues later. I need to do some investigation to see whether Google fixed any of them or not, as they reported that they were re-evaluating some of their design decisions.

If you're unfamiliar with how the two-step verification works, see Google's video below (borrowed from Getting started with 2-step verification).

Now, straight to the point.


The never ending cookie
After you've enabled two-step verification, you'll have to supply a verification code once you've entered your username and password. Note that you can select "Remember this computer for 30 days".

When clicking "Verify", the code would be posted back to Google, and the following response would set a cookie configured to live for 30 days in the browser. Here's the actual cookie used to demonstrate the security bug (I've truncated its value for readability, and other obvious reasons):

Set-Cookie: SMSV=ADHTe-...; Expires=Sat, 02-Apr-2011 14:03:26 GMT; Path=/accounts; Secure; HttpOnly

As you can see, it was set to expire on Saturday, April 2. Here's the note I sent to Google do describe the problem:

I took interest in the option to "remember" the two-step verification for 30 days. Naturally, I've been looking at the cookies used for this purpose, and noticed the cookie set when supplying a valid OTP:

POST /accounts/SmsAuth?persistent=yes HTTP/1.1

Set-Cookie: SMSV=ADHTe-...; Expires=Sat, 02-Apr-2011 14:03:26 GMT; Path=/accounts; Secure; HttpOnly

Today, I reused the above mentioned cookie, which was set to expire in april, four months ago. The cookie still works like a charm, I'm not required to provide a fresh OTP on login, as long as the cookie is set.

"Today" was August 6, so the cookie could definitely be used also after its expiration date. So what went wrong? The problem was that the cookie itself either:

1. Did not include its lifetime as part of its value, enabling a server side validation of its validity. 
2. It did include its lifetime, but it was not validated on the server.

The effect was that the lifetime of the cookie was controlled by the browser, and not server side, yielding an "eternal" cookie. This was not Google's intention, and they reported that they "moved quickly" to fix this.

What was the risk?
If we consider the threats that Google specifically mention on their blog, this was not a severe risk. In the case of password reuse across sites, this vulnerability does not reduce the usefulness of the two-step verification. An attacker who stole your password from another site would still need to obtain one of your verification codes (or a verification cookie) to be able to access your account.

The same goes for an attacker that has obtained your username and password through a phishing attack, she would still need to obtain a verification code to compromise your account.

This vulnerability let a (malicious) user circumvent the re-authentication mechanism in 2-step verification. After 30 days, the user must prove yet again that she possesses the mobile phone required to log in to the Google account, assuring that it's still the correct person who's logged in. Re-authentication could be circumvented since it was enforced by the browser. Now it is enforced on the server instead.

And how did Google react?
I have to say, the Google security team was very professional throughout the process. Their e-mails were polite and forthcoming — they were quite open about some of the design choices they'd made. Apparently there was one person assigned to my particular case, which made the follow ups more personal. Thanks to both Adam on the Google security team, and the 2-step verification team!

So, that was the story of my first vulnerability reward-winning bug. In a week or two I'll blog about some design issues that, in my opinion, might have a much larger impact on security.