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. 

Get Internal Network Information with Java Applets

The first two issue on Java Applets are related to Information disclosure.

In particular a malicious user could get important information about private IP of each NIC a victim has on her platform.

17364779 NETWORKINTERFACE HASHCODE PROBLEM

Summary
It is possible to infer network IP on any local NIC via HASHCODE.

Analysis
It is known since Java v1.4 that Applets expose some network information of a user machine.
It is in fact possible to use

java.net.Socket( host,port)).getLocalAddress().getHostAddress();


which does work according to SOP (Example here).
Since Java 6 several other methods have been added which disclose Nic names, MAC and other information.
There is however some limitation on the information that can be gathered, and in particular it's not possible to get the IPs because they are tied to Same Origin Policy; for example is not possible to get the IP of VPN local interface.

We found that it is possible to bypass SOP by reversing the Hashcode of NetworkInterface object.
Hashcode on NetworkInterface is calculated as follows:

public int hashCode() {
int i = 0;
if (this.addrs != null) {
for (int j = 0; j <>

As can be seen NetworkInterface hashCode is the sum of each attached IP hashCode which is computed in the following way:


public int hashCode()
{
return this.address;
}
// Where address is :
if ((paramArrayOfByte != null) &&
(paramArrayOfByte.length == 4)) {
this.address = (paramArrayOfByte[3] & 0xFF);
this.address |= paramArrayOfByte[2] <<>

It is hence possible to reverse the hashCode to the address by simply using the following code:

d=Packages.java.net.NetworkInterface.getByName("eth0").hashCode();
IP=(d>>>24&0xff)+"."+(d>>>16 &0xff)+"."+(d>>>8 &0xff)+"."+(d &0xff)


But, what happens if there are more IPs bound to a single NIC?
It depends. Linux for example generates unused IPv6 addresses from MAC Address so it's possible to calculate it from the value returned by:

nic.getHardwareAddress();


And then use it to get the IPv4.

17322679 JAVA APPLET DNS IP DISCLOSURE

Summary
It is possible to get the DNS address of a victim.

Analysis

The SOP mechanism on new Java 6 applets is similar to Flash.
Before doing any action it check for the existance of crossdomain.xml files.
It was found that when we try to explicitly resolve a name using Packages.javax.naming package
setting the DNS to "dns://" Java VM will get the default DNS and ask it for crossdomain.xml file with a HTTP request on port 80.
If DNS drops packets on port 80 then Java will wait until socket will timeout, otherwise will return immediately with an error.
The error contains the DNS IP. The attacker can easily get the DNS IP from the error and use it for further attacks (DNS Cache Poisoning and so on).


function f(){
try{
env=new Packages.java.util.Hashtable()
env.put("java.naming.factory.initial", "com.sun.jndi.dns.DnsContextFactory");
env.put("java.naming.provider.url", "dns://");
ctx=new Packages.javax.naming.directory.InitialDirContext(env);
attrs = ctx.getAttributes("www.wisec.it",['*']);
}catch(e){alert(e)}
}
setTimeout(f,1);


Proof Of Concept
An example of what an attacker can gather from an applet can be found here
(should work on almost every browser maybe Safari has some problem):

There are a couple of non resolved issues:
If windows supports IPV6 and there are IPv4 + IPv6 IPs on a single interface it is not possible to infer them since Hashcode cannot be reversed.
You'll need to wait for socket timeout to have your DNS IP discovered so be patient.
The applet will get:


• Your DNS IP
• If you are using a proxy
• If you are using an authentication over the proxy (if TRACE Method enabled)
• Your proxy credentials
• Your NIC interfaces comprehensive of your IP, MAC Address and some other infos

To be noted that MAC address revelation is a feature.

Ps. As you'll probably notice after running the POC, I also found that Java 6 plugin exposes to Javascript (java & Packages objects) on every browser but we will talk about it on another post.