Skip to main content

Twitter API vulnerable to replay attacks

Reading about Google's security today reminded me of an vulnerability I discovered in the @ a while ago. October 4th to be exact. The response was a typical but as of this writing the replay attack vulnerability has not been fixed.

Replay attack
A replay attack is a form of network attack in which a valid data transmission is maliciously or fraudulently repeated or delayed. This is carried out either by the originator or by an adversary who intercepts the data and retransmits it, possibly as part of a masquerade attack by IP packet substitution.
Notification

My email to security@twitter.com on October 4th and their response.
A single OAuth request can currently be made repeated until the timestamp expires. For example the below url worked in a browser repeatedly.

http://api.twitter.com/1/account/verify_credentials.json?oauth_consumer_key=DC0sePOBbQ8bYdC8r4Smg&oauth_signature_method=HMAC-SHA1&oauth_timestamp=1286249576&oauth_nonce=2568844471&oauth_version=1.0&oauth_token=9436992-nlnplVVuWbpQ6pG2992RCK01cOaTpiUIZXnwZuD3W0&oauth_signature=iNjBZzaH46J0K/4dRG74GG9skoM%3D

Abraham

----------

Hi Abraham,

Thanks for the note. We'll check it out.

-Bob
Example

Here is a snap shot of a POST request to create a list named "replayattack" at 00:16:18 GMT. Shortly after I made a request with the same @ parameters at 00:17:57 GMT that succeeded in creating a second list with the slug of replayattack-20. Both request use the same oauth_timestamp, oauth_nonce and oauth_signature values.

Severity

How serious is this vulnerability? Well luckily the vector seems to be pretty small but I'm not a security expert so there could be hidden vectors I have not considered.
  • The initial request must to be intercepted by an attacker so the use of SSL and certificate verification should protect against the attack.
  • Replay requests are limited to five minutes after the initial request before the timestamp gets rejected.
  • Requests can not be modified or the request will be rejected for having an invalid signature.
  • Duplicate statuses and messages can not be posted because Twitter rejects duplicates of recent statuses.
  • Requests to private resources like messages or protected timelines have not only the response of the initial request but any statuses or messages created in the following five minutes as well.
Prevention

What can Twitter do to prevent this? Twitter can store nonces for five minutes and if a single nonce hits the API more then once reject the subsequent requests. The OAuth specification has this to say about nonces:
A nonce is a random string, uniquely generated by the client to allow the server to verify that a request has never been made before and helps prevent replay attacks when requests are made over a non-secure channel. The nonce value MUST be unique across all requests with the same timestamp, client credentials, and token combinations.
It is possible that Twitter decided to write off this vulnerability instead of trying to scale nonce checking for over 6 billion API requests every day.

Comments

Popular posts from this blog

CloudSense: the Future of Advertising

With the whole cloud taking off and more and more services switching to a push it into the cloud, leave it there until you need it, and pull it out model. I can only imagine what will be switching to this model soon. Oh wait. I can imagine.



Advertising!


Reading an article about how Avril Lavigne is supposed to have a $2 million check "appear" in her mailbox because of the absurd number of streams her videos get from YouTube got me thinking about creator compensation. The problem Avril is having is, a) Google wants to keep the money, and b) Google is having trouble figuring out how to monetize video streams. But on a grander scale it is whoever puts the ads on the page that gets the money not the content creator.

Little known @Twitter and @TwitterAPI tips and tricks

Be sure to comeback as new tips and tricks get added. If you know of anything I missed be sure to let me know.

Static URL for profile images based on screen_name:

https://api.twitter.com/1/users/profile_image/abraham

* This performs a http redirect to the actual profile image URL. Currently https redirects to http. You can also add "?size={mini | bigger | normal}" to get specific sizes.

Redirect to profile based on user_id:

https://twitter.com/account/redirect_by_id?id=9436992

In_reply_to_status_id mentions:

https://api.twitter.com/1/statuses/update.json?status=reply+to+@abraham&in_reply_to_status_id=12410413197

* In the web interface new mentions are only replies if they start with @screen_name. By pushing @screen_name further along in the string your followers who do not follow @screen_name will still see the status.

Profile image sizes:

http://a3.twimg.com/profile_images/54160223/chart-black-small.png

* By default you get the original image size you can add _mini, _normal, and …

Installing Storytlr the lifestreaming platform

"Storytlr is an open source lifestreaming and micro blogging platform. You can use it for a single user or it can act as a host for many people all from the same installation."

I've been looking for something like Storytlr for a few months now or at least trying to do it with Drupal. While I love Drupal and FeedAPI I did not want to spend all that time building a lifestream website. So I've been playing around with Storytlr instead and found it very easy. Here is how I got it up and running on a Ubuntu EC2 server. You can also check out the official Storytlr install instructions.

Assumptions:
LAMP stack installed and running.Domain setup for a directory.MySQL database and user ready to go.Lets get started!
Get the code: wget http://storytlr.googlecode.com/files/storytlr-0.9.2.tgz tar -xvzf storytlr-0.9.2.tgzYou can find out the latest stable release on Storytlr's downloads page.

Import the database:
Within protected/install is database.sql. Import this into your empt…