You can see the full code on Dabr’s Google Code page.

First of all, you’ll need to have enabled OAuth for your Twitter client. I use Abraham’s excellent OAuth libraries for PHP.

This tutorial assumes you already have OAuth working. I’ll attempt to explain what I’m doing as I go along – but the code should be pretty readable.

Start by reading the Twitpic API documentation. You will also need to register for an API key – this only takes a few seconds.

We start by setting CURL’s headers to those required by Twitpic

Next, we create the OAuth credentials that we need. Essentially, we’re signing a URL request. We then pass that on to Twitpic and they verify it with Twitter. We never pass our OAUTH_CONSUMER_SECRET – so Twitpic can’t impersonate us.

We add these generated credentials into the header.

Add everything into CURL

The data we send to Twitpic (message text, image and key) have to go via POST.

All done, we now send the data to Twitpic.

If this has worked, Twitpic will pass back the URL of the image we posted. We then need to post the entire message to Twitter ourselves (Twitpic can’t do it for us).

This next part is specific to Dabr – your client may post things differently.

If it didn’t work, Twitpic will tell us why.

Share This

The easy bit.

It’s easy to post the data to Twitpic

$media_data = array(
	'media' => '@'.$_FILES['media']['tmp_name'],
	'message' => html_entity_decode($_POST['message']),
	'key'=>'123465789132465'
);
curl_setopt($ch,CURLOPT_POSTFIELDS,$media_data);

OAuth Credentials

Using Abrahams OAuth library for PHP, it’s easy to get the required OAuth data.

require_once('OAuth.php');
// instantiating OAuth customer
$consumer = new OAuthConsumer(OAUTH_CONSUMER_KEY, OAUTH_CONSUMER_SECRET);
// instantiating signer
$sha1_method = new OAuthSignatureMethod_HMAC_SHA1();
// user's token
list($oauth_token, $oauth_token_secret) = explode('|', $GLOBALS['user']['password']);
$token = new OAuthConsumer($oauth_token, $oauth_token_secret);

// signing URL
$fakeurl = 'https://twitter.com/account/verify_credentials.xml';
$request = OAuthRequest::from_consumer_and_token($consumer, $token, 'GET', $fakeurl, array());
$request->sign_request($sha1_method, $consumer, $token);
$OAuthurl = $request->to_url();

The Tricky Bit

I’m following the header example in the API documentation. Passing these variable to Twitpic is where I seem to go wrong.

$header = array(
'X-Auth-Service-Provider: https://api.twitter.com/1/account/verify_credentials.json',
'X-Verify-Credentials-Authorization: OAuth realm="http://api.twitter.com/"'
);

I then modify the second header so it reads

"X-Verify-Credentials-Authorization: OAuth realm="http://api.twitter.com/",
oauth_consumer_key="aaaaaaa",
oauth_nonce="bbbbbbbbbbb",
oauth_signature="ccccccccccccc%3D",
oauth_signature_method="HMAC-SHA1",
oauth_timestamp="123456798",
oauth_token="15948715-dddddddddd",
oauth_version="1.0""

The Error

401 “Could not authenticate you (header rejected by twitter).”

GAH!

Share This

I wracked my brains thinking about how they could have gotten in there before I realised it was a long-dormant friend who had changed their name and avatar.

But, in thinking about how a spammer could infiltrate one’s timeline, I think I came up with a fairly bullet-proof method to spam Twitter users.

I present this as an exercise in devious thinking – and also to show how our assumptions about security can play against us. Remember, hacking and impersonation are likely to be illegal in your jurisdiction.  This information is designed to help you understand how security weaknesses can occur.

Being Evil

Imagine you are a nasty, evil Twitter spammer. Your own mother wouldn’t spit on you if you were on fire – that’s how mean you are. Here’s what you do.

1. Obtain a user’s password.  Admittedly, this is the hardest part of the process. You might use a dictionary attack, use the same password they use to log in to another site, or somehow steal it.
2. Log on to Twitter.
3. Go to “Connections” and see which services they have connected to using OAuth.  For the purposes of this experiment, let’s assume they use Example.com.
4. Go to Example.com and OAuth yourself with Twitter using your mark’s credentials.
5. Here’s where the ordinary spammer falls down.  The ordinary spammer will start sending out messages from the mark’s account.  That’s not the aim of this weakness.
6. From the mark’s account, through Example.com, make your victim follow one of your spam accounts.  An account which exists solely to show adverts to your victim.

Your victim now sees your adverts for pills, poker and porn in their timeline.  With any luck, they’ll just assume that one of their true friends is promoting your illicit wares.

Counter Attack

Most victims will assume that they accidentally followed your spam account – or that one of their friends has been hacked.

Worst case scenario, they unfollow your spam account.

So you just make them follow you again! Remember, you are still OAuth’d to Example.com. You can make them follow as many of your spam accounts as you think you can get away with.

At this point, the intelligent victim will think that their account may be compromised and change their password.

It doesn’t matter! Because you have used OAuth, password changes don’t affect you.  You can continue make them follow as many of your spam accounts as you think you can get away with.

At this point, the really intelligent victim will go through their OAuth connections to look for something suspicious.  They won’t find it.  Remember steps 3 and 4?  You are OAuth’d to a service that your victim trusts.

Because of the way Twitter displays OAuth information, there’s no way for a victim to know when a service was last authorised.

Twitter OAuth Connections

There is no information other than the first time the OAuth was set up.  No last accessed date, no IP addresses, nothing useful.

When following an account, the victim gets no notification of what has happened, when it has happened or how it has happened.  There is no way of them knowing which of their OAuth’d connections have been compromised, nor when it happened.

Their only safe option is to revoke every single OAuth connection.  Then reauthorise.  A time consuming and annoying prospect.

Conclusion

I hope I’ve demonstrated two things.

Firstly, there’s more to spam then just sending out messages.  Forcing someone to read a message is just as annoying.

Secondly, our understanding of security and usability haven’t quite caught up with the new tools which are available to us.  OAuth is still better than giving your password to an untrusted site – but without essential usability changes, a compromised account is a lot more dangerous than the user would suspect.

This “attack” still relies on a victim having their original password compromised.  That’s not a trivial matter.  But security is like sexual health – it only takes one little accident…

Share This

Usually, I would be a big fan of this move – especially if it forces password anti-pattern sites like TwitPic to implement the new, secure standard.

This means that you won’t be able to log in to a third party site by giving them your username and  password.  You will have to use OAuth to securely validate with the main Twitter site.

But – as ever – there’s a dark side to OAuth.

Repressive Regimes

One of the joys of Twitter is that its clients are decentralised from the main site.

This means that if Twitter is blocked in your country, you can use a third party client (like Dabr) to access it.

Twitter User -> Dabr -> Twitter API -> Dabr -> User

If Dabr became sufficiently popular to be blocked by an oppressive regime, you can switch to any one of the thousands of Twitter web clients.

OAuth forces you to the main Twitter site.  While you may visit Dabr to start with, you would be redirected to Twitter to complete OAuth.  If Twitter is blocked, you can’t connect.

At a stroke, Twitter has shut itself off to anyone in a repressive country.

This has been picked up by some concerned users.

A (Hacky) Way Around It

There’s really only one way around this problem.  The third party web client has to act as a man-in-the-middle.  There’s a patch for Dabr – developed by cnyegle – which will ask for a username and password, then proxy it to Twitter, get the OAuth token and tweet on behalf of the user.

From the user’s point of view, they are still giving the (potentially untrusted) site the username and password.

Challenge Response

This could be solved by implemented a challenge / response system.

1. Alice visits the Dabr website.
2. Dabr asks Alice for her username (and only her username)
3. Dabr asks Twitter for the challenge associated with Alice’s username.
4. Twitter checks that Dabr is an authorised website (i.e. has signed up for OAuth).
5. Twitter returns the response:  A secret phrase which Alice has previously chosen.
6. Dabr displays this phrase to Alice.
7. Alice knows that Twitter trusts Dabr
8. Dabr asks Twitter for the password challenge.
9. Twitter returns that it requires the 3rd, 5th and last character from Alice’s password (the characters requested change randomly).
10. Dabr asks Alice for only those characters.
11. If Alice provides the correct characters, an OAuth token is granted to Dabr to tweet on behalf of Alice.

This has the advantage of proving that Dabr is trusted (by displaying Alice’s pre-defined secret phrase) and mitigating the risk that Dabr is untrusted (by only revealing part of the password).

Conclusion

This is a very new area, and I’ve not had a chance to read through all of the proposals.  Nevertheless, it remains a fundamental problem that, if you can’t access a site, you need to delegate your trust to someone else.

I’m not a security expert – so I would appreciate someone pointing out the flaws in my reasoning.

Share This

For a service which started out operating by SMS, Twitter takes a surprisingly unenlightened view of mobile. It’s main mobile service – http://m.twitter.com/ – is almost completely devoid of useful features. That’s one of the main impetuses behind the development of Dabr. Their latest mobile site – http://mobile.twitter.com/ – is really only suitable for the tiny minority of people who have smartphones.

So, understandably, many people use 3rd party sites like Dabr. They are now faced with a dilemma – give an untrusted site their username and password or try to use OAuth on the mobile.

A few weeks ago came the announcement that OAuth was finally ready for mobile… Was it? No. Once again a “mobile friendly” site designed with masses of JavaScript and guaranteed not to work with the majority of phones on the market.

Here’s how mobile OAuth looks on a variety of popular mobile phones.

BlackBerry

BlackBerry Twitter OAuth

While this looks pretty enough, it doesn’t work. The buttons aren’t clickable. I’ve tried with and without JavaScript. No matter where I click, nothing happens.

Android

The Android’s User-Agent isn’t detected by Twitter as being a mobile phone. While it’s true that the browser is very capable – the OAuth screen is a lot more usable when it’s in mobile mode.

Android Twitter OAuth

So, it works, but it doesn’t look nice.

N95

The N95 makes a good test phone because it’s popular. Probably more popular than the iPhone.

N95 Twitter OAuth

N95 Twitter OAuth

It’s not pretty – but at least it works.

Others

The Sharp GX-10 is my default test phone. One of the first phones with a colour HTML browser. If your site can work on this phone, it will work on any phone. There are no screenshot capabilities for this phone – but rest assured, it does not work.

The three phones I’ve demo’d above are very popular modern phones – AKA the minority. If they don’t work well, what chance for the people using older phones?

Useless! How hard can it be? All it needs is a username field, a password field and a button. That’s just about the most basic page imaginable. It should be child’s play to make it work on mobile.

This was first raised in March 2009 on Twitter’s issues list. It’s currently the most popular bug.

So, we’re stuck in a dire situation. Third-Party mobile sites get access to Twitter users’ passwords because Twitter are unable or unwilling to develop a simple OAuth form. It would be fascinating to know how many of Twitter’s security breaches are down to corrupt or insecure 3rd party sites which leak passwords.

Share This

I received a rather worrying email from Twitter.  Apparently they thought my password had been compromised and needed to be reset.

Reset Your Twitter Password

After checking to see if it was valid, I went and changed my password.  Any site which relied on a cookie to post to Twitter would have been blocked out. Ha! Gotcha, suckers!

The OAuth Problem

OAuth tokens are not revoked when the master password is changed.

OAuth is a great idea – rather than give your username and password to any random site, you log on to Twitter and tell them that you authorise the refering site.  The site gets an OAuth token and never gets to see your password.  Great! Right? Not really.

Let’s consider the following scenario.

Alice has a Twitter username and password.

Bob runs a Twitter site.

Alice visits Bob’s site.  Alice is security conscious and uses OAuth.

Eve somehow discovers Alice’s password.

Eve also visits Bob’s site and uses OAuth.

Alice gets suspicious about strange activity on her account and changes her password.

Because Bob’s site uses OAuth, it does not require either Alice or Eve to re-enter Alice’s password.

In this scenario, Alice has to visit Twitter’s OAuth Connections page and revoke access to all the sites she has previously connected to.  Alice has no way of knowing when each site was last accessed.  She also doesn’t know which site Eve is using.

Twitter's OAuth Page

The Problem

Changing a password should – in the minds of most people – mean that you need to re-enter your password even if you have previously authenticated yourself.

In this scenario, changing the password does not revoke access to malicious users who have previously used your credentials.

Twitter should revoke all OAuth tokens when a user’s password is changed. It is the only way to ensure that stolen credentials cannot continue to be used after a user has changed their password.

Addendum

As I’ve made clear in the comments – this isn’t a vulnerability within OAuth per se.  It’s a usability issue which has strong security implications.

I spoke to Eran Hammer-Lahav (listed as OAuth’s advisory contact) who said:

If you suspect someone stole your password, you should revoke any tokens you did not personally authorized. But there is no reason to revoke tokens just because you are changing password.

While I appreciate this as the official line from those in the know, it does nothing to prevent a user who uses the same sites as you.  For example, I can see on every tweet that you use Dabr.  Therefore, I can safely OAuth myself as you on Dabr.  You’ll change your password, but you won’t revoke Dabr’s token because you personally authorised it.

Continuing The Conversation

Heise Online provides comentary in German (English version)

El Reg has a feature about Twitter and OAuth.

There’s also an interesting discussion over at Hacker News.

Share This