Slashdot Mirror

← Back to Stories (view on slashdot.org)

Bypassing Google's Two-Factor Authentication

Posted by timothy on from the disclaimer-dug-song-is-a-genius-monkey dept.

An anonymous reader writes "The team at Duo Security figured out how to bypass Google's two-factor authentication, abusing Google's application-specific passwords. Curiously, this means that application-specific passwords are actually more powerful than users' regular passwords, as they can be used to disable the second factor entirely to gain control of an account. Duo [publicly released this exploit Monday] after Google fixed this last week — seven months after initially replying that this was expected behavior!"

49 comments

  1. Where's the surprise? by F.Ultra · · Score: 4, Insightful

    Since the regular password as been changed to require an additional two-factor password they of course had to come up with this ASP idea for services where you cannot provide a two factor authentication and of course these have to be more powerful than the password that you now changed into a two factor. How can this be a surprise at all?

    1. Re:Where's the surprise? by AvitarX · · Score: 1

      Wasn't the single factor password to be tied to a device and a service though?

      I don't think it follows that it can obviously be used to disable 2 factor authorization (or even to get access to other services).

      --
      Wow, sent an e-mail as suggested when clicking on "use classic" banner, and got a fast response that addressed my msg
    2. Re:Where's the surprise? by Anonymous Coward · · Score: 3, Informative

      Well, a session using an ASP should not be able to do things that an app has no business doing, such as visiting the account security page. Google seems to understand this:

      This is no longer the case as of February 21st, when Google engineers pushed a fix to close this loophole. As far as we can tell, Google is now maintaining some per-session state to identify how you authenticated — did you log in using a MergeSession URL, or the normal username, password, 2-step verification flow? The account-settings portal will only allow you to access security-sensitive settings in the latter case (i.e. if you logged in using a MergeSession URL, it will give you a username/password/2-step-verification prompt that you can’t skip.)

    3. Re:Where's the surprise? by Albanach · · Score: 1

      Wasn't the single factor password to be tied to a device and a service though?

      The service thing I understand. I'm not sure how you would tie, say an IMAP password, to a device though? What would differentiate two different IMAP clients?

    4. Re:Where's the surprise? by Talennor · · Score: 5, Informative

      It's a privilege escalation problem. The surprise was that changing your main password or password recovery email should be only done by the full account, not an ASP context.

      --

      //TODO: signature
    5. Re:Where's the surprise? by blakelarson · · Score: 1

      You just generate a password for each "device". You can have multiple IMAP passwords. It gets a little weird -- you can just keep cranking out passwords for your various devices. You just name them and then, if one is compromised, you delete it while keeping the others.

    6. Re:Where's the surprise? by Albanach · · Score: 1

      I don't think you understand. How could Google identify one device from another?

      Of course as the user you can manage your passwords in whatever way works best for you. I don't see how Google could manage what the poster above suggested - that the password be tied to a device. From google's end, one IMAP client will look very much like another.

    7. Re:Where's the surprise? by AvitarX · · Score: 1

      Agreed, I wasn't thinking, Google's apps (such as android gmail) could authenticate as a specific device cryptographically, but there's no way to hack it into unaware apps such as an arbitrary IMAP client.

      --
      Wow, sent an e-mail as suggested when clicking on "use classic" banner, and got a fast response that addressed my msg
    8. Re:Where's the surprise? by blakelarson · · Score: 1

      I may have mis-typed. Google doesn't seem to care which generated password you use. You could just generate one password and use it for every single-factor login. Or you could generate a new one for every service. Either way, when you generate a password, you can "name" it whatever you want -- "Home Laptop Thunderbird IMAP", "SmartPhone Google Reader App", whatever. I don't think Google cares which one you use for which service. It allows you to name them for your own bookkeeping.

    9. Re:Where's the surprise? by hawguy · · Score: 2

      Since the regular password as been changed to require an additional two-factor password they of course had to come up with this ASP idea for services where you cannot provide a two factor authentication and of course these have to be more powerful than the password that you now changed into a two factor. How can this be a surprise at all?

      Why does a device password have to be more powerful than my main two-factor protected password?

      If my phone needs a device password to download email, why should that password also be able to change my password settings?

    10. Re:Where's the surprise? by hawguy · · Score: 1

      I don't think you understand. How could Google identify one device from another?

      By using the unique password to identify the device?

      Presumably Google has a password hash stored somewhere that they use to authenticate the device. If it matches password hash 1, then it's your phone, if it matches password hash 2 then it's your tablet.

      They could also use unique usernames, but that may be harder for the user. user+myphone@gmail.com for the user's phone, user+mytablet@gmail.com for the user's tablet. But some software will probably get confused and not understand that the authentication username is not the user's email address.

    11. Re:Where's the surprise? by icebike · · Score: 2

      Actually TFA says the App Specific Password was encrypted with the device id. Google knows which device is talking to it.

      You are correct that ANY one of your valid ASPs could be used for any Google service. This is the part that they fixed.

      As you suggested, generating one single ASP and using it for everything would in fact work, but Google doesn't make this easy. You have to write them down somewhere, because once they show them to you, you can never see them again. You have to copy them into password fields in various apps (say for instance your favorite email app).

      After the first showing of the actual ASP google only refers to them by the Name you gave it, so your naming convention is exactly what they expect you to do.

      The problem was that, with a carefully set up network, and if you know the device id, you could capture and decrypt the ASP, and use the decrypted form from then on. But you had to be quick, as the encrypted ASP was time sensitive.

      --
      Sig Battery depleted. Reverting to safe mode.
    12. Re:Where's the surprise? by icebike · · Score: 1

      It's a privilege escalation problem. The surprise was that changing your main password or password recovery email should be only done by the full account, not an ASP context.

      But that was the part that they fixed, No?

      --
      Sig Battery depleted. Reverting to safe mode.
    13. Re:Where's the surprise? by icebike · · Score: 3, Interesting

      From TFA:

      This is no longer the case as of February 21st, when Google engineers pushed a fix to close this loophole. As far as we can tell, Google is now maintaining some per-session state to identify how you authenticated — did you log in using a MergeSession URL, or the normal username, password, 2-step verification flow? The account-settings portal will only allow you to access security-sensitive settings after username/password/2-step-verification prompt that you can’t skip.

      So, yes, you are correct, that is how it used to work, but not any more.

      Still these ASPs are not in fact "Application" specific. They probably should be, but that would be pretty convoluted and people would throw up their hands and walk away. (I read somewhere that something like 80% of the people that try 2-Factor give up when they see all the hoops that need jumping.

      --
      Sig Battery depleted. Reverting to safe mode.
  2. I didn't get this by Anonymous Coward · · Score: 0

    Application-specific passwords are for programs that don't support Google's 2-step authentication process. They're computer-generated (approx 16 characters of random alphanum) and you're supposed to use one per application. I use one for Mac Mail, one for YouTube posting on my iPhone, etc.

    Clearly they bypass the 2-step auth process because that's what they're designed to do. So how are these not working as designed? I can see that it would be better if they could be restricted to say only allow YouTube posts or only allow IMAP access, but that's a design improvement.

    Did I miss something here? Are they broken as designed or is the issue just the design?

    1. Re:I didn't get this by nedlohs · · Score: 1

      Allowing authentication with an application-specific password to give you permissions to change account settings like the email to send password reset information to was unlikely part of the design (it'd happen with the obvious implementations if not doing so wasn't explicit in the design of course).

    2. Re:I didn't get this by Anonymous Coward · · Score: 0

      Clearly they bypass the 2-step auth process because that's what they're designed to do.

      They must allow normal application access, yes, but there is no reason that they should allow you to reset passwords or to disable 2-factor authentication.
      "Broken" can be subjective in the security world, but let's just say they found a "trivial and obvious" improvement to the design.

    3. Re:I didn't get this by Talennor · · Score: 1

      Problem is that "design improvement" is a security concern, and required for the system to function as desired. Adding wheels to a car might be a "design improvement", but you'd better have them.

      --

      //TODO: signature
  3. Sounds like expected behavior to _me_ by Anonymous Coward · · Score: 0

    ...and I'm a customer who uses this functionality.

    I'd really need a much better explanation to know what part of this is a bug. Letting application-specific passwords leak is a problem, and has always obviously been such -- part of the reason OAuth2 is being positioned as a replacement is to avoid having these tokens stored.

    1. Re:Sounds like expected behavior to _me_ by Half-pint+HAL · · Score: 2

      The problem is that anyone who manages to log onto your laptop has access to your Google Drive account (expected behaviour). And anyone who has access to your Google Drive account has access to everything Google... including Google Wallet. I was online when this change was applied. I'd connected to Google via the Google Drive application (because I couldn't remember my password) before navigating through to Google Wallet. It didn't strike me at the time just how dangerous a security hole this is. A few minutes later I was asked to log in properly, so I had to reset my forgotten password by phone alert. But a malicious hacker would have been able to change that too, and I might have worked away for various clients for a month before I discovered that the money was no longer reaching my bank. (Online language teaching, small value payments -- Google and Paypal are the only viable options.)

      --
      Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
  4. Hand in the cookie jar by Anonymous Coward · · Score: 0

    Just keep in mind that any application that has access the files on your computer (mainly the browser cookies) can bypass the 2-factor-auth. You just need to copy the cookie to another browser and BAM! - you're logged into Google.

    1. Re:Hand in the cookie jar by Half-pint+HAL · · Score: 1

      Which is why I don't use browser cookies for accounts of genuine value -- email, business webhosting, paypal, Google Wallet, ecommerce sites.

      --
      Got them moderator blues I blieve I walk out the do', With these mod-points I been gettin', I 'most never post no mo'
    2. Re:Hand in the cookie jar by unrtst · · Score: 1

      Just keep in mind that any application that has access the files on your computer (mainly the browser cookies) can bypass the 2-factor-auth. You just need to copy the cookie to another browser and BAM! - you're logged into Google.

      You are confusing various unrelated items. (or maybe you're just oversimplifying things)

      Just to clarify, authentication (2-factor or single factor) is separate from session management.
      In addition, the application session is separate from the single sign on session.

      Although google doesn't use Jasig CAS, I think it's protocol is one of the easiest ways to get a more detailed understanding of SSO: http://www.jasig.org/cas/protocol
      That protocol doc is actually quite readable. It differs from SAML in some respects, but it's a very similar process.

      I honestly haven't tested this with google services, but I believe (and hope) that if you take a gmail session cookie, and copy it to another browser, it will only get you access to gmail (and maybe not even that, if it's doing some additional tests... you may need to bring over other information and key identifiers). I'd be curious to see this attempted (it'd be easy to try). In any case, this is unrelated to the authentication.

      In addition, that session cookie is unlikely** to be present in the cookie file, since it's a session cookie (lives as long as the browser session is active) and is a secure cookie (shared and only accepted over SSL). It's still possible to get to it if your'e on the local machine, but it's not as simple as opening a file and reading it out.

      ** "unlikely" as in, unless you told the service to remember your session somehow, which may be the case in some situations, like on mobile devices... I'm not sure. The default on the browser won't do this though.

  5. Not surprised... by Junta · · Score: 1

    I considered the 'application specific' passwords as just 'hard for human to remember password' and that divulging the password to the program meant I explicitly trust the program with access to my account (the big fat clue being no app specific configuration data other than a helpful descriptive tag).

    I suppose they could enrich it by forbidding account management function, or scoping it more (e.g. mail versus jabber versus whatever as limited scope).

    --
    XML is like violence. If it doesn't solve the problem, use more.
  6. Surely this is expected by cgimusic · · Score: 2, Insightful

    To be fair I can sort of see Google's point. An application specific password is meant to be given to the application once and then never typed again, heavily reducing the chance of it being compromised. It should still not be possible to turn off 2 step auth or change the users password with one though but I have never assumed that it couldn't. Google makes it quite clear that the password grants full account access.

    1. Re:Surely this is expected by fermion · · Score: 1

      I would say that this is far from clear. In chrome I was asked for my application specific password, but since I did not know what it was, and could find nothing to tell me, I did not give it or set it up. This really seems a case of bad security through complexity. When I log into Google, i give it my password and a one time code. This seems like simple security. Perhaps someone will tell me otherwise.

      --
      "She's a scientist and a lesbian. She's not going to let it slide." Orphan Black
    2. Re:Surely this is expected by Anonymous Coward · · Score: 0

      Did you read the article?

    3. Re:Surely this is expected by Eric+S.+Smith · · Score: 1

      An application specific password is meant to be given to the application once and then never typed again, heavily reducing the chance of it being compromised.

      If it's kept in persistent storage by the application, that actually increases the chance of it being compromised. Rather than logging keystrokes or peeking at RAM or man-in-the-middling the application in some way, you can just read a file.

      --
      Mind the Gap
  7. Re:Nice Guys! by Xicor · · Score: 2

    you dont generally go public with an exploit until you have a fix for it. it seems silly to me to publicize a way to take over peoples' accounts that the person who found out is keeping quiet. if you do, then everyone who would be using exploits is now aware of an exploit that you cant fix in the immediate future

  8. You Didn't RTFA! by Anonymous Coward · · Score: 4, Informative

    You missed the part where your individual ASP doesn't simply have access to YouTube, but rather to ALL of your Google services. And, worst of all, the ASP also gave full access to the password/account options page so, you could leverage an ASP and take complete control of all services managed by that Google account.

    A single ASP completely bypassed all security and two factor authentication.

    This was all clearly and plainly explained in the not-very-long fucking article!

    1. Re:You Didn't RTFA! by hawguy · · Score: 2

      You didn't RTFC. I didn't miss that part, I explicitly mentioned it. My question was fairly specific and was not answered in TFA. Thanks for proving the "33% of Slashdot responses are from dickheads" law, though.

      So you understand the original problem, understand the weakness of an ASP having the same privileges as the 2-factor protected password, and you say it's working as designed and any fix would just be a "design improvement".

      I think that's exactly what Google told the people that disclosed the bug 7 months ago, that everything was working according to design. A weakness is a weakness, even if it was designed that way, that doesn't mean it isn't a weakness or that it shouldn't be fixed.

    2. Re:You Didn't RTFA! by icebike · · Score: 1

      A weakness is a weakness, even if it was designed that way, that doesn't mean it isn't a weakness or that it shouldn't be fixed.

      And it was fixed. So why the venom?

      By the way, reading TFA would reveal that using this design flaw as an attack was a LOT harder than it first appears. You actually had to know three things, a username, a device Id, just to decrypt the ASP that you captured on your carefully crafted network with an intercepting proxy with fake credentials. However, if the session all happened under SSL, all bets were off. (Always using SSL is an option offered in many, but not all google services).

      --
      Sig Battery depleted. Reverting to safe mode.
  9. For what it's worth by caldroun · · Score: 1

    I use the Application Specific passwords as Device Specific instead. I have a code for my Phone, laptop, and desktop computers. So...If one of the devices gets stolen or sold, I just expire the one code. Much easier to manage 4 or 5 codes than a bunch of codes for a lot of apps.

    --
    "If you have done 6 impossible things this morning, why not round it off with breakfast at Milliways" -- hhgg
  10. Re:Nice Guys! by Anonymous Coward · · Score: 5, Insightful

    The generally accepted behavior is to:

    1. Report the bug to the developers.
    2. Work out a disclosure timeline and give them time to fix the problem.
    3. Disclose after the fix is released.

    Except when the developer at stage two says; 'that's not a bug' or, 'that's intended design', or FOAD' or they ignore you completely. Then the responsible thing is to disclose the bug so that everyone knows that it is an issue and stops using the service until the developer is forced to address the issue.

    In this case, Google said that it was by design. Meaning essentially that there was no fault/bug when there clearly was. At that point, with no expectation of it being fixed, Duo Security would have been well within the right to disclose and force Google's hand. Or, they could turn evil and profit from the exploit, since you seem to feel that they should not have disclosed a bug that Google was ignoring.

  11. [publicly released this exploit Monday] by Anonymous Coward · · Score: 0

    Why the block quotes? Was this cleaned up from something offensive or unintelligible?

    1. Re:[publicly released this exploit Monday] by Shatrat · · Score: 1

      Probably said 'released Today' or something slightly more ambiguous than what they replaced it with.

      --
      09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
  12. Goes to show... by Anonymous Coward · · Score: 0

    that good security is a process, NOT a product.

  13. Re:You Didn't RTFC! by Anonymous Coward · · Score: 0

    You're still struggling to understand? Reread the article and my previous comment. The fact that Google fixed the issue should indicate to you that, it was in fact, real despite your comprehension issues.

    The application specific password allowed access to services and areas that it should never have. That access removed all security measures. This may or may not have been by design, but if it was by design, the design was broken. That's why they fucking fixed it, you moron!

  14. google passing buck again? Or is it yet? by Almost-Retired · · Score: 0

    I wonder if that is why I found myself locked out of my gmail account as of about 3:38 am yesterday. Fetchmail reported a password problem. I called google on that number from fastsupport, and 2 different people, neither of whom spoke English well enough to talk to this old Iowa Farm boy, tell me that something was changed in my account that only my machine could have done, and accused my machine of being compromised. I'm running linux, and my whole home network is behind a dd-wrt router. I can see the traffic leds on both the switch and the router, and this machine isn't spewing anything.

    I've run all the usual suspect tests for rootkits and such, and I am confident my machine is clean. The only thing that might be suspect is the "by country" logs from awffll. India shows up to a much larger extent than I would normally associate with running a repo for a nearly 30 year old computer originally sold by Radio Shack. 31% of the traffic, a grand total of 1.33Mbytes, (I said its a legacy machines repo), was to/from India. No PHP involved either.

    So, since I have more than one 'isp' at my disposal, I spent a good part of the day yesterday re-subscribing to the mailing lists I am on from a different address that is not under google's ever so helpful umbrella.

    I am quite tired of the 800 lb gorilla's in this "intertube" thing passing the f*cking buck when _they_ get a fart stuck crossways.

    Cheers, Gene

  15. Re:Nice Guys! by binarylarry · · Score: 1, Insightful

    They're a Google Ventures company.

    Best not to bite that hand that feeds you.

    --
    Mod me down, my New Earth Global Warmingist friends!
  16. Re:Nice Guys! by Anonymous Coward · · Score: 0

    Why are you assuming that you are the only one to have found out about it? At least this way people know to stop using the product.

  17. So is this a good summary? by 140Mandak262Jamuna · · Score: 1
    OK, this is the best I could make out based on my limited understanding. You can turn on two factor authentication on and every time you log in from a browser, you need to get a code to cell phone or use a one time pad number as the second factor. But not all google accounts/applications/services use a plain browser to log-in. Looks like this is more common the apps/mobile/android world. So you create a special password for those applications alone. But if those app specific passwords are captured by a thirdparty, they can use it to reset the full account password or capture the account.

    So if I had not created any app-specific password I should be safe right? Or have I implicitly created some app specific passwords to let my android phone to log in to my google account? I don't have any serious app in my mobile phone. All I do with my phone is to make phone calls, listen to FM radio and look at the clock. Why I got a smart phone I don't know. Now it looks like it is making my google accounts vulnerable.

    --
    sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
  18. Re:Nice Guys! by icebike · · Score: 4, Informative

    So, Google blows them off and the don;t go public for seven months? These are some nice guys!

    Or perhaps they've been profiting for the past seven months. WFT Google?

    Well, its not as easy as to pull off this exploit as it might seem.

    From TFA:

    So: given nothing but a username, an Application Specific Password, and a single request to https://android.clients.google.com/auth, we can log into any Google web property without any login prompt (or 2-step verification)!

    So you had to know two things:

    1) Someone's Username
    2) Someones Application Specific Password.

    You had to know their PASSWORD. Or you had to "set up an an intercepting proxy with a custom CA certificate to watch the network traffic" to try to capture the encrypted password". These ASPs are encrypted with the sending device id. (That Device ID is yet another thing that the attackers KNEW up front. If you didn't know that Device ID, setting up the Intercepting Proxy wouldn't help you.

    Granted if you know the password its game over. Two factor authentication only works if every piece of software supports it, and until it does big long hairy App specific passwords still have to be used.

    You can't derive this password unless you also know the device ID, because its encrypted.

    The big HOLE here is that ANY one of your valid Application Specific Password gave you access to ALL parts of your Google Account.
    So an ASP for SMTP allowed you to access your Account dashboard. They really weren't Application Specific on Google's end. That is the part Google fixed.

    But again, its not as big of a gaping hole as the summary makes it out to be. Because you still needed to carefully craft an intercepting proxy, know the originating device id, decrypt the password, and log in VERY QUICKLY because the encrypted password is date stamped with a short life span. This would be very hard to pull off in the real world.

    So yeah, it needed fixing.
    I'm glad its fixed (for the most part), but there was no giant emergency here.

    --
    Sig Battery depleted. Reverting to safe mode.
  19. Re:You Didn't RTFC! by BlueMonk · · Score: 3, Insightful

    I think you're being over-critical of the commenter's diligence. There is some room for interpretation or confusion. Yes, application specific passwords are intended to provide single-step authentication to applications that don't participate in 2-step authentication. And yes, it's easy to gloss over the distinction between using an ASP to access application functions versus security aministration functions, and that's where the bug lies. Its easy to gloss over because ASPs were intended to replace 2-step authentication, and its a somewhat subtle point that this access should exclude administrative functions - subtle because that was never mentioned in the design/purpose of ASPs.

    So I think the commenter's confusion/question is fair to some extent: Google representatives themselves probably glossed over the distinction between limiting ASP access to app-level functionality versus ASP access to admin-level functionality leading to their initial response that it was working as intended. Now you say that the commenter should have made that distinction, and that's true with the help of this article, but there's still a gray area that I think the commenter is trying to point out. Not only is there a distinction between app-level access and admin-level access that ASPs should have been conscious of. There's also a distinction between app-level access and app-specific access. In other words, an application could be limited to access only data relevant to its specific operation (just email content, for example), or it could be limited to access only data relevant to *any* application-level operation (exclude all admin functionality, but allow access to all other data), or it functions just like a mechanism to bypass 2-step authentication, accessing all functionality (which Google now agrees is "buggy").

    The commenter acknowledges that yes, it would have been nice to have ASPs limited to app-specific functions, but notes that this level of refinement was never intended to be incorporated into ASPs. And I think the commenter is right on that point. My (and your) response to that however is the next level of distinction. This is not the level of distinction being called out in the article. I think the distinction is between app-level access versus admin-level access, not a reference to app-specific access. No application should have admin-level access when using an ASP. That's less of an enhancement and more of a security flaw when you get to that level of security hole.

  20. Re:Nice Guys! by Golddess · · Score: 1

    But if TFS is to be believed, Google was originally calling it a feature, not a bug. Now I don't know what I would do in such a situation, but I can understand how someone might think "well, if they view it as a feature, then I should share this feature with the world".

    --
    "I'm not sure I like the fugnutish tone you used in your post!" -RogL (608926)-
  21. Re:Nice Guys! by vux984 · · Score: 1

    But again, its not as big of a gaping hole as the summary makes it out to be.

    You could phish for them.

    Release something 'useful' that uses an ASP and then harvest them...

  22. Re:Nice Guys! by Xicor · · Score: 1

    you should read helpdesk, you will get a kick out of it