Tumblr.com is a microblogging platform with over 32 millions of users, with Alexa global rank of 45. Tumblr.com had a CSRF vulnerability on blog settings page
http://tumblr.com/tumblelog/[blog-name]/settings that allowed for launching targeted attacks against a specified blog to hijack its domain and perform other potentially severe actions on behalf of a victim user.
The page allowed POST requests with new blog settings. It did not have any CSRF tokens (like other forms at Tumblr), but used HTTP referrer checking instead. Requests with 3rd party referrer value triggered 403 Forbidden error. However, empty referrers went through. And that was bypassable by client side referrer strip.
Blog settings form allowed attacker to:
- change blog domain name (leaving the original free to hijack for the attacker)
- forward blog RSS requests to given FeedBurner URL (hijacking RSS subscribers)
- change user's avatar (defacement)
- mark / unmark the blog as NSFW
- and other similar things...
The whole technique required no user intervention and worked in Chrome, Safari or Firefox. To exploit this vulnerability attacker needed to:
- know the blog domain name (e.g. http://victim.tumblr.com)
- entice owner of target domain (being simultaneously logged in to Tumblr) to visit webpage with malicious code
// change the location to data URI meta refresh to lose referrer // the final page loaded will include exploit script location = 'data:text/html,<html><meta http-equiv="refresh" content="0; url=data:text/html,<body><h1>Loading...</h1><script src='+location.href+ '/../../lib/common.js></scr'+'ipt><script src=' + location.href + '/../exploit.js></scr'+'ipt></body>"></html>';
The actual exploit code stored in exploit.js is nothing fancy, so it's left as an exercise to the reader. It's a Cross Origin Resource Sharing CSRF request with silent file upload. So Tumblr joins the gallery of top sites with CSRFable file upload forms, together with Flickr, Imgur, Facebook and minus.com.
This attack has limited applicability as attacker needs to POST to a URL containing blog domain name, so it's usable in targetted attack scenario. This is a demo of such an attack. Watch the story of Darth Vader who is looking for Han Solo...
Timeline23.10 - discovered & confirmed vulnerability
24.10 - contacted email@example.com, auto response from firstname.lastname@example.org
25.10 - vendor response, full details sent
28.10 - vulnerability fixed (token added to form), public disclosure
Final wordsTumblr: have a dedicated security contact listed somewhere on your website. Putting security vulnerabilities reporting to standard support queue is not a good idea!
Developers: use tokens, don't rely on referrer!