Twitter OAuth API Keys Leaked

The OAuth keys and secrets that official Twitter applications use to access users’ Twitter accounts have been leaked in a post to Github this morning.

The OAuth keys and secrets that official Twitter applications use to access users’ Twitter accounts have been leaked in a post to Github this morning.

The consumer keys and secrets, which function similarly to a username and password, were posted for Twitter for iPhone, Android, iPad, Mac, Windows Phone and TweetDeck. Unapproved third-party applications can now use these secrets to impersonate legitimate third-party apps and circumvent any access control measures Twitter has in place for unofficial apps.

“In OAuth, the consumer keys identify your application (eg. if you had a third-party Twitter client like HootSuite). Therefore, the impact is that someone can take your app’s consumer key and use the OAuth API pretending to be your application (eg. I can make API calls pretending to be the HootSuite application),” said Jon Oberheide, CTO and cofounder of Duo Security, a hosted two-factor authentication service for mobile devices. Oberheide downplayed the security implications of the lead, adding that there could be indirect risks that are specific to a particular application or service.

“A service that was not aware of the problems with consumer [keys] could erroneously put too much trust into the application’s identity,” he said.

In August 2010, Twitter moved to OAuth from Basic Authentication for authentication of official third-party apps such as TweetDeck. The third-party apps’ use of OAuth allows users to access the applications without the apps storing a password. OAuth consumer keys and secrets are embedded in every native or mobile application that relies on the specification.

“With OAuth, you still individually approve each application before using it, and you can revoke access at any time,” wrote Twitter communications person Carolyn Penner upon the announcement in 2010. With Basic Auth, users had to provide a user name and password for the application to gain access to the user’s Twitter account. The third-party app would store and send the information each time the application was used. The move to OAuth changed this dynamic.

Twitter will likely have to reset its keys, but this won’t prevent a repeat scenario where the new keys would be leaked as well. Given the way OAuth is designed, experts say the keys weren’t all that safe to begin with.

“OAuth consumer keys and consumer secrets are embedded in every application that uses OAuth, whether it’s a native application or mobile app,” Oberheide said. “And since the application is delivered to the user, the consumer key and secret can be extracted fairly easily by anyone with basic reverse
engineering skills.

“The developer can regenerate the keys and push out a new version but they can be extracted again. The developer can try to obfuscate the keys in different ways in the app to make them harder to
recover, but that’s not a game they’ll win at,” Oberheide said.

Suggested articles

Discussion

  • Katrina Payne on

    That... is not how these authentication systems are meant to be set up.

    Typically in how these systems work, is:

    An application has a key and a "secret" for the purpose of talking with a social network server.

    Then, upon talking to the server, to log in as a specific user, another set of "key" and "secret" are to be generated. Typing that specific application to that specific user id with that specific server.

    With a similar application not being able to access the user account, until it has the proper "key" and "secret".

    I think the issue may come from the authentication process having one of the handshakes removed.

    1. Server has its own finger print/cert
    2. Application has its own finger print/cert
    3. Connecting the Application gets a new finger print/cert
    4. User needs to approve the Applications connection outside of the application
    5. Applications current finger print/cert is unique to that "application session"
    6. Similar finger printed/cert Applications will need to handshake again to generate a new application session
    7. Regularly require finger prints/certs to expire, on all three levels: server, application and specific transaction. Works best if used via Sanity Checking rather than hardcoding stuff into each other.

    It is a system that should be able to work... I'm just thinking either the requirement for regular handshakes might have been dummied down a bit... or perhaps the finger prints/certs are not required to expire... which the lack of expiration allows for the system to be circumvented by merely watching the handshake, rather than a regular rotation of such systems.

  • Mohammed Tanveer on

    Katrina Payne - I'm so with you on this. We certainly have a problem, if applications are hardcoded than to have a set expiration frame.

  • Anonymous on

    youtube has something similar for iphone/appletv. it good for watch premium content free ;) all u need is cert from official device and U can generate with itunes sync

  • Louis St-Amour on

    Indeed part of the issue is expiry of oauth sessions -- few if any social networks support this on an individual-user basis. However, part of this is also the application. Addressing Katrina's comment, the problem is #2 -- that an application has a unique ID string or key that doesn't require server-side integration with Twitter for authentication. Now, Twitter itself can re-write the app to support better forms of challenge-response such that the local app cannot be as easily impersonated. But third-party apps can and have all along been impersonable as the mechanism to identify the app can always be duplicated by another app -- even if it expires, the method to get another key could itself be duplicated, because at the end of the day, the apps run on a local machine and so a user has full access to its secrets. At the end of the day, it's not Twitter's job to police their API, even for their own apps, if user data remains locked down under OAuth. Yes, an app could pretend to be Twitter during the OAuth process, as an app, but they could always have presented a fake login screen to do the same thing. Similarly, apps could re-use other apps' keys, but realistically, what's the point? The only foolproof scenario I can think of here is if you restrict your own OAuth app key usage to server-side, and wrap your app's calls in your own protection. But who does that and why bother?

    I'd like to see how Google and Facebook do such app-based authentication. At the end of the day, I think Twitter painted a target on their backs with their API restrictions of what was once public.

  • Ruler on

    I'm just curious how this re4k character obtained them.. makes me think whatever he got a hold of, because obviously it's sensitive information. There's no telling what else he got and didn't post to the public.

Subscribe to our newsletter, Threatpost Today!

Get the latest breaking news delivered daily to your inbox.