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

XSS on FCKeditor

What's FCKeditor?
FCKeditor is a ready-for-use open source WYSIWYG text editor from CKSource designed to bring common word processor features directly to web pages, simplifying their content creation. It aims to be lightweight and requires no client-side installation. This tool is already deprecated and was updated to CKEditor but still many open-source projects use FCKeditor.

When using Drupal and PHPList I come across something that caught my attention. The about page (fck_about.html) of FCKeditor showed a window with the User-Agent, Browser and Platform. I thought to myself: I think we can inject something into this window.

I checked the source code and voilà...

document.write( '<b>User Agent<\/b><br />' + window.navigator.userAgent + '<br /><br />' ) ;
document.write( '<b>Browser<\/b><br />' + window.navigator.appName + ' ' + window.navigator.appVersion + '<br /><br />' ) ;
document.write( '<b>Platform<\/b><br />' + window.navigator.platform + '<br /><br />' ) ;

The lack of sanitizing those parameters will allow code to be executed on the browser.

To give a proof-of-concept, I used a Chrome plugin to change the User-Agent for a XSS vector.

Of course this vulnerability is not critical. It requires user interaction to exploit this. You always need to control the victims browser to execute an attack. Needless to say that if you have the victims browser the attacker didn't need to inject a XSS (IMO)...
It's a self-XSS so it needs more than a link to attack someone. It needs to be combined with other attack, like good social engineering skills. I reported this issue because even a self-XSS it's a vulnerability. It can be used to check vendors security response; what kind of vulnerabilities are most common on their products; etc.

By the way FCKeditor is still used in millions of websites and just to be sure update your version.

This issue was fixed on version 2.6.10.

We would like to announce a small update to FCKeditor. FCKeditor 2.6.10 is a minor security release that contains a fix for a recently reported issue where the About dialog window could hypothetically be used for an XSS attack provided that the user was forced by the attacker to change his browser properties.
Please note FCKeditor is a retired and no longer supported product. No further updates will be provided and it is highly recommended to upgrade to its successor, CKEditor, that is a far superior, feature-rich, and mature product.

Also present in 2.6.10 changelog:

Values displayed in the "About" dialog window were not properly escaped - reported by David Sopas.

My congrats to the CKSource team for the fast support showing that they're a company that cares about security.

Alexa reflected DOM XSS

Alexa Internet, Inc. is a California-based subsidiary company of Amazon.com which provides commercial web traffic data. Once it is installed, the Alexa Toolbar collects data on browsing behavior and transmits it to the Alexa website, where it is stored and analyzed, forming the basis for the company's web traffic reporting. As of 2013, Alexa provides traffic data, global rankings and other information on 30 million websites, and claims that 6 million people visit its website monthly.

When using Alexa.com website I found a reflected DOM XSS that could be used by malicious users to trick innocent visitors.
This vulnerability was present at tags.js from a remote location and the variable "tagSrc" lacked the proper sanitizing.

Vulnerable code:

t.tagSrc = '<div align="center">'+t.tagSrc+'</div>';
document.writeln(t.tagSrc);

When modifying the URL you can inject the code you want:

http://www.alexa.com/tfBuster.html#?flashVer=11&ver=1.25&th=11117008646&tagKey=4138765495&site=alexacom"></script><script>alert(document.cookie);</script><!--&adSpace=miscellanious&center=1&env=display

This issue already has been fixed but it took more than 3 months. It's strange that a company that's so big couldn't fix this type of vulnerability faster.
Malicious users could use this DOM XSS to spread phishing campaigns with a higher success rate.

Timeline:
13 December 2012: Reported this issue.
13 December 2012: Alexa replied and forwarded to engineering team.
26 December 2012: I requested a follow-up. They replied that still unpatched.
15 March 2013: Alexa replied that the DOM XSS has been fixed.

McAfee DOM XSS

After Panda Security, AVG, Kaspersky and continuing my project to find XSS flaws on antivirus vendors, I found out a DOM XSS vulnerability located at the McAfee website:

http://www.mcafee.com/us/mcafee-labs.aspx 

 A user could inject code for example:

<img src=f00bar onerror=prompt("xss");>

...on the input text in the form "Search the Threat Library".
When changing the select box it will get the XSS vector executed on the browser.

This "self-XSS" it's a minor security issue but still can be used to trick other users and a good way to check the security policies of McAfee.

 Keep in mind that this issue has been fixed.
My congratulations on the good and fast support from McAfee security team.