Tuesday, March 3, 2015

iOS Masque Attack Demystified

The Masque Attack, recently discovered by FireEye security researchers, sets a new level of warning for iOS users.
This is a dangerous attack that also threatens non jailbroken Apple iOS devices both on iOS 7.x and 8.x platforms. While some issues were being fixed in iOS 8.1.3, it has been found that the very same version is affected by a variation of the attack.

This attack leverage the easiness to obtain valid enterprise certificates and provisioning profiles from the open Internet in order to deploy a malicious app that substitutes a regularly installed one on the target device.

This malicious app can read all the data belonging to the previous app (the Keychain being an exception) and could also be used to perform a phishing attack by mimicking the UI of the original app in order to steal user credentials.




It is important to note that this attack poses to iOS users a greater risk than the Android counterpart. Because on Android there is an option that forbid users to install applications from sources that are not the official Play Store, while on iOS this choice is not available.

Minded Security has written a white paper to give the reader a deep insight of the attack by illustrating the key concepts behind it and proposing some remediations.


Wednesday, February 4, 2015

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!



Wednesday, September 17, 2014

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!

Monday, August 4, 2014

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:

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.

Wednesday, June 18, 2014

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:

Friday, October 18, 2013

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!

Friday, April 19, 2013

"jQuery Migrate" is a Sink, too?!

or How "jQuery Migrate" un-fixes a nasty DOMXSS without telling us..

Foreword

Today Mario Heiderich of Cure53 tweeted the following message:

"@0x6D6172696F Does anyone know why jquery.com has a special jQuery 1.9.1 version that is still vulnerable to $(location.hash)?"

What happened after that message might be considered to be the discovery of a rather interesting bug - which Mario and me will try to wrap up in this joint blog-post.

In short words:
an official jQuery plugin un-fixes a long-gone DOMXSS bug and brings it back - even on the jQuery homepage itself!

The Long Story

First, let's give the word to Mario and hear what he has to say:

"Some days ago, while being engaged in a workshop, I discovered a funny thing.
I visited the jQuery.com homepage and tried playing around with the DOMXSS jQuery came shipped with some months ago.
The one, that could be exploited by allowing arbitrary user input to the $() function - remember?
My goal was to demonstrate the attendees, how the XSS worked, why it worked and how it was fixed.

So, I wanted to test if there's still ways to activate it and get past the regular expression they installed to mitigate the bug. First thing was to try the obvious, set location.hash to <svg onload="alert(1)"> and execute $(location.hash) via the Firebug console expecting it NOT to work.
But.
It worked.
Admittedly confused, I checked the jQuery version they deployed and it was the latest - jQuery 1.9.1.
That couldn't be - I must have made something wrong!

I decided to build a small dynamic checker to see which exact version of jQuery is vulnerable to this bug, and which is not. The tool I created - really ugly code, be warned - is here.
It simply fetches all the jQuery versions from 1.3.0 up to 2.0.0 from the Google API, tests the vector via location.hash and then goes red or stays green depending on whether the code executed or not. As can clearly be seen:
jQuery 1.6.2 was the last vulnerable version. And 1.9.1 is not!



So, what did the jQuery people do? Why is their latest version vulnerable but the actual version isn't? How did they get their version to be buggy again? In my desperate helplessness I tweeted and Stefano replied. He found the cause for this quirky behaviour of eternal madness."

Now, Stefano (me:) had a deep look into the code and started the engine of... well, you know it, DOMinatorPro to see what kind of roguery is going on here.

"Since the day I started to develop DOMinatorPro and write DOMXSSWiki I thoroughly studied jQuery internals in its very own, so when Mario tweeted about that, I immediately thought about some weird misunderstood mixed jQuery version behaviour, as sometimes have happened to me.
Yet, here's the screen-shot:




..and the version info indeed clearly says: 1.9.1!!!
You can easily check that via $.expando by the way - no need to dig in the site sources or script code itself.
But, how's that possible?
Can DOMinatorPro help  me?
Let's see. By simply doing the same with DOMinatorPro, it will show the following alert:


The StackTrace says:

buildFragment(elems="#<s>sss", context="[object HTMLDocument]",scripts="undefined", selection="undefined")jquery-1.9.1.js (line 6481)

parseHTML
(data="#<s>sss", context="[object HTMLDocument]",keepScripts="true")jquery-1.9.1.js (line 521)

init(selector="#<s>sss", context="undefined", rootjQuery="[object Object]")jquery....1.0.js (line 213)

jQuery(selector="#<s>sss", context="undefined")jquery-1.9.1.js (line 48)


ParseHTML? No way! What are those files? Wait a moment, that jquery....1.0.js (line 213) is actually:
http://code.jquery.com/jquery-migrate-1.1.0.js !!
Let's see what's there:

var matched, browser,
 oldInit = jQuery.fn.init,
 oldParseJSON = jQuery.parseJSON,
 // Note this does NOT include the #9521 XSS fix from 1.7!
 rquickExpr = /^(?:[^<]*(<[\w\W]+>)[^>]*|#([\w\-]*))$/;

// $(html) "looks like html" rule change
jQuery.fn.init = function( selector, context, rootjQuery ) {
 var match;

 if ( selector && typeof selector === "string" && !jQuery.isPlainObject( context ) &&
   (match = rquickExpr.exec( selector )) && match[1] ) {
  // This is an HTML string according to the "old" rules; is it still?
  if ( selector.charAt( 0 ) !== "<" ) {
   migrateWarn("$(html) HTML strings must start with '<' character");
  }
  // Now process using loose rules; let pre-1.8 play too
  if ( context && context.context ) {
   // jQuery object as context; parseHTML expects a DOM object
   context = context.context;
  }
  if ( jQuery.parseHTML ) {
         return oldInit.call( this, jQuery.parseHTML( jQuery.trim(selector), context, true ),
 /* Vuln Call Here !! -^*/  context, rootjQuery );
  }
 }
 return oldInit.apply( this, arguments );
};
jQuery.fn.init.prototype = jQuery.fn; 

So, by looking at the oldInit.call what happens here is that another jQuery sink is called (!) and that's jQuery.parseHTML."

Why is that?

It's probably a way to give back compatibility by recreating the old behavior using parseHTML, but jQuery guys forgot that there are two fixes that try to patch a wrong design choice, and the first one comes from Version > 1.6.2. These include the dreaded DOMXSS from Mala.
 
Can it be worked around? 

Mario wrote this quick and - as he calls it himself - incredibly dirty fix, which will address the unexpected abuse of this classical pattern:

function jQMfix(){      if(/</.test(location.hash)) {           location.hash=location.hash.replace(/</g,'')      } }
onhashchange=jQMfix; jQMfix();

The  fix is - and that is Mario speaking again - extremely dirty and everything but production ready.
But it shows a way to make sure the location.hash cannot be abused to cause DOMXSS on your precious website.
If your JavaScript is.. "special" it can of course still happen.

But you get the gist - make sure that if you use the jQuery Migration plugin that your web-app stays safe from DOMXSS.

Here's yet another way to approach it, from Stefano, but keep in mind that it's completely untested and more an example on how to approach it:

jQuery = $ =( function (r) {return function jQuery(a,b){
  if(a.charAt(0)==='#') 
    a=a.replace(/</g,'')
  r.apply(null,[a,b])
 }
} )(jQuery)
..and, of course, feel free to improve it and paste it in a comment.

We do see a lot of plugin-caused DOMXSS in the wild - but a plugin that purposely un-fixes an existing and well-known XSS bug? That's something :-)

Also, greetings to the fellow attendees of the jQuery UK conference that is happening right now.

Have a beautiful (0-)day! :)