Re: [Full-disclosure] Google Accounts Security Vulnerability

["Thor (Hammer of God)" <thor@xxxxxxxxxxxxxxx>]

That's what I said.  :D



Timothy "Thor"  Mullen
www.hammerofgod.com
Thor's Microsoft Security Bible


-----Original Message-----
From: full-disclosure-bounces@xxxxxxxxxxxxxxxxx 
[mailto:full-disclosure-bounces@xxxxxxxxxxxxxxxxx] On Behalf Of Mike Hearn
Sent: Wednesday, May 16, 2012 1:38 PM
To: full-disclosure@xxxxxxxxxxxxxxxxx
Cc: mgray@xxxxxxxxxxxx
Subject: Re: [Full-disclosure] Google Accounts Security Vulnerability

Hi there full-disclosure,

I wanted to respond to the recent post covering the Google real time 
anti-hijacking system and explain a bit more about what this system is and how 
it works. For background I am the tech lead of the relevant team, and Daniel 
Margolis works on it with me.

Firstly, I'd like to note that despite what Michael may have observed with his 
account, performing a programmatic login does not whitelist for web access. 
Most of the time if you would be challenged via the web then logging in via POP 
or IMAP would also be denied, and result in a notification email about the 
blocked login. See here for what this looks like:

  
http://blog.plaxo.com/2012/05/google-account-%E2%80%9Csuspicious-activity%E2%80%9D-next-steps/

There are a small number of edge cases that can cause this rule to break. 
Unfortunately although Daniel asked for it, Michael has not provided the name 
of the account in question so we cannot check which one it was. To understand 
why this is not a problem it's important to understand the design parameters of 
this security system.

The real-time antihijack system was created to solve a specific problem, 
namely, spammers/scammers turning up at our front door with large numbers of 
valid passwords. I gave a public talk at the RIPE64 conference last month which 
provides some background:


   https://ripe64.ripe.net/archives/video/25/
   https://ripe64.ripe.net/presentations/48-AbuseAtScale.pdf  (slides)

Executive summary: it is no longer unexpected for individual attackers to own 
on the order of a million valid passwords. These passwords are taken from 
compromised websites and the hashes reversed using GPUs. We have in the past 
seen known attackers correctly authenticate to over
30 accounts per second and this problem is structural - it's isn't going to go 
away any time soon.

For this reason we now perform a risk analysis of every login and if we suspect 
it may not be the real owner of the account, redirect it to identity 
verification. This is what Michael saw.

The primary design principle of the system is to move all our users into the 
post-password age as gently as possible. The threat model covers attacks that 
operate at scale and who do not care about the specific accounts they work 
with. We provide things like 2-step verification, which authenticates you via a 
device or phone, for handling the stronger threat model of a highly motivated 
adversary against a specific highly motivated defender.

One outcome of this threat model is that if we can protect 95% of accounts from 
an attacker, that's good enough because it renders their attack uneconomic and 
they go away. See this paper from Microsoft
Research:

  http://research.microsoft.com/pubs/149885/wheredoalltheattacksgo.pdf

For this reason the system will usually fail open if there is a problem of some 
kind. An example of what can cause the type of behavior Michael saw:  if there 
the risk analysis subsystem misses its deadline the login processing servers 
will proceed without it.
Timeouts are rare but can occasionally happen. There are other cases involving 
specific types of account history and IP address combinations that could cause 
what Michael observed. Or there could be a bug :-)

It's best to view the risk analysis / id verification system as more like a 
spam filter than a hard-guarantee security system. It relies heavily on 
security through obscurity and exploiting weaknesses of very specific 
opponents, against which it has proven very effective.
Analyzing it as if it were a complete replacement for password security will 
lead only to disappointment.

thanks
/mike

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/