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:
Nowadays banking
authentication systems are getting more and more sophisticated in
order to counterattack the increasing number of hack attempts, but
unfortunately attackers follow the same trend by forging new and more
refined attack systems, we can define this as a classical never
ending battle between good and evil forces.
In this blog post we
will talk about the threats posed by the lack application of the
proper standard (ISO
15022, 8583) which regulates controls on
banking transaction details.
We can summarize
this lack of standard with the following statement: “Banking
transactions details are checked discretionally by the receiving
institute”.
An in depth view of
Discretionary Controls could be checked here [1].
The immediate effect
of this behavior is that an attacker could choose a bank with weak
controls to commit fraudulent transactions.
In this post we describe a scenario where an attacker takes advantage of a bank accepting incoming wire transfers omitting the surname of the recipients. Too many financial institutes allow incoming wire-transfers to "Giorgio" instead to "Giorgio Rossi" as a recipient.
The immediate effect
of this behavior is that an attacker could choose a bank with weak
controls to commit fraudulent transactions.
Another very
important consequence of a weak control on transaction details is
that it could disrupt the effectiveness of authentication mechanisms
especially transaction detail verification ones because is possible
to accomplish Social Engineering attacks, for example on the
recipient Name.
More details will be given in a specific
paragraph thatwillclarify how discretionary controls could be
abused. To clarify the whole attack process let's clarify what is an
OOB authentication system.
Overview of
OOB Transaction Detail Verification devices
The OOB
(Out-Of-Band) Transaction Detail Verification authentication system
sends to the banking customer a set of details about the transaction
that he should approve. Those details could be for example Iban,
Amount, Recipient, Country, if the requested transaction matches the
expectation of the customer (seems legitimate) he will validate the
transfer by generating an OTP code.
Follows an example
of a typical transaction detail verification hardware device:
If the transaction
is correct, the user will validate it by generating an OTP code to
finalize the operation.
Let’s see how an attacker could
abuse the weaknesses in deriving from discretionary controls in
realtime thanks to the technology offered by the most modern banking
malware.
The first step is to
clarify what is a realtime-deception attack and how is
accomplished.
ATS and Realtime
Deception Attacks
Most modern malware
banking implements a webinjection technology called ATS [2] which
stands for Automatic Transfer System. Thanks to the ATS system
attackers could automatically commit fraudulent transactions or
modify and substitute in realtime sensitive details like Iban and
Recipient of a legit transaction requested by the victim with
malicious detail one.
A realtime-deception
attack creates a condition, in which the victim is convinced to
authorize a legitimate transaction, when in fact will be validating
the fraudulent transaction desired by the attacker.
Realtime-Deception applied to
Discretionary Controls
The following
picture summarizes the attack process:
It’s
clear that a realtime-deception attack could be a serious threat if
applied to a bank that implements weak discretionary controls.
First step
involves in the infection of the victim with a banking malware which
supports MiTB (Man in The Middle) and makes use of ATS technology.
When the victim
fills details to commit a legitimate transaction, the webinjection
will substitute the proper Iban and other details, with a malicious
ones owned by the attacker. The attacker automatically chooses thanks to
ATS the proper money-mule to adopt, in the case of the example
Giorgio “Mule”. Attackers needs a mule with the same name (not surname) of the intended recipient chosen by the user.
The victim will receive in the OTP device details about the transaction, but will hardly notice the change of the Iban code, so finally the victim is convinced to validate your transaction. OTP will also provide the code necessary to validate the fraudulent transaction.
Realtime-Deception attacks are suitably constructed according to the device and transaction details exposed to the victim.
However it’s possible to provide a categorization of the possible combinations of detail alteration and relative weak discretionary control that could lead to a successful attack. This combination involves the security design of the OOB device screen:
Substitution of
Recipient, Iban and Amount – This substitution could be used for
example against phone call authentication which does not reveal
transaction details.
Substitution of
Recipient and Iban – This substitution could work for example
against devices that does not show the Name between transaction
details.
Substitution of
Recipient’s Name and deletion of the Surname – This substitution
could work for example against devices that only show only the
Recipient Name.
Let’s suppose for
example that we are in the third case, the hardware device shows only
Amount and Name and let’s also suppose that the banking transaction
detail controls does not care about the recipient Surname.
An attacker could
exploit this flaw to substitute for example The ATS automatically
chooses the best fitting money-mule, in this case the mule has the
same name of the legitimate recipient, the Surname difference is
rendered useless due to the nature of this specific control weakness:
example Giorgio (Real) -> Giorgio (Mule). Where “Giorgio
Mule” is a money-mule owned by the attacker. From a victim point
of view would be impossible to distinguish Giorgio “Real” from
“Mule”, this behavior will finally lead the customer to validate
the fraudulent transaction.
The scope of this
simple attack scenario is to show that it’s possible to meet a
specific banking institute which has poor controls, for example by
allowing transactions that contains a wrong beneficiary name. For an
attacker will be an easy task to change Iban code and leave the same
recipient name.
Each kind of
substitution/modification typology strictly depends on the weak
discretionary control applied by the specific bank.
It’s
interesting to put in evidence the fact that a correct mix of Social
Engineering, webinjection capabilities and knowledge of the details
validation flaws could pose a serious threat for the vast majority
(hardware and software) of OOB transaction detail verification
authentication systems.
From a defense point of view became
clear that adopting the proper transaction detail verification
standards [3] [4] represents a significant increase in terms of
security.
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 twodocument.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:
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.
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.
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:
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.
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.
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.
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.
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.
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.
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
