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.
Demo
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...
Timeline
23.10 - discovered & confirmed vulnerability24.10 - contacted security@tumblr.com, auto response from support@tumblr.com
25.10 - vendor response, full details sent
28.10 - vulnerability fixed (token added to form), public disclosure
Final words
Tumblr: 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!
Posts
3 comments:
shame they blocked it...
I got 2-3 persistent XSS on Tumblr.com . Have reported it to them.
Lets hope they fix it soon. They should be having a bug bounty and hall of fame too, just like google. :)
If target is checking referer header in all ways. Then is it possible to bypass referer protection for CSRF?
Post a Comment