OAuth-Protected Access at Facebook and Twitter Breached from Leaky Buffer Service

On October 26, 2013 tens of thousands of Facebook and Twitter users got a nasty shock. Hackers broke into a service called “Buffer”, plundered OAuth access tokens and posted to their accounts. Luckily, it was all just to promote a weight loss scheme. Last time a major social network breach was in the news, with the fake White House tweak, it cratered the stock market for a day!

 

I’m glad I didn’t use the convenient Buffer social posting and scheduling service, or any similar one with the power to impersonate me using weak security like OAuth’s. What many people don’t realize is that social loginservices often work in reverse, at least for posting. Think about it. If you use Facebook Login, many or all of perhaps of dozens of sites can post to your Facebook account. Any one of them could be breached and the hackers could wreak havoc on your business or reputation. Update: See my NEW POST describing OAuth’s Covert Redirects and Perverse Incentives.

 

I read about what I’ll call the “leaky Buffer breach” yesterday at the Programmable Web where author David Berlind called it a “wake up call for the web.” Berlind does a great job describing the situation. While Buffer could have done a better job protecting itself and its customers, the rot goes deeper than any one site’s vulnerabilities. It strikes at the heart of OAuth itself. The industry needs to address systemic low assurance OAuth vulnerabilities before they become foundational to Internet identity itself.

 

I addressed OAuth assurance more formally in this post, but there’s nothing like a breach to bring out the metaphors and Berlind cites this one: The bearer token form used in 99% of OAuth implementations is like a valet key. Valey keys give access to your car, not your life. Unfortunately, anyone that gets the valet key or access token can use it to steal your car or to compromise your account. That’s what happened at Buffer – attackers stole in and grabbed all the access tokens from a database and began driving users’ Facebook and Twitter accounts.

 

OAuth advocates tout the access token aka valet key for its benefit of “eliminating the password sharing anti-pattern” and that’s good, as far as it goes. But perhaps its being taken too far with social login services like Facebook Login, generalized authentication like OpenID Connect and even generalized authorization with User Manager Access (UMA) and all the other “O-tocols” that are piling on this weak foundation.

 

Popular OAuth implementations with big targets painted on their back come up with crude hacks to address the bearer token vulnerability. Facebook has its “appsecret_proof” and Twitter has its “consumer_secret.” Each enables partners to sign access tokens using the shared secret string so that a stolen access token alone gets hackers nowhere. But neither of these solutions kept the hackers out in the case of the leaky Buffer.

 

Facebook’s appsecret_proof – like the OAuth 2.0 “client secret” parameter used in the Authorization Grant flow to get an access token – is optional. Buffer wasn’t even using it until afterthe breach. The consumer_secret is mandatory (kudos to Twitter) but hackers broke into the Buffer’s GitHub database (where the string was hard coded in the source code) and took it!

So with OAuth you have specs that all too often say “SHOULD” instead of “MUST” or leave important issues like registration “out of scope.” You have implementers taking the easy road, ignoring the vulnerability or creating non-standard solutions. I’ve learned that there’s no such thing as a “generic OAuth connector,” only “Facebook connectors,” “Twitter Connectors” and so on.

 

What do OAuth’s “client secret”, Facebook’s “appsecret_proof” and Twitter’s “consumer_secret” all have in common? They are all shared secrets and very challenging to manage. Berlind highlighted some ways that OAuth implementers could do a better job of protecting shared secrets than Buffer did. Like obfuscating the string in the code, keeping it in an offline file or storing it in a hardware security module (HSM). 

 

Where an HSM could come in handy is with more advanced asymmetric or public/private key management. Instead of a shared secret, security servers at sites like Facebook’s would use the application’s public key to check a digital signature on every request. The request signing and private key functions would exist only on the HSM. Different application tiers or domains could have different keys and HSM access (separation of duty). Keys could be frequently changed and immediately revoked at need. More on this to come in a future post!

 

For individuals: Minimize use of OAuth-based services like social login or social posting to what’s really essential for you. Use a password manager, or form filler product instead of social login. Use two factor authentication and tighten the privacy permissions on all your social media sites.

 

For implementers: Read the Buffer blogs from late October, 2013. It seems the developers at this resource-constrained startup managed to implement access token encryption (a toothless MUST in OAuth 2.0), two factor sysadmin administration and appsecret_proof in just a few days! That’s not to say they’ve got this stuff right (yet) but it’s a great start. Why wait and fix it in the wake of a breach? If it only takes a few days, won’t a few late night expressos taste much better than the acid reflux of breach adrenaline at 2:00 AM? Build in the security up front instead of cutting corners.

 

For the industry: Continue working on various OAuth enhancement specs to add in proper crypto, key management, registration and the rest. But the upgrade is not going to be easy! Anticipate the need to retrofit OpenID Connect, UMA and all the other “O-tocols” as well as existing OAuth implementations once a better foundation is in place. We’ll have to specify that enhanced assurance foundation simply, clearly and unambiguously in a minimum of RFCs or specs with a minimum of different ambiguous options. And we’ll need guidelines for enterprises, developers and CSPs using OAuth to test, evaluate and obtain certifications that each implementation attains some (to-be-defined) assurance level.