google-jacking: a review of google 2-factor authentication
Post on 13-May-2015
1.465 Views
Preview:
DESCRIPTION
TRANSCRIPT
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?
top related