Most of the app’s communication with the Path servers is over SSL. This means that no-one can see the data you’re sending and receiving. If there are snoops on your network, they will only be able to see the encrypted data flowing back and forth. In general, this is a good thing.

Apart from images. If your friends are posting images, they are sent over http. No security. Anyone monitoring your network connection will be able to see all the images you’re viewing.

Now, that’s bad enough – but it turns out that all the images you send are visible to the the world even if you’ve set your post to private.

The images are sent over SSL, but as soon as you return to your “Path”, a thumbnail is shown of what you’ve just posted!

Here’s a picture of the logs, so you can see what’s happening.

So, every image you post or see – including the avatars of your friends – are visible to all. A rather serious security and privacy problem.

Oh, does anyone know what the unencrypted call to “sendgrid.net” is all about?

Your carefully crafted code could be replaced by one which…

• Points to a rival’s site.
• Calls a premium rate phone number.
• Redirects the user to a site which EXPOSES THE TRUTH BEHIND…
• Goes to a non-legitimate site which asks for credit card / personal details.
• Downloads a virus or other form of malicious content.

It’s a real threat – thankfully it’s usually easy to spot. Especially in this case…

In the above image, it should be fairly obvious to anyone that the QR code has been replaced.

Combating QR Hijacking

There are some practical actions you can take to make sure that your code isn’t hijacked.

1. Say where your code will go. In your call to action say something like “Scan for our mobile site” that way, it should be obvious that a code which tries to call a premium rate number is fraudulent.
2. Don’t use short URLs. How can a customer tell if bit.ly/CYRWP goes to your site or to a rivals? Always use your domain name in your QR codes.
3. Place a logo in your QR codes. It’s not foolproof, but it means the hijacker has to work harder to look legitimate.
4. Use a light background colour for your code. It will mean the hijacker has to print on more expensive coloured paper and it is less likely to look like a seamless replacement.
5. Track down hijackers. If a your code is being redirected, try to track down those responsible.

Finding Joachim Schmid

I am fairly confident that the above inept defacement was by Joachim Schmid.
The above photo was taken at Olympia in London. The same defacement is recorded on the Nine Errors blog, which appears to be run by Schmid.
The photo on the Nine Errors blog was taken on November the 18th, according to the EXIF data.
Schmid was presenting his work at Olympia on November 18th.

The Nine Errors project is a slightly odd attempt by Joachim Schmid to “intervene” and redirect QR codes to error pages.

Need Help?

Want some bespoke QR advice? Give me a call.

Twitter’s secure API hides the contents of the tweets you are reading. But it doesn’t hide the images of those you converse with.

Raised as Issue 2175.

A Bit More Detail

Twitter has a secure (HTTPS) and insecure (HTTP) API.

When calling the secure API, all the content of the returned message (tweets) are encrypted. Eavesdroppers only see the cipher-text – essentially garbage.

However, within that cipher-text are links to insecure resources.

For example, a user requesting my tweets will get an object which contains a link to my avatar image.

Twitter is currently returning the insecure link:

"profile_image_url" :
    "http://a2.twimg.com/profile_images/1283757621/Sketch_Avatar.jpg"

Twitter should be returning the secure link:

"profile_image_url" :
    "https://si0.twimg.com/profile_images/1283757621/Sketch_Avatar.jpg"

Exploiting This Weakness

A user (Anna) will request the encrypted text of my tweets
She then requests the unencrypted image.
An eavesdropper (Eve) is listening in on the connection between Anna and Twitter.

Anna ---->Eve---->Twitter  (Secure request)
Anna <----Eve<----Twitter  (Secure response)

When Anna makes the initial request to Twitter, the malicious Eve can’t see what they’re talking about.

• The request “https://example.com/twitter/edent” is itself encrypted. Eve only sees an encrypted request to example.com – not “twitter/edent
• The response containing all the tweets is also encrypted

Anna ---->Eve---->Images  (insecure request)
Anna <----Eve<----Twitter  (insecure response)

Anna then makes the subsequent request for the twitter user’s image, a malicious user can see

• The URI of the request.
• The content of the image.

Impact

Truth is, this has a pretty low security impact.

• There is no way to determine a user’s name based on the URI for their image. (Unless you already have both).
• An eavesdropper has no way of knowing if the image is from the timeline, a reply, a DM, a search, a retweet, or the public timeline.
• Images may be locally cached by the user’s browser – so frequency analysis isn’t reliable.
• A malicious user could alter the image in transit.

Worst case scenario is that if a malicious man-in-the-middle knows which images relate to which Twitter users, they know the intercepted user has seen at least one tweet from that user.

Let’s say Anna is communicating with Bob. Eve is trying to eavesdrop.
If Bob has never tweeted, and Eve sees repeated requests from Anna for Bob’s avatar, she may reasonably surmise that they are exchanging DMs.

Overall

This is a pretty low-impact privacy risk.
It can be fixed by Twitter’s API returning HTTPS URIs where possible.
In the meantime, developers can replace “http://a2.twimg.com/” with “https://si0.twimg.com”.

Long time readers will know that I have some severe usability and security concerns with Twitter’s OAuth implementation. See also my interview in The Register.

Zach Holman has an entertaining and informative blog post about giving Twitter applications fine grained controls.

Essentially, he’s saying that you should be able to authorise an app for just posting, for example.
Here’s his graphic which I’ve stolen.

This doesn’t go far enough.

I was taking a look at this LinkedIn application which graphs your contacts.

Take a look at their OAuth screen.

At the bottom is an “Access Duration” option – giving you the option to try out the app and have it automatically revoke after a specified period of time.

Now, this isn’t something you’d want to do for every app. But it gives you a method to limit the damage that a malicious app can do. Remember, just because an app isn’t malicious today, doesn’t give you any guarantee about its future performance.

As it happens, the Oauth Specification 2.0 has this to say in section 4.2.2. Access Token Response

expires_in
         OPTIONAL.  The duration in seconds of the access token
         lifetime.  For example, the value "3600" denotes that the
         access token will expire in one hour from the time the response
         was generated.

If you run a service relying on OAuth, please consider giving users an Access Duration option.

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…

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.

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.

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.

What’s the next logical step? Viewing on your mobile, of course!

Two British companies have come up with some innovative – and cheap – technologies to make watching over your home as simple as picking up your phone.

Y-Cam

Y-Cam ready to be unboxed

Y-Cam is an Internet camera which looks like any other.

It works via ethernet or WiFi. A full compliment of acronyms and tech spec including, DDNS, NTP, user management, ftp, email. It’s got a decent VGA resolution. It has Infra-red for the all important night vision. In short, it’s got everything you’d expect from a standard IP camera.

Night Vision

But the Y-Cam has three little secrets.

The first is that you don’t need to be chained to your PC to watch what’s going on at home. The Y-Cam has an inbuilt RTSP server – so you can stream live video and audio directly to your handset!
If you’ve only got a 2.5G phone – that’s no problem, you can set the bandwidth to a level that’s suitable for your device.
Y-Cam have recently updated the device’s firmware to include BlackBerry support.

If you want a demo of the quality, visit Y-Cam’s live gallery.

The second secret is that it will email you photos when it detects motion. Because you can choose the size of the emailed photo, it’s perfect for receiving on your phone. Here’s a snap sent to my BlackBerry.

An email alert on a BlackBerry. Thumbnail image fills the screen when clicked

But, saving the best for last, Y-Cam works flawlessly with Linux. And Mac, if you’re in to that sort of thing. Everything from set-up, configuration and viewing works as well in FireFox as it does in IE. The only thing it won’t do is set up specific motion detection zones – that uses Active-X so can only be done with Internet Explorer. A minor blemish.

Motion detected!

The Y-Cam costs around £150. Bargain!

Peepr

The second is small British start-up Peepr.

Peepr take a decidedly low-tech approach. All you need is a PC and a Webcam. You visit http://peepr.tv/ and their Flash application hooks into your webcam & microphone. You’re now broadcasting on the web at and the mobile at http://peepr.mobi/

Peepr preparing to broadcast

Done. And it won’t cost you a penny.  Peepr will even attempt to SMS you if it detects motion.

Of course, it’s a lot less fully featured than the Y-Cam, but its power is in its simplicity.  If you’ve got a PC or laptop and a £9.99 webcam, you can have an instant view of your home whether you’re sat in the office, pub or train.

So, two pretty smart and simple ways to watch over your stuff from your phone.

Enjoy!