Live data from Hacker News

Ripping OAuth tokens out of Twitter apps

timetobleed.com

11–20 of 33 posts

Re: Ripping OAuth tokens out of Twitter apps

#11
post #8
post #5

I pulled the keys out of the android client this weekend. Not as good of a write up, but I used apktool to convert the APK back to xml resource files and smali dalvik assembler. Greped for Hmac and added some logging. Did the same thing for oauth_consumer_key. Rebuilt it as an APK with apktool. Signed it with jarsigner. Watched the logs and logged in. I think the best part is this key can use xauth so other clients c…

are you intentionally neglecting the additional steps to make this work, or did you not test your assumptions against the requests that the app actually sends? ;)

I tested this on the with the twitter api. This key was already leaked in 2010 at https://github.com/mitsuhiko/logbook/blob/master/twitter-sec.... So I will just post it here. https://twitter.com/armooo/status/237729837157060609 take a look at the name of the client.

    >>> key = 'Bcs59EFbbsdF6Sl9Ng71smgStWEGwXXKSjYvPVt7qys'
    >>> oauth_consumer_key = '3nVuSoBZnx6U4vzUxf5w'
    >>> import tweepy
    >>> auth = tweepy.OAuthHandler(oauth_consumer_key, key)
    >>> auth.get_xauth_access_token('armooo', )
    
    >>> api = tweepy.API(auth)
    >>> api.update_status('This is an update %s:%s' % (oauth_consumer_key, key))
    

Re: Ripping OAuth tokens out of Twitter apps

#12
post #9
post #6

Earlier quoted context omitted.

OAuth was designed to not require SSL. So only the oauth_consumer_key, which works as an client id, is sent over the wire. HMAC-SHA1 is then used with a shared secret key to sign all the requests. This key is what the maloc shim is finding, along with the oauth_consumer_key, but it was simpler at this point then looking at the http connection.

Ok, then why did the OP only show HTTP requests as the captured output? If he's capturing something else, shouldn't he show that?

Good point, I am not sure why the OP did not show the key.

Re: Ripping OAuth tokens out of Twitter apps

#13
post #2

This operation is awesome and it does a great job of showing how twitter is going to have a hard time having blessed clients. If twitter wants to rate limit API calls for apps in an effort to reduce abuse then abusers are going to impersonate the official twitter client.

This is AOL Instant Messenger all over again: a closed source client with a secret (proprietary protocol) that is blessed, and vague threats of legal action against unauthorized clients. Except in this case, Twitter's probably more serious about the whole thing.

Which is ridiculous, this being Twitter and all...

Re: Ripping OAuth tokens out of Twitter apps

#14
post #11
post #8

Earlier quoted context omitted.

are you intentionally neglecting the additional steps to make this work, or did you not test your assumptions against the requests that the app actually sends? ;)

I tested this on the with the twitter api. This key was already leaked in 2010 at https://github.com/mitsuhiko/logbook/blob/master/twitter-sec... . So I will just post it here. https://twitter.com/armooo/status/237729837157060609 take a look at the name of the client. >>> key = 'Bcs59EFbbsdF6Sl9Ng71smgStWEGwXXKSjYvPVt7qys' >>> oauth_consumer_key = '3nVuSoBZnx6U4vzUxf5w' >>> import tweepy >>> auth = tweepy.OAuthHandle…

ah, yes, you're right, was thinking of another api endpoint.

Re: Ripping OAuth tokens out of Twitter apps

#15
Cross-pasted from the previous submission of this article:

By its nature, the only way to combat this class of attack is security by obscurity - hence, it should be assumed that OAuth client tokens and client secrets do not provide true protection against unauthorized client applications.

Of course the tokens can be obfuscated, but at some point the tokens must be used in plain-text to sign the OAuth request, and on a device like an iPhone where complete control of execution flow and full address space access is possible (via kernel exploits / jailbreak and a debugger), it's literally impossible to prevent this attack.

Issuing unique per-device device tokens would be an interesting approach, but then a trusted side-band would be necessary to issue the tokens to the device, and a lot of the point of OAuth is moot.

OAuth is still quite useful for user authentication (as to steal per-user tokens requires access to the user's device anyway). Plus, in the other common OAuth use-case (backend to backend), if the consumer token is stolen, your client probably has a larger security issue on their hands that would have allowed the attacker to pose as them anyway.

This is interesting in that it may allow unscrupulous app developers to evade Twitter's new API limits by posing as the Twitter for iOS or Android applications, but I suspect these uses will not be widespread as Twitter can quite probably send a Cease and Desist to Apple or Google and have the offending app removed from the market.

Re: Ripping OAuth tokens out of Twitter apps

#16
post #10

I was thinking about this quite a few times: doesn't it mean that all this OAuth things are broken from the start, since once you give the binary to the people, the could just get the secret out and reuse it another way? The TOS of all these APIs all say that "you have to keep your Secret secret, or else!", but fundamentally there's no way to really do that, is there?

It just compromises the application identity, it still does not give you access to anything useful and it will probably be noticed if you use it on any significant scale.

However, OAuth is indeed a bad way to authenticate for applications that run on devices in the possession of third parties.

Re: Ripping OAuth tokens out of Twitter apps

#17
post #2

This operation is awesome and it does a great job of showing how twitter is going to have a hard time having blessed clients. If twitter wants to rate limit API calls for apps in an effort to reduce abuse then abusers are going to impersonate the official twitter client.

This is AOL Instant Messenger all over again: a closed source client with a secret (proprietary protocol) that is blessed, and vague threats of legal action against unauthorized clients. Except in this case, Twitter's probably more serious about the whole thing. Which is ridiculous, this being Twitter and all...

At least for me the vague threads of legal action during the aim time where not very vague, but trademark infringement for naming my application Kaim. Unlike the Gaim guys I simply switched my application name Kinkatta (Kinkatta is not Kaim anymore thanks to AOL).

Re: Ripping OAuth tokens out of Twitter apps

#18
OAuth on the client side is not about restricting access to people hacking up their own clients, its about restricting access to the network for things that don't fit the api owners wishes, in this case involving revenue. Just like content owners dont tend to worry too much when a hard to use and essentially impossible to scale bypass tool is released, but it behind a nice gui and toss it in an appstore and you've brought all sorts of hell upon yourself.

Thinking of oauth on the client as any kind of security measure on the client side is absurd anyways, at best it keeps honest people honest and maybe cuts down on signal/noise for the lowest of the low budget spammers.

Re: Ripping OAuth tokens out of Twitter apps

#19
post #5

I pulled the keys out of the android client this weekend. Not as good of a write up, but I used apktool to convert the APK back to xml resource files and smali dalvik assembler. Greped for Hmac and added some logging. Did the same thing for oauth_consumer_key. Rebuilt it as an APK with apktool. Signed it with jarsigner. Watched the logs and logged in. I think the best part is this key can use xauth so other clients c…

well, jellybean has app encryption http://developer.android.com/about/versions/jelly-bean.html#...

Re: Ripping OAuth tokens out of Twitter apps

#20
Oauth tokens, consumer keys, nonces, and timestamps are not something you don't already have access to as a user. The token is your authentication proof / API access key, the consumer key is a bit misleadingly named but just identifies the 3rd party, it is public knowledge. The nonce and timestamps are artifacts of authentication and less sensitive than the token.

The real meat is the 3rd party's consumer secret (the secret key that goes with their consumer key.) If you're finding those then someone needs to make a South Park ski instructor meme.

Post reply on HN