Ripping OAuth tokens out of Twitter apps

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.

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.

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 can have the nicer UX of the official client.

    invoke-virtual {v0, v1}, Ljava/lang/StringBuilder;->append(Ljava/lang/String;)Ljava/lang/StringBuilder;

    move-result-object v0

    invoke-virtual {v0}, Ljava/lang/StringBuilder;->toString()Ljava/lang/String;

    move-result-object v0

    // Added logging
    const-string v1, "PrivateKey"
    invoke-static {v1, v0}, Landroid/util/Log;->d(Ljava/lang/String;Ljava/lang/String;)I

    const-string v1, "UTF8"

    invoke-virtual {v0, v1}, Ljava/lang/String;->getBytes(Ljava/lang/String;)[B

    move-result-object v0

    new-instance v1, Ljavax/crypto/spec/SecretKeySpec;

    const-string v2, "HmacSHA1"

    invoke-direct {v1, v0, v2}, Ljavax/crypto/spec/SecretKeySpec;-><init>([BLjava/lang/String;)V


  D/PrivateKey(18590): XXXXXX
  D/Auth Header(18590): OAuth realm="http://api.twitter.com/", oauth_version="1.0", oauth_nonce="2404904914329321765488437936138011", oauth_timestamp="1345512606", oauth_signature="gEvQOcGWO7aPCYTemRy%2BkYH3oFM%3D", oauth_consumer_key="3nVuSoBZnx6U4vzUxf5w", oauth_signature_method="HMAC-SHA1"

You can often find things even more simply if they're just embedded in the binary and you know what format you're looking for.

This, for example, goes fishing for MD5 hashes:

  /Applications> find *.app/Contents/MacOS -maxdepth 1 -perm 755 -type f -print0 | \
    xargs -0 strings | grep '^[0-9a-f]\{32\}$'

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.

The printed output strings look like HTTPS requests. Wouldn't it have just been simpler to use Charles to run an SSL MitM attack? I highly doubt these twitter clients check what certificate they're using beyond whether it's trusted.

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.

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.

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?

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.