Tumblr got DOM XSSed

When using this awesome blog platform - which hosts more than 138,4 million blogs - I come across a vulnerability that could be used my malicious users to a variety of illegal activities (steal user credentials, spread malware, spamming, etc).
This vulnerability could put millions of web surfers at risk of malicious user attacks.

The affected file was located at http://assets.tumblr.com/assets/scripts/tumblelog_iframe.js.
A couple of variables (name and title) weren't properly sanitized within the source location.hash. So basically anyone could explore it by injecting HTML and launching a reflected DOM XSS attack - https://www.owasp.org/index.php/DOM_Based_XSS.

Vulnerable code:

(...)
if (v) {
v.innerHTML = decodeURIComponent(e.get.name)
}
(...)
document.getElementById("name").innerHTML = r;
document.getElementById("title").innerHTML = decodeURIComponent(x).replace(/\+/g, " ");
(...)

Proof-of-concept:

http://assets.tumblr.com/assets/html/iframe/o.html?_v=0e885d75acad691664be152f8a0af5b0#src=http%3A%2F%2Fstatus.soundcloud.com%2Fpost%2F55089207412%2Fmaintenance-tomorrow-morning&pid=55089207412&rk=Obe5imR3&lang=en_US&name=soundcloudstatus%3Cimg%20src=x%20onerror=prompt%281%29;%3E&avatar=http%3A%2F%2F24.media.tumblr.com%2Favatar_d06f17cd8eb4_64.png&title=SoundCloud+Status&url=http%3A%2F%2Fstatus.soundcloud.com%2F&page_slide=slide

You didn't even need to be authenticated in Tumblr.

Tumblr patched it by using a sanitize function in the Javascript file:

(...)
document.getElementById("name").innerHTML=_t.sanitize(r,true);
document.getElementById("title").innerHTML=_t.sanitize(x,true).replace(/\+/g," ");
(...)

It took more than two months to fix this reflected DOM XSS. And this isn't the first time that Tumblr ignores this kind of vulnerability. On June 25, 2012 the researcher Riyaz Walikar found and published a persistent XSS (http://www.riyazwalikar.com/2012/07/stored-persistent-xss-on-tumblr.html) that was only patched by Tumblr when it got public. They ignore his emails disclosing the vulnerability.

I really hope that in the future Tumblr patches this kind of security issues faster.

Timeline:
11 Jul 2013: Reported to Tumblr
11 Jul 2013: Tumblr reported that they're looking into it
17 Jul 2013: I asked for an update
17 Jul 2013: Tumblr reported again that they're looking into it
06 Aug 2013: I asked for other update
13 Aug 2013: Tumblr reported that they reviewed the exploit and were taking appropriate actions on their end
20 Set 2013: I noticed that the security issue was fixed and never got any reply.
24 Set 2013: Full disclosure

Your weekend reading about web security

During this week I tweeted this articles but I found interesting compiling it.

- Slow DoS on the Rise https://blogs.akamai.com/2013/09/slow-dos-on-the-rise.html
- Reducing Security https://blog.whitehatsec.com/reducing-security/
- Non-alphanumeric Backdoors http://blog.sucuri.net/2013/09/ask-sucuri-non-alphanumeric-backdoors.html
- Case Study: phpbb.com Compromised http://blog.sucuri.net/2013/09/security-case-study-archive-phpbb-com.html
- Pixel Perfect Timing Attacks with HTML5 http://contextis.co.uk/files/Browser_Timing_Attacks.pdf
- Mac OS X Security Configuration Guides https://ssl.apple.com/support/security/guides/

Feel free to suggest some new articles. Just tweet @dsopas.

Gizmodo, Lifehacker, Gawker - reflected DOM XSS

I'm a big follower of many of Gawker Media websites - like Lifehacker and Gizmodo - and with that in mind I try to help them on their security level.

Just cruising along in Gizmodo website I found a problem that caught my attention.
A request to a file called ad_iframe.html on assets directory. Checking the source code of that file I found:

<script>
var location_parts = window.location.hash.substring(1).split('|');
var rand = location_parts[0];
var scriptsrc = decodeURIComponent(location_parts[1]);
document.write("<scr"+"ipt src='" + scriptsrc + "'></scr"+"ipt>");
</script>

The variable scriptsrc isn't properly escaped from the source location.hash.
Just giving the expected hashtag and pipe chars, a user could exploit this vulnerability with a DOM XSS to achieve information.

How can this be exploited?

Proof-of-concept on Gizmodo:

http://gizmodo.com/assets/ad_iframe.html#|'></script><script>alert("xss by @dsopas");</script><div x='

Proof-of-concept on Gizmodo (encoded):

http://gizmodo.com/assets/ad_iframe.html#|'>%3C%2F%73%63%72%69%70%74%3E%3C%73%63%72%69%70%74%3E%61%6C%65%72%74%28%22%78%73%73%20%62%79%20%40%64%73%6F%70%61%73%22%29%3B%3C%2F%73%63%72%69%70%74%3E%3C%64%69%76%20%78%3D%27

A malicious user could also:

• access other sites inside another client's private intranet.
• steal another client's cookie(s).
• modify another client's cookie(s).
• steal another client's submitted form data.
• modify another client's submitted form data (before it reaches the server).
• submit a form to your application on the user's behalf which modifies passwords or other application data

This DOM XSS vulnerability was present in many Gawker Media websites:

http://gawker.com/assets/ad_iframe.html
http://gizmodo.com/assets/ad_iframe.html
http://lifehacker.com/assets/ad_iframe.html
http://deadspin.com/assets/ad_iframe.html
http://io9.com/assets/ad_iframe.html
http://jalopnik.com/assets/ad_iframe.html
http://jezebel.com/assets/ad_iframe.html
http://kotaku.com/assets/ad_iframe.html

I want to thank Gawker Media tech team for fixing this issue in less than 24 hours. They really care about security and their users.

Timeline:
02 Set 2013: Reported to Gawker Media
03 Set 2013: Gawker Media replied that a fix has been deployed
06 Set 2013: Full disclosure

Mashable DOM XSS

Recently I found a security issue on Mashable website.
Vulnerable code was:

(...)
var customOpts = optsFromUrl(window.location.hash);
(...)
src = appendKeyVal(src, 'ord',      opts.options);
(...)
buffer += '<script class="ad_call" src="' + src + '"><\/script>';
(...)
document.write(buffer);
(...)

The source location.hash wasn't properly sanitized for injections and that way could be used to inject a XSS vector into the browser DOM by using the sink document.write.

Proof-of-concept:

http://mashable.com/#type=left_column&ord=499753815940197_"><img src=x onerror=prompt(1);>&tile=1&sec0=home&sec1=index&escnotcategory=iframe&bg=#39ebd1&adnum=1

This type of attack could be used to trick innocent users, infecting them with malware and even get their accounts hijacked.

Timeline:
22 Ago 2013: Reported to Mashable
26 Ago 2013: Mashable replied that they will fix it
29 Ago 2013: Fix is released
03 Set 2013: Full disclosure