Dowjones.com DOM XSS

Dow Jones & Company is an American publishing and financial information firm.
The company was founded in 1882 by three reporters: Charles Dow, Edward Jones, and Charles Bergstresser. Like The New York Times and the Washington Post, the company was in recent years publicly traded but privately controlled. The company was led by the Bancroft family, which effectively controlled 64% of all voting stock, before being acquired by News Corporation.

(in Wikipedia)

In January I found a couple of issues on a Eloqua script (which I don't got any reply, even after I tried to contact them for more than 5 times). This script is used by Dow Jones site. Let's take a look into the vulnerable code:

if (document.referrer) { elqRef2 = document.referrer; }
if (navigator.appName == 'Netscape' || navigator.userAgent.indexOf("Opera")!=-1) { document.write('<la' + 'yer hidden=true><im' + 'g src="' + elqCurE + '?pps=3&siteid=' + elqSiteID + '&ref2=' + elqRef2 + '&tzo=' + elqTzo + '&ms=' + elqMs + '" border=0 width=1 height=1 ><\/la' + 'yer>');}
else { document.write('<im' + 'g style="display:none" src="' + elqCurE + '?pps=3&siteid=' + elqSiteID + '&ref2=' + elqRef2 + '&tzo=' + elqTzo + '&ms=' + elqMs + '" border=0 width=1 height=1 >');}

As you can see it was possible to manipulate the document.referrer and write (due to document.write) present on the Eloqua javascript.

How was it possible to attack it?

#1
Simple creating a HTML page with a link to the dowjones.com site, with the XSS vector, the code is executed on the browser.

http://www.example-site.com/?"><img src=x onerror=prompt(1);><!--

example-site.com will have a link to dowjones.com. When a user click on that link it will redirect to dowjones.com and execute the XSS vector on that page.

#2
This proof-of-concept is much easier to implement. When a user change the page inside dowjones.com, it will execute the XSS vector.

www.dowjones.com/?"><h1>XSS</h1><!--

You can even play around encoding a little bit to obsucate from inexperient users.

www.dowjones.com/%3F%22%3E%3Ch1%3EXSS%3C%2Fh1%3E%3C!--

Both examples could be used by malicious users to trick victims on scams and even to spread malware.

Dow Jones already fixed this and their solution was to simply remove the script.

Timeline:
21 Mar 2013: Sent this information to Dow Jones
22 Mar 2013: Got a reply
11 Apr 2013: Requested a update about this vulnerability
12 Apr 2013: Got a reply that they were fixing it
03 Jun 2013: Noticed that the issue was fixed and requested an update from Dow Jones (no reply so far)
17 Jul 2013: Full disclosure

Prestashop persistent XSS and CSRF vulnerability

Continuing to test Prestashop security I just found out a vulnerability on the latest version (and maybe prior versions).
Logistician, translators and other low level profiles/accounts could inject a persistent XSS vector on TinyMCE to affect users and even admins.
This is possible due to a flaw on TinyMCE which doesn't filter some events (blocks only a couple of them) on HTML.

Proof-of-concept on a combined CSRF attack (logged in as logistician):

On a CMS page, enter the following HTML in TinyMCE (on HTML mode) <img onmouseover="window.location.href = 'http://www.website-example.pt/loja/admin9050/index.php?logout'" src="x" alt="" />

When the admin hover the image, he will automatically logout from the admin panel.
With a little imagination this issue can be used to spread malware or grab users credentials (popping up a screen to login) to visitors, authenticated users or even admins. (CVE-2013-4791)

Also logout GET request should also have a token protection. Just to prevent CSRF attacks. (CVE-2013-4792)

Keep in mind that the latest version of TinyMCE it's patched against this issue.
By the way I tested under PrestaShop 1.5.4.1.

Prestashop developing team replied:

We have fixed this problem in our 1.4.11 release, and we will also put this patch in our next 1.5 release before the end of July.

Timeline:
05 Jun 2013: Reported to Prestashop
11 Jun 2013: Replied that their team were working on it
02 Jul 2013: Prestashop released a fix to this issue
08 Jul 2013: Full disclosure

Issuu DOM XSS

For those who don't know Issuu...

Issuu is an online service that allows for realistic and customizable viewing of digitally uploaded material, such as portfolios, books, magazine issues, newspapers, and other print media. It integrates with social networking sites to promote uploaded material. While most of the documents are meant to be viewed online, some can be downloaded and saved as well. Uploaded print material is viewed through a web browser and is made to look like a printed publication with an animated page flip option. 

I found out that was possible to inject a DOM XSS vector on their code. The vulnerable code was present at embed.html in the following line:

document.write('<div data-configid="' + location.hash.replace('#', '') + '" class="issuuembed"></div>');

location.hash.replace wasn't properly escaped and could be used to lauch DOM XSS attacks by malicious users using sink document.write. This could be exploited in phishing attacks or to trick innocent users to click on malicious links (with malware).

Proof of concept:

http://e.issuu.com/embed.html#1200954/2011806"><a href=# onmouseover=alert(1);>Click here</a><div x="

This DOM XSS vectors could be modified to work on each browser.

Timeline:
17 Jun 2013: Reported to Issuu
17 Jun 2013: Issuu reported that they'll fix it ASAP
25 Jun 2013: Issuu reported that they fixed it
01 Jul 2013: Full disclosure