Tagged: https

Path - Privacy & Security Problems

I'm trying out the new Android app for Path - the new social networking service. I've discovered something rather troubling...

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.

path ssl

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?

A (Minor) Twitter Privacy Bug?

Quick Summary

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