Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ripping OAuth tokens out of Twitter apps

timetobleed.com

Post reply on HN
Print view View original

21–30 of 33 posts

Re: Ripping OAuth tokens out of Twitter apps

#21

Post by JoshTriplett »

dpeck wrote: post #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 br…

You can use OAuth without requiring blessed per-application API keys; it primarily exists so that services can let an application access a user's account without actually having the username and password of that account, and without necessarily having the full permissions of that user.

Re: Ripping OAuth tokens out of Twitter apps

#22

Post by armooo »

necenzurat wrote: post #19
armooo wrote: 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#...

Reading this http://nelenkov.blogspot.com/2012/07/using-app-encryption-in... it looks like if you have root on your phone you can still access the APKs. Sounds like it is using the same encryption system as the apps on SD. But have have not had a chance to look at it.

Re: Ripping OAuth tokens out of Twitter apps

#23

Post by conradev »

bri3d wrote: post #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…

How about an Twitter client that allows you to specify your own consumer key and secret? It's really easy to go and create an application on Twitter's developer dashboard. Hell, the client could even walk you through the process.

The developer dashboard also makes it really easy to generate an OAuth token for your account, for the application you have created. So just inputting the OAuth token is also an option.

Even if these options are not opened up by an existing Twitter client of choice, one could just use code injection to force this behavior customization.

Twitter can't really filter new applications based on the number of users, either, because I'm sure that there are a number of blogs that use a custom Twitter application to tweet new posts, with the sole user being the website.

Twitter really doesn't have a good way of enforcing its new Display Requirements, or any such policy.

Re: Ripping OAuth tokens out of Twitter apps

#24

Post by maqr »

metoosorta wrote: post #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…

This should be the top comment. This blog post just shows URLs, which are the result of being signed with the 'consumer secret'. You can see the same thing with wireshark, charles, or any other sniffer or debugging proxy.

The more important thing is the consumer secret itself, which is discussed here: http://stackoverflow.com/questions/4419915/how-to-keep-the-o...

Re: Ripping OAuth tokens out of Twitter apps

#25

Post by mathrawka »

icefox wrote: post #17
mattgreenrocks wrote: post #13

Earlier quoted context omitted.

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).

I never dealt with any legal issues, but one day I noticed that licq.net was registered by AOL. I had the licq.org and licq.com (sold the .com years ago though), but always thought it was funny how they did a passive-aggressive move like that.

Re: Ripping OAuth tokens out of Twitter apps

#26

Post by slashclee »

slashclee wrote: post #7

I'm surprised he went to the trouble of using `DYLD_INSERT_LIBRARIES` - DTrace makes this sort of thing trivial.... something like: #!/usr/sbin/dtrace pid$1:$2:free:entry { printf("%s: %x\n", probefunc, arg0); } would do the trick, I think.

Nope, that'll just get you the addresses being freed. This, on the other hand, seems to do what I expected:

    dtrace -n 'pid$target::free:entry { printf("%s: %s", probefunc, copyinstr(arg0)); }' -p

Re: Ripping OAuth tokens out of Twitter apps

#27

Post by tommoor »

metoosorta wrote: post #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…

agreed, this post doesn't show any information you don't have permission to know being the authorised user of the application...

Re: Ripping OAuth tokens out of Twitter apps

#28

Post by rmccue »

maqr wrote: post #24
metoosorta wrote: post #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…

This should be the top comment. This blog post just shows URLs, which are the result of being signed with the 'consumer secret'. You can see the same thing with wireshark, charles, or any other sniffer or debugging proxy. The more important thing is the consumer secret itself, which is discussed here: http://stackoverflow.com/questions/4419915/how-to-keep-the-o...

You shouldn't be able to see it with Wireshark, given that it's HTTPS, but you should be able to MITM it (assuming you can make yourself a CA, that's trivial).

Re: Ripping OAuth tokens out of Twitter apps

#30

Post by franzus »

Fun Fact: You can get the API secret key out of twitter's official client. Which will allow you to use their xauth system (no browser oauth required - only enter username/password).

Also great for spambots: Twitter can't ban the app because then they had to ban their official Twitter clients.

/edit: have fun

    'key': 'Fpl5UUVwvaczUzzpVJ8Rlw'
    'secret': 'z73HF21zCz5CaxzDM6M0OPeaCBYGfHUG3FYBgcMB2Y'

    'key':  '3rJOl1ODzm9yZy63FACdg'
    'secret': '5jPoQ5kQvMJFDYRNE8bQ4rHuds4xJqhvgNJM4awaE8'
One is for tweetie 1.0 and the other is for the official twitter client.
Post reply on HN