Security Problem with Google’s 2-Step Authentication

Hi Folks,

A couple of months ago I tried to get one of my findings accepted to Google’s Security Reward program. This is my second try, my first one was accepted, but this time they found the report wasn’t eligible. Since the reward is off the table I am free to discuss my observations publicly and I feel more people should be aware of the issue.  So, let’s go.

Below there’s a copy of the conversation I had with Google regarding the flaw I pointed out. To sum it up, it’s about their 2-step authentication (aka OTP) scheme. They have implemented a design option that yields some security issues, some of with I have pointed out in my communications with Google.
I found out they have a time window of 10 minutes in which any of the 20 OTP passwords are valid. They do this in order to better assist users with out of sync (aka. late) watches. This means that, if you have a very precise watch, it’s likely that you will have 10 minutes before your generated OTP password gets invalidated. Also, whenever you enter a valid OTP password, the time window before it  gets invalidated altogether. This is done to avoid interception, in the sense that if you have been able to login, all past OTP passwords that were generated before the one you have just used are deemed useless in case they are intercepted by an attack. This protects you well unless the attacker can intercept OTP passwords in the future, which is impossible, or is it? As a correction, I have suggested invalidating all the time window (all the 20 OTPs), or at least they could synchronize accounts.google.com’s watch with the user’s at some point, like some banks do.

I’ve prepared a very simple PoC for Firefox to exemplify my point: http://ximen.es/gmail/

Google stated they think they have the right balance between security and usability, which I disagree. So, the PoC should be still working (since they haven’t change anything). In order to understand the PoC better, please refer to the contents of the conversation below.

Thanks,

Pablo Ximenes

 

CONVERSATION:

Vulnerability Report – Applying for Reward – 2-Step Authentication in accounts.google.com

Pablo Ximenes

Jun 5

to Google
Dear Google Security Team,I have stumbled on a vulnerability that can circumvent the Two-Way Authentication scheme used in accounts.google.com.As I am aware of, the mechanism is intended to give users the easy of mind, while authenticating themselves, that:1) If an attacker intercepts my password (using MITM, for instance) he will still be unable to login to my account, because he doesn´t own my 2-step auth token.
2) If the attacker captures my OTP, he will be unable to use it because whenever I use an OTP in asuccessfull login attempt, the OTP automatically invalidates itself (avoiding replay).
3) If an attacker pretends I entered the wrong OTP (again using MITM) and gives me an error message so I enter a second OTP so the first OTP, acquired by attacker, remains unused, I still can rely on the fact that by using the latest issued OTP,  all other issued OTPs will automatically be invalidated. This way the attacker will remain with an invalid OTP.
4) etcWell, though an informal investigation I was able to determine that your policy for timeframing the accepted OTPs is 10 minutes. This means that I issue an OTP, using a accurate watch, I have up to 10 minutes to use it before it becomes invalid. I can only imagine this policy is intended as a solution for late and advanced watches that are out of sync with precise atomic time.The problem with this policy is that by allowing the system to accept OTPs in the “future” (or in the past, depending on the reference point), the system creates an attack vector that can be used by malicious users.  Using any form of MITM, an attacker could intercept the user´s authentication request, capturing both password and OTP and issue an error mesage to the user saying the OTP is wrong. The user will enter a second attempt OTP. Instead of using the second attempt OTYP, the attacker will store the second attempt OTP and continue with user authentication through the firtly entered OTP. This will leave the attacker with an unsed OTP that is good for up to aproximately 9 minutes. This will break the premisse number 3 from the list I cited in the begining of this report and if applyied more than once in a roll, will give the attacker two valid OTPs that could be used to completely deactivate 2-Step verification in the victim´s account. I consider it severe.

I have taken the liberty of assembling a modest PoC in http://ximen.es/gmail that examplifies this problem. (please bear in mind that this example could be vastly improved if it were to be weaponized)

If the PoC isn´t clear enough, I am available for answering any questions.

A solution to this isssue would be changing the current policy for accepting OTPs. Instead of invalidating only OTPs that are timed before the one that was used, it would be a good practice to invalidade all the time frame, meaning all OTPs before + All OTPs in the next X minutes, where X would be 10 minutes for maximum security (as your timeframe is 10 minutes). X could be lower, but a save value is yet to be found. You guys could balance security and usability to find it.
Another simpler solution that would counter only the particular way to use MITM in my PoC (that uses Michal´s approache) is to extend the use of GALX cookie (together with GALX POST form variable) to https://accounts.google.com/SmsAuth as well (the page users enter their OTP).

So, I leave it to the judges to give me feedback on this. I supose this should be considered an authentication bypass vulnerability on accounts.google.com with regards to the Vulnerability Rewards Program, but I will wait for your feedback.

Thanks in advance for your consideration,

Pablo Ximenes

Google Security security@google.com

Jun 5

to me
Thanks for contacting Google’s security team. This is an automatic response to let you know that we’ve received your message. If you’ve identified a security vulnerability within any of Google’s services, systems, or networks, we’ll investigate as soon as possible and follow up with you shortly.If you aren’t reporting an application security vulnerability, you won’t receive a response and we’ll be unable to take action on your message. Here’s a few links that will hopefully help you find a solution to your issue:* For Android security issues, please contact security@android.com or visit http://developer.android.com/resources/faq/security.html#issue
* For Chrome security issues, please visit http://dev.chromium.org/Home/chromium-security/reporting-security-bugs
* For account hijackings, please go here (http://goo.gl/E3Ii3) for Youtube, and here  (http://goo.gl/Jb3at) for Google Accounts (including Gmail).
* Other problems with account security in Gmail (http://goo.gl/Jcac), Youtube (http://goo.gl/iIKAe) or Checkout (http://goo.gl/GPehn).
* Requests to remove content in Search (http://goo.gl/nhm6R), Streetview (http://goo.gl/JWwp), Maps (http://goo.gl/zys9l), Youtube (http://goo.gl/RuuQF), Orkut (http://goo.gl/YVAUU), Blogger (http://goo.gl/bBHrD), or any other product (http://www.google.com/security.html).
* Report malware (http://goo.gl/dR12) or phishing (http://goo.gl/6Q9Y) sites, or inappropriate or malicious advertisements (http://goo.gl/PKpIu).
* Scams, including fake lotteries and job offers (http://goo.gl/OhRr).
* You’ve received someone else’s email (http://goo.gl/GeCe).For anything else, please check the Google Support (http://www.google.com/support/) page.Regards,
The Google Team
Pablo Ximenes

Jun 5

to Google

I forgot to mention, the PoC was designed for firefox.

It might work on other browsers, but almost certain not chrome.

Regards,

Pablo
Em 05/06/2012 13:56, “Pablo Ximenes” <pablo@ximen.es> escreveu:

>
> Dear Google Security Team,
>
>
> I have stumbled on a vulnerability that can circumvent the Two-Way Authentication scheme used in accounts.google.com.
>
> As I am aware of, the mechanism is intended to give users the easy of mind, while authenticating themselves, that:
>
> 1) If an attacker intercepts my password (using MITM, for instance) he will still be unable to login to my account, because he doesn´t own my 2-step auth token.
> 2) If the attacker captures my OTP, he will be unable to use it because whenever I use an OTP in asuccessfull login attempt, the OTP automatically invalidates itself (avoiding replay).
> 3) If an attacker pretends I entered the wrong OTP (again using MITM) and gives me an error message so I enter a second OTP so the first OTP, acquired by attacker, remains unused, I still can rely on the fact that by using the latest issued OTP,  all other issued OTPs will automatically be invalidated. This way the attacker will remain with an invalid OTP.
> 4) etc
>
>

> Well, though an informal investigation I was able to determine that your policy for timeframing the accepted OTPs is 10 minutes. This means that if I issue an OTP, using a accurate watch, I have up to 10 minutes to use it before it becomes invalid. I can only imagine this policy is intended as a solution for late and advanced watches that are out of sync with precise atomic time.

Pablo Ximenes

Jun 6

to adammein, Google

Dear Adam,

Sorry to disturb you with this, but I haven’t heard anything as feedback to my report yet and Its been almost 24 hours (which is kindda long compared to my previois experience). Is there any problem?

I am very sorry If crossed any lines with this email.

Thanks for everything,

Pablo

Em 05/06/2012 18:53, “Pablo Ximenes” <pablo@ximen.es> escreveu:

Google Security Team security@google.com

Jun 6

to me, adammein
Hey Pablo,We got this and are looking into it! Sorry for the delay but we will get
back to you shortly!Regards,
KevinOriginal Message Follows:
————————
From: Pablo Ximenes <pablo@ximen.es>
Subject: Re: Vulnerability Report – Applying for Reward – 2-Step
Authentication in accounts.google.com
Date: Wed, 6 Jun 2012 12:36:12 -0300

Google Security Team security@google.com

Jun 7

to me, adammein
Ok Pablo,I investigated this and you are correct RE: the 10 minute window. I would
however term your attack as phishing rather them MITM as you are not
intercepting requests between the client and the legitimate server. I
would not consider this a security risk although I do appreciate you
bringing it up. It is something that we were aware of already and was a
design decision for reasons I can’t get into.

Regards,
KevinOriginal Message Follows:
————————

From: “Google Security Team” <security@google.com>
Subject: Re: [#1043898468] Vulnerability Report – Applying for Reward –
2-Step  Authentication in accounts.google.com
Date: Wed, 06 Jun 2012 18:31:05 -0000

Pablo Ximenes

Jun 7

to Google, adammein

Thanks for replying.

Phishig was only a way I used to implement some sort of request interception (aka MITM) in order to exemplify the vector. Any form of MITM would do: malware on the victms pc, dns hijacking, etc. I myself used Michals switching example.

Any way, my point of view is that there’s a correctable flaw. Maybe you were aware.of the design, but not of the security problem it causes. Adittionally, I proposed a viable solution which is to invalidate all the 20 (10 minutes times 2) OTPs after a successful login attempt instead of invalidating only the the OTP used to authenticate and the ones timed before it. That would require little effort, Id assume. I read somewhere that if you as little as open a bug request based on anything.from the report, the.reporter is at least credited in the HoF. Since there’s no mention of that from your part I’d assume you.dont.plan to change anything with regards to my report.

Well, since the reward is off the table, can I at least blog about it?

PS: Sorry for the typos, Im using a tablet. Android. 🙂

Em 07/06/2012 18:42, “Google Security Team” <security@google.com> escreveu:

Pablo Ximenes

Jun 7

to Google, adammein

PS: BTW, The OTP scheme is known as a way to counter exactly these kind of phishing attacks you saw on my example. “Dont worry so much about phishing, cause they can get your passwotd, but they will never get a usable OTP if you were able to login to your account.”

Timing is one big problem for offline token based OTP schemes, and Google’s solution to that causes a serious security problem.

Em 07/06/2012 19:28, “Pablo Ximenes” <pablo@ximen.es> escreveu:

Google Security Team security@google.com

Jun 8

to me, adammein
Pablo,Thank you for your note, I appreciate your concerns however we feel we
have the right balance between security and usability, unfortunately this
issue is not eligible for the VRP.

Regards,
Kevin

Original Message Follows:
————————

From: Pablo Ximenes <pablo@ximen.es>

Subject: Re: [#1043898468] Vulnerability Report – Applying for Reward –
2-Step
Authentication in accounts.google.com

Date: Thu, 7 Jun 2012 19:56:56 -0300

Pablo Ximenes

Jun 8

to Google

Ok, I got that. I wanna know about me.bloging about it. 🙂

Is that OK?

Em 08/06/2012 14:17, “Google Security Team” <security@google.com> escreveu:

Google Security Team security@google.com

Jun 8

to me

Sure, it’s a free world (ideally anyway) please feel free to publish
whatever you like.

Regards,
Kevin
Original Message Follows:
————————
From: Pablo Ximenes <pablo@ximen.es>
Subject: Re: [#1043898468] Vulnerability Report – Applying for Reward –
2-Step
Authentication in accounts.google.com

Date: Fri, 8 Jun 2012 14:18:54 -0300

 

Esta entrada foi publicada em Security. Adicione o link permanente aos seus favoritos.

4 respostas para Security Problem with Google’s 2-Step Authentication

  1. Pingback: Security Problem with Google ’s 2-Step Authentication - NMAP Scan!

  2. Juan disse:

    2-Factor Authentication for me wins every day. It is deffinatly better than the other option one-factor. I feel suspicious when I am not asked to telesign into my account by way of 2FA, it just feels as if they are not offering my sites enough protection. Just the fact that we are still living in a password world is annoying. Almost everything is still only password protected. But ultimately the fact is passwords (strong or not) do not replace the need for other effective security control.

  3. Joao Lucas disse:

    Eu praticamente trabalho com o Google Security Team.
    Na verdade voce que me ajudou com meu primeiro report para o VRP do Google a um ano atrás 🙂

    Acabei engrenando nessa de “bug hunter” e hoje sou muito próximo ao time de segurança deles, tendo contato quase que diário para submeter algum relatório.

    A verdade é que eles são um dos melhores times de segurança que eu já conheci, se não o melhor, comparado a Apple, Microsoft, Paypal, Facebook, eBay, Adobe, LinkedIn, RedHat e Mozilla, times de segurança os quais já tive o privilégio de trabalhar em conjunto, mas eles (Google) são cabeças duras quando querem e não cedem jamais.

    Sua preocupação é válida, com certeza (parabéns pela PoC), mas com minha experiência no VRP (aproximadamente 220 relatórios, porém com apenas 163 aceitações) eu te digo uma coisa, se sua vulnerabilidade, por mais engenhosa que seja, necessitar que o usuário digite sua senha, em um site ‘phishing’ ou no próprio site original, porém estando a máquina infectada, esquece, eles não vão aceitar.

    A falha não pode necessitar da senha do usuário (exceto claro no momento do login usual), do manuseamento pelo usuário de tokens anti-XSRF, de softwares desatualizados (salvo raras exceções como IE8) e da necessidade do usuário digitar códigos javascript (self-XSS).

    Quando algum dos fatores acima está incluso no relatório ele será rejeitado e eles NUNCA voltam atrás.

    Esse é o defeito deles. Até hoje não aceito eles ignorarem ‘open redirectors’. Em um teste que fiz na faculdade, com colegas de engenharia de computação, tive sucesso em mais de 80% dos casos de ataques de phishing usando o redirecionamento para dizer que a senha estava incorreta e pedir que o usuário a redigitasse.

    Boa sorte no seu próximo report e que eles sejam menos intransigentes hehehehe.

    Abraço.

  4. pablo
    disse:

    Oi Lucas,

    Tudo bom? Bem… na verdade eu acho que concentrei meu relatório em algo não tão importante. De fato, continuei essa mesma conversa com a Google apontando um outro detalhe que não tinha dado importância no relatório e atualmente minhas observações estão em análise por eles. Estou aguardando novo posicionamento deles, mas como você sabe não posso dar detalhes sob risco de desqualificar para o VRP. Aviso quando tiver novidades.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *