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

Microsoft Pinpoint vulnerable to DOM XSS

Using a third-party web application, Microsoft Pinpoint site was vulnerable to a DOM XSS that could be used by malicious users to launch attacks.
A user could access Ensighten Real-Time Tag Management System by adding the URL parameter "ensightenVT=1" on the pinpoint.microsoft.com. This would allow to check a couple of Ensighten options.

Proof of concept #1:

http://pinpoint.microsoft.com/en-US/applications/search?sort=rating&q=nothing&fcrc=PRT&ensightenVT=1

After this point, a reflected DOM XSS it's present on a couple of places and adding the vector on the previous URL:

Proof of concept #2:

#"><img src=x onerror=prompt(1);>

... and navigating on some Ensighten options, the vector would execute successfully and automatically.
This was due to a lack of sanitizing location.hash.

Microsoft Security Response Center replied:

Thank you for reporting this to us.  I want to let you know that we have been able to finish our review of this issue and have fixed this in an online services update.  I would like to provide you with an acknowledgement for working with us on our Online Researcher Acknowledgement page at http://technet.microsoft.com/en-us/security/cc308589.

After getting my name on Google and eBay, currently I'm also listed on Microsoft: (http://technet.microsoft.com/en-us/security/cc308589).

Timeline:
19 Mar 2013: Reported to Microsoft
19 Mar 2013: Microsoft reported that will take a look into it
22 Mar 2013: Microsoft reported that this issue is fixed in an online services update
13 Jun 2013: Full disclosure

Jobs.cz XSS vulnerability

I found that is possible to conduct a XSS attack on career site on jobs.cz by manipulating the URL and injecting Javascript. That way when the user clicked on the link "Apply" - to a job - it will launch the attack.

This could be used to trick innocent users applying to a job on a big company (Jobs.cz customers). When they're clicking on the Apply they could been victims of, for example, redirections to malware sites or drive by downloads.

Proof of concept:

http://xxxxxxx.jobs.cz/lang/577198204/xxxxxxxx?brand=g2&exportRCM=43374188&trackingBrand=unknown';alert("xss by @dsopas");//&rps=186&ep=

Keep in mind that Jobs.cz have many important clients like Accenture, KPMG, DHL, ŠKODA AUTO, Telefónica, T-Mobile, BOSCH Group, GE Money, Vodafone, Ernst & Young, SIEMENS, Avast and many others.

I would like to thank the Jobs.cz security team for keeping me updated and providing a solution to this issue very fast. It's always glad to see companies that care about security and appreciate help from outsiders.

Timeline:
23 Apr 2013: Reported to Jobs.cz
24 Apr 2013: First contact with Jobs.cz technical support
25 Apr 2013: Update from Jobs.cz security team
13 May 2013: Patched
13 Jun 2013: Full disclosure

IDG Now! vulnerable to reflected XSS

IDG Now! is one of the most popular brazilian IT online mags and a reference in portuguese language. It has millions of visits each day and a large community on social networks.

The site suffered from a reflected DOM XSS present on the JavaScript code for the AnythingSlider.

Vulnerable code:

a.gotoHash = function() {
var c = a.win.location.hash,
(...)

The location.hash wasn't sanitized and it was possible for a user to manipulate the URL injecting a XSS vector.

Proof of concept:

http://idgnow.uol.com.br/#<img src=x onerror=prompt(1);>

Also, the jQuery version was outdated.

The Developing team for IDG Now! reported that they fixed the DOM XSS issue and updated the jQuery framework.

Timeline:
23 Mar 2013: Reported to IDG Now!
26 Mar 2013: Fixed by their developing team.
23 Apr 2013: Full disclosure.

phpMyAdmin XSS

For those who don't know phpMyAdmin, is a free software tool written in PHP, intended to handle the administration of MySQL over the World Wide Web. phpMyAdmin supports a wide range of operations with MySQL. The most frequently used operations are supported by the user interface (managing databases, tables, fields, relations, indexes, users, permissions, etc), while you still have the ability to directly execute any SQL statement.

When using it on a client I found out that, under versions 3.5.3, 3.5.4  and 3.5.5, it was possible to inject a self-XSS.

The vulnerability is under "Query results operations" - "Display Chart" and "Title" field. When writing the title with a XSS vector the code is automatically executed.

Proof of concept:

Chart title"><script>alert("xss by @dsopas")

This bug was fixed (version 3.5.6) but per their policy for self-XSS, they decided against a
security release.
The commit is https://github.com/phpmyadmin/phpmyadmin/commit/d30aaae.

Timeline:
10 Jan 2013: Reported to phpMyAdmin security team
10 Jan 2013: They replied and told me that they're investigating
15 Mar 2013: I asked for update - reported that it is already been fixed since January
12 Apr 2013: Full disclosure