Analysis of Dom Xss vulnerability in a Facebook Like Button implementation

Note: The following vulnerability is now patched. Thanks to Matt, Charlie and to the Addthis.com team that released a patch yesterday after receiving our advisory.

Description

I like very much facebook, and I like clicking on facebook like buttons like the one below. Addthis.com has its own implementation of Facebook Like Button and is very used among internet websites. They estimate that unique websites around the world are several millions.

A Facebook Like Button in a Share Widget Bar:

You can find some background information already in one of our previous posts:

•    http://blog.mindedsecurity.com/2012/09/temporary-patch-for-dom-xss-0day-in.html

Proof of Concept

http://www.website-with-addthis-widget.con/#"></fb:like><img/src="aaa"/onerror="alert('DomXss Found!')

Note: This reflected dombased cross site scripting (before the patch) was present in a tremendous number of websites

Vulnerable Code

if (F.href === _1) {
d = _8.util.clone(E.share.url_transforms || {});
d.defrag = 1;
F.href = _8.track.mgu(E.share.url, d);//-- Location
}
for (A in F) {
B += " " + A + "=\"" + F[A] + "\"";//-- Attribute Set
}
if (!E.share.xid) {
E.share.xid = _8.util.cuid();
}
f[F.href] = {};
for (A in E.share) {
f[F.href][A] = E.share[A];  
}
G.innerHTML = "<fb:like br="br" 
ref="\">_8.share.gcp(E.share, E.conf,".like").replace(",", "_") 
+ "\" " + B + "</fb:like>"; //-- DomXss
p(G);

Analysis and discovery with DOMinatorPro

Even if to the reader this issue seems like a common cross site scripting, finding such kind of security issues in Javascript code (aka DomXss) is an extremely complex task.

This is why our Advanced Research team developed DOMinatorPro. DOMinatorPro can be downloaded from the following dedicated website: http://dominator.mindedsecurity.com.

DOMinatorPro is a Free Opensource Project with Commercial Extensions. Commercial extensions have a 15 days Free Trial Period.

The vulnerability was in ONE of the scripts loaded by the “addthis_widget.js”  script available online at “http://s7.addthis.com/js/300/addthis_widget.js”. As you can see multiple scripts are loaded and the scripts are compressed and obfuscated , giving to human security reviewers a painful and a very long and time comsuming task to accomplish.

Note: The following part is taken from the DOMinatorPro user manual and shows a similar vulnerability in a demo context. In DOMinatorPro user manual you can find sample cases to help you understand the cause of the vulnerability for producing solid Javascript patches.

By the way, when browsing to a website with a vulnerable “Facebook - Like Button” with DOMinatorPro tool you will see in a couple of seconds the following alert:

From the previous screenshot the very interesting information is that you got an HTML Injection (e.g. Cross Site Scripting) from the location.href (e.g. the URL).
Important Note: Sink describes where the vulnerability is and the Source is where the controllable input comes from.
 
Summary of the issue: HTML injection vulnerability coming from a user supplied input location.href (URL). 

 Source History

Next step is to check where this issue has been found. This is easy, looking at the source history:

Exact location of the issue is: 

• http://www.vulnerablewebsite.con/webpage.aspx?menuid=3#injectedstring<>”’

Source history is a simplified call stack that shows the content of controllable strings.
Location.href can be controlled and the value is showed up in light green, after this string is concatenated with another string by left and by right.
As it is possible to see from the above picture, it’s also possible to check if there are validator functions in place by injecting HTML patterns after the # (hash); in this case I injected the pattern #injectedstring<>”’ after the vulnerable URL. Using the “Hash” sign is important because anything coming after it will not be sent to the server.
It’s possible to see from the last line that #injectedstring<>"' is not encoded (typical encoded string is in the form of: #injectedstring%3c%22%27).
By supplying now the correct exploit it is possible to turn the vulnerability into a reflected DOM cross site scripting attack:
 
Standard HTML Injection Payload: 

• <img/src="aaa"/onerror="alert('DomXss Found!')">

Important Note: Thanks to DOMinatorPro Browser emulation feature we can mimic different browser insecure behaviors. This permits to show developers the vulnerability inside DOMinatorPro/Firefox, even if the previous exploit works only under Internet Explorer.

Call Stack 

Now for a developer it is time to open the “Call Stack”:

The Call Stack interactively shows where the vulnerability is with the correct line. It is possible to see “document.location.href” is not escaped properly.
It’s very important to output encode the value before it is displayed.

Fixing

Correct fixing at line 116:
•    Use the “encodeURIComponent()” function.