google-jacking: a review of google 2-factor authentication

A Review of Google 2-Factor Authentication

Google-Jacking

Craig Young Security B Sides San Francisco, USA 2013

Look Who’s Talking

• Defining 2-Factor Authentication (2FA)

• Defining 2-Step Verification (2SV)

• diff -Burp 2FA 2SV # Compare & Contrast

• Attacking Application-Specific Passwords

• DEMO: Do androids dream of übertokens?

• TODO: Making 2SV Better

Talk Overview

Define: 2-Factor Authentication

• 2SV is Google’s 2FA branding

• Phone becomes the ‘something you have’

- STEP 1 – Login to with account password

- STEP 2 – Enter code from phone

• Application-Specific Passwords (ASPs) - Used for 3rd party & legacy support

- 16 lowercase letters

- Limited by application (in theory anyway)

man 2SV

Authentication Credentials 2FA 2SV

Something you have + Something you know ♦ ♦

Something you know ♦

Something you have ♦

$ diff –Burp 2FA 2SV

Bottom Line?

2FA enhances security by compromising convenience

2SV enhances security but only when it is convenient

• Are ASPs the Achilles heal of 2SV?

1. ASPs are all powerful

2. ASP revocation is broken

3. ASPs increase the risk of token attacks

4. Google recommends saving ASPs

Attacking Application-Specific Passwords

Google attempts to restrict browser-based ASP use:

Android browser auto sign-in bypasses this restriction:

ASPs Provide Full Account Access

HOWTO: punting the intruder Recovery Measure Tested Result

Revoke application-specific passwords No effect on logged in intruder

‘Sign out all other sessions’ from Gmail No effect on logged in intruder

Revoke ‘Android Login Service’ Androids must re-authenticate

Change account password Androids must re-authenticate

Recommended Procedure: STEP 1 : Revoke all ASPs STEP 2: Change account password STEP 3: Verify account settings

• Pay attention to permissions!

• Apps with root can directly access acounts.db

• ASPs are backdoors by design

Android Apps Can Generate ASPs

• Privacy advisors don’t look at token related permissions

• Far too many apps have the ability to request tokens

There’s An App For That

Auditing the ASP Auditing

ASPs added and removed in the same activity period are not reported!

Check “Remember Password”

• Saving passwords gives attackers an edge

- OS X Keychain can be dumped

• Pidgin (chat) doesn’t bother to use crypto

- Most applications provide limited protection

What could go wrong?

DEMO!

• Ideal Solution:

- ASPs are no longer part of 2SV

- Use account password + time-based code

• Quick Fix:

- Force authentication when generating ASPs

- Allow users to disable ASP creation

TODO: Ditch ASPs

• Ideal Solution:

- Tokens should be revoked along with the ASP

- Requires tokens & ASPs to be related

• Quick Fix:

- Treat ASP removal like a password change

- All sessions are forced to authenticate again

TODO: Fix ASP Revocation

NO MORE ANDROID LOGIN WITH ASP!

• Explicit ASP Model: - Specify allowed services for an ASP

- Limits abuse of compromised ASPs

• Implicit ASP Model:

- Restrict the ASP to the 1st application using it

TODO: Make ASPs Application Specific

• Require a password to enable auto sign-in

• Don’t allow auto sign-in for account settings

• Allow disabling auto sign-in at an account level

TODO: Lock Down Auto Sign-In

• Audit how and when an ASP is used

• ‘Access type: Mobile’ is too vague

• ASP name in the activity screen would help

TODO: ASP Auditing

1. Android is a logged in browser session • Use caution when sharing your device

• Consider unlinking your Google account when traveling

• Watch app permissions closely (guard your tokens)

• Use a strong password (Lock screen widgets FTW)

2. Don’t save ASPs without encryption

3. Monitor ASPs & change your passwords

How to Protect Yourself

Android 4.2 Lock Screen

Dialer Widget

Concluding Remarks

• 2SV is vulnerable-by-design

• 2SV increases risk from token-based attacks

• Android + 2SV reduces security

• ASPs are a bad idea

- Password + OTP code makes security in 1-step

- Let users decide whether ASPs are allowed

1. 11/26/12-11/30/12 - Multiple 2SV/ASP issues reported to Google

2. 12/5/12 – Confirmation of reported behavior as known issues

3. 1/11/13 – Google notified of BSides SF CFP submission

4. 2/18/13 – Account Activity Logic Error Reported to Google

5. 2/22/13 – Fix details received (Re-auth requirement implemented)

6. 2/24/13 – BSides presentation

7. 2/25/13 – ASP revocation fix begins to roll out

Disclosure Timeline

For more information about enterprise risk management or Google 2-step verification:

• Visit nCircle RSA booth 1023

• Check out the nCircle VERT blog: http://vert.ncircle.com

• Follow @craigtweets

Questions?