tag:blogger.com,1999:blog-1978970833907863972024-03-28T14:36:47.886+05:30The Beautiful Broken Web\0/ bish \0/http://www.blogger.com/profile/17332421144422015996noreply@blogger.comBlogger17125tag:blogger.com,1999:blog-197897083390786397.post-34608143341635473692012-02-13T16:56:00.001+05:302012-02-13T16:56:47.039+05:30NodeJS: Switch is EVIL<div dir="ltr" style="text-align: left;" trbidi="on">
<i>switch</i> statement in JavaScript is known to have bad effects as in other programming languages. In this post we discuss it's potential impact in server side JavaScript context like NodeJS. For more history on <i>switch </i>please refer <a href="http://yuiblog.com/blog/2007/04/25/id-rather-switch-than-fight/" target="_blank">Douglas Crockford's YUI blog post</a>.<br />
<br />
Let's look at a sample code snippet as in the screenshot below. This is an over-simplistic example. It is a funny little take on an app that reveals it's users the discount code based on their tiers. The logic that will determine the tier of the user and it's category is omitted for benefit of stressing on the issue at hand.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://3.bp.blogspot.com/-rUSsJGIPH40/Tzjt3GLH1YI/AAAAAAAAAis/v09kWcCQNIg/s1600/switch_1.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://3.bp.blogspot.com/-rUSsJGIPH40/Tzjt3GLH1YI/AAAAAAAAAis/v09kWcCQNIg/s1600/switch_1.png" /></a></div>
<br />
What should have happened was, the basic tier user <i>Valued Customer </i>should have been shown only 10% discount code. Now since our programmer forgot to apply the brakes (i.e. <i>break</i> highlighted in red in the previous <i>case</i> - in hurry or just human error or insufficient knowledge of <i>switch</i> may be), the second case code under <i>case (dis < 5000)</i> triggered leading to giving higher discount to a basic tier customer and showing a not so good message, as in the screenshot below.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://1.bp.blogspot.com/-UDqSMMCg_RI/TzjzWbmDSyI/AAAAAAAAAi0/N2x0Il1L3cM/s1600/switch_2.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://1.bp.blogspot.com/-UDqSMMCg_RI/TzjzWbmDSyI/AAAAAAAAAi0/N2x0Il1L3cM/s1600/switch_2.png" /></a></div>
<br />
Still in this fun app nothing really nasty happened. And the idea was exactly that to take a simple code and demo what <i>switch </i>could lead to.<br />
<br />
In real world a similar mistake could lead to serious vulnerabilities
- those are hard to detect. More I think of JavaScript, more I
believe, coding best practices usually translate to security best practices. To be safe, anti-patterns like <a href="http://bishankochher.blogspot.com/2012/02/nodejs-global-namespace-pollution.html" target="_blank"><i>implied globals</i></a>, <a href="http://bishankochher.blogspot.com/2012/02/nodejs-with-is-evil.html" target="_blank"><i>with</i></a>, <a href="http://bishankochher.blogspot.com/2011/12/nodejs-security-good-bad-and-ugly.html" target="_blank"><i>eval</i></a>, should be avoided. <br />
<br />
<br /></div>\0/ bish \0/http://www.blogger.com/profile/17332421144422015996noreply@blogger.com50tag:blogger.com,1999:blog-197897083390786397.post-20815541126319036592012-02-13T14:50:00.001+05:302012-02-13T14:51:44.320+05:30NodeJS: 'with' is evil<div dir="ltr" style="text-align: left;" trbidi="on">
It is a known fact that <i>with</i> statement in JavaScript is evil. For a good read on why read <a href="http://yuiblog.com/blog/2006/04/11/with-statement-considered-harmful/" target="_blank">Douglas Crockford's post on YUI blog.</a><br />
<br />
Let's look at how it implies on server side JavaScript. Below is a fun little app coded by a beginner that tries to be funny although in real apps this could lead to unbelievably serious vulnerabilities.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://2.bp.blogspot.com/-XvGxmnbuSwQ/TzjPEquOkTI/AAAAAAAAAic/1ogixmIku68/s1600/with_1.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="464" src="http://2.bp.blogspot.com/-XvGxmnbuSwQ/TzjPEquOkTI/AAAAAAAAAic/1ogixmIku68/s640/with_1.png" width="640" /></a></div>
<br />
So what went wrong here? The developer loves using <i>with</i> for it's shot handedness and thought she called the property names of the <i>welcome </i>object correctly. Also it didn't show any errors. But what her first user on the web saw was this (not that <i>this</i>)<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://2.bp.blogspot.com/-srtRnlJCuYM/TzjT0dnhAZI/AAAAAAAAAik/wlz2Zh-Z4X0/s1600/with_2.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="122" src="http://2.bp.blogspot.com/-srtRnlJCuYM/TzjT0dnhAZI/AAAAAAAAAik/wlz2Zh-Z4X0/s640/with_2.png" width="640" /></a></div>
<br />
<br />
So, she did a typo and ended up unintentionally modifying global variables she wasn't even aware of. Let's just imagine they existed in some other code base where she couldn't even see. This just reminds me how difficult will it be for a security guy like me to code review a code with <i>with.</i><br />
<br />
Now how <i>with</i> works is, it tries to find the property assignments in the context of the called object, if found, great, else it tracks back on the higher scope till reaching the global scope and assigning (actually clobbering) value of some other global variable if there is a match. Think common names like <i>i</i>, <i>x</i>, <i>a</i>, <i>name</i>... we all grew up coding with (not that with).<br />
<br />
In short, do not use <i>with</i>, unless you are very sure of what you are doing. On a positive note, use of <i>with</i> is forbidden in ES5 <i>strict</i> mode. <br />
<br />
<br />
<br /></div>\0/ bish \0/http://www.blogger.com/profile/17332421144422015996noreply@blogger.com53tag:blogger.com,1999:blog-197897083390786397.post-23488045181163154342012-02-13T12:28:00.002+05:302012-02-13T14:53:17.338+05:30NodeJS: Global Namespace Pollution<div dir="ltr" style="text-align: left;" trbidi="on">
<br />
From a security standpoint, a big change for most server-side developers moving on to NodeJS would be the notion of JavaScript's global namespace. If misunderstood or with limited knowledge of this inherent property, writing secure NodeJS web apps will be a challenge.<br />
<br />
So what is it? A prime property of JavaScript is, it is a 'global' language.<br />
<ul style="text-align: left;">
<li><i>variables</i> by default have an implied global scope</li>
<li><i>functions </i>by default have an implied global scope</li>
<li>all <i>objects</i> inherit from the native / built-in global objects</li>
</ul>
Let's understand more with a code snippet. In a traditional PHP script
(or any other non-server side JS paradigm), each request has it's own
scope. So a code similar to below will always print <i>1</i>, unlike in the case of NodeJS. Any request will share the same <i>global</i> scope.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://1.bp.blogspot.com/-CkKaYJsV4M8/TzicmuydUgI/AAAAAAAAAh8/058Dx29r9OI/s1600/globalNamespace.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="191" src="http://1.bp.blogspot.com/-CkKaYJsV4M8/TzicmuydUgI/AAAAAAAAAh8/058Dx29r9OI/s400/globalNamespace.png" width="400" /></a></div>
<br />
In relevance to this code, each request will increase the global variable <i>gbl</i> by 1, as seen in the screenshot below for two different requests. In a PHP script such a model would only show<i> 1</i> for every request. <br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://3.bp.blogspot.com/-mmPV34IXyFo/TzihL2bdlxI/AAAAAAAAAiE/5AVzc2hP6z8/s1600/globalNamespace_1.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="163" src="http://3.bp.blogspot.com/-mmPV34IXyFo/TzihL2bdlxI/AAAAAAAAAiE/5AVzc2hP6z8/s320/globalNamespace_1.png" width="320" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://1.bp.blogspot.com/-QnLvqcS7LTI/TzihMmLc0YI/AAAAAAAAAiM/quPee1QGcsc/s1600/globalNamespace_2.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="139" src="http://1.bp.blogspot.com/-QnLvqcS7LTI/TzihMmLc0YI/AAAAAAAAAiM/quPee1QGcsc/s320/globalNamespace_2.png" width="320" /></a></div>
<br />
<br />
So, what could go wrong from security perspective? Short answer - it depends, on the context and sensitivity of a global variable or function. An attacker could exploit this behavior to her benefit to achieve desired effects. What could those be,<br />
<ul style="text-align: left;">
<li>as a web user, could bypass logic flows</li>
<li>a malicious library could over-ride native, built-in or known objects, variables, functions to adversely impact sensitive code base/libraries</li>
<li>in a shared coding environment, an inexperienced developer could unintentionally over-ride native, built-in or known
objects, variables, functions - adversely impacting sensitive code
base/libraries </li>
</ul>
A lot more serious stuff could happen only time will tell.<br />
<br />
So what's the defense? Unless really needed, always define your functions, variables, as <i>local</i>, as shown in the screenshot below.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://4.bp.blogspot.com/-Qz8gDJZAOPg/Tzilwm42X2I/AAAAAAAAAiU/wHCTqjRzMNQ/s1600/globalNamespace_local.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="171" src="http://4.bp.blogspot.com/-Qz8gDJZAOPg/Tzilwm42X2I/AAAAAAAAAiU/wHCTqjRzMNQ/s400/globalNamespace_local.png" width="400" /></a></div>
<br />
<br />
Now you get the desired effect as in PHP. Each request now shows <i>gbl</i> as <i>1</i>. For potential rogue/malicious libraries - audit them! <a href="http://www.jslint.com/" target="_blank">JSLint</a> (though a bit noisy) is a good bet.<br />
<br />
I am a JavaScript beginner, hence for a healthy advise for typical programming requirements, I recommend reading <a href="http://www.crockford.com/" target="_blank">Douglas Crockford's</a> post on why <a href="http://www.yuiblog.com/blog/2006/06/01/global-domination/" target="_blank">Global is Evil and the best practices to avoid it</a>.</div>\0/ bish \0/http://www.blogger.com/profile/17332421144422015996noreply@blogger.com12tag:blogger.com,1999:blog-197897083390786397.post-6370185376355132792011-12-01T13:15:00.001+05:302012-02-14T10:45:29.055+05:30Node.JS Security - the good, bad and ugly<div dir="ltr" style="text-align: left;" trbidi="on">
At the moment, dev world is full of rave about Node and server side JavaScript (databases like MongoDB and the likes). There hasn't been a better time for front-end and JS developers. On the first look - it appears great, promising and exciting.<br />
<br />
On the down side, as with most upcoming technologies, there isn't enough security analysis, consideration and advisory to reference and understand gotchas with server side JS. Nothing wrong with that - it's functions, coolness and innovation that brings business and not security (history/economics is a testimony).<br />
<br />
In this post, I will share my security view point as I see it. This could be an ever growing list and the kind of things you can achieve with server side JavaScript - there is no early end to this.<br />
<br />
Let's start with <b>the good things</b>. Node inherently introduces a great security benefit over<br />
traditional server side programming paradigms and that is "secure by default" (reminds me of my NetBSD days). As highlighted in white below, your create your web server - a bare bone types and not a full blown with bells and whistles like Apache.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://3.bp.blogspot.com/-dDfsLEsNEBM/Ttda3Iy1lUI/AAAAAAAAAhE/-1fW0d-3oqU/s1600/serverJS.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="593" src="http://3.bp.blogspot.com/-dDfsLEsNEBM/Ttda3Iy1lUI/AAAAAAAAAhE/-1fW0d-3oqU/s640/serverJS.png" width="640" /></a></div>
<br />
<br />
And then chose and pick what you want. Like define what your doc root will have - unlike anything and everything in a traditional web doc root. Like highlighted in yellow below - that is what your web server will respond to for requests. Rest needs to be caught by a 404.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://3.bp.blogspot.com/-P9nTimIPUGc/Ttda2u9nW5I/AAAAAAAAAhA/DWXTvdaV1Rw/s1600/handlers.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="241" src="http://3.bp.blogspot.com/-P9nTimIPUGc/Ttda2u9nW5I/AAAAAAAAAhA/DWXTvdaV1Rw/s640/handlers.png" width="640" /></a></div>
<br />
<br />
Summarizing - your web server isn't configured and capable more than what you want it to be unlike Apache, Tomcat or IIS. I recall countless instances of Tomcat compromises due to default admin and manager apps that come installed and running with default passwords. And IIS getting exploited with WebDAV buffer overflow when in reality the web app never really needed it in first place. Typically web servers sent a false sense of security where developers mostly considered them to be secure. And we all know, more features, bigger the attack surface. Bigger the attack surface more chances of things going wrong. And something that can go wrong will go wrong!<br />
<br />
On the flip side - <b>the bad parts.</b> Node carries over the known dangerous JavaScript APIs like the <i>eval</i> that can be trivially exploited to do server side injection (that were earlier only client side exploits like XSS).<br />
<br />
Let's look at a PoC exploit where app evaluates the input and returns an output like below<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://2.bp.blogspot.com/-d-Vse31FVs4/TthAWTq2u4I/AAAAAAAAAho/q74MjMo6Mow/s1600/usecase_1.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="478" src="http://2.bp.blogspot.com/-d-Vse31FVs4/TthAWTq2u4I/AAAAAAAAAho/q74MjMo6Mow/s640/usecase_1.png" width="640" /></a></div>
<br />
Abusing <i>eval</i> on client side would result an XSS but on server-side it induces a server side injection alike SQL Injection as seen below where we inject an HTTP response.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://4.bp.blogspot.com/-Gv5kpHQdEaY/TtdTTJCI75I/AAAAAAAAAgw/XjWBfYOiu1g/s1600/eval_SSI_request.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="441" src="http://4.bp.blogspot.com/-Gv5kpHQdEaY/TtdTTJCI75I/AAAAAAAAAgw/XjWBfYOiu1g/s640/eval_SSI_request.png" width="640" /></a></div>
<br />
The screenshot below highlights execution of server side injection. <br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://1.bp.blogspot.com/-KQN6nOr1QO0/TtdWTmR0niI/AAAAAAAAAg4/Z0A_D3C8r0w/s1600/eval_SSI.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="443" src="http://1.bp.blogspot.com/-KQN6nOr1QO0/TtdWTmR0niI/AAAAAAAAAg4/Z0A_D3C8r0w/s640/eval_SSI.png" width="640" /></a></div>
<br />
To best of my knowledge, this issue was first brought to notice in context of Node by <a href="https://media.blackhat.com/bh-us-11/Sullivan/BH_US_11_Sullivan_Server_Side_WP.pdf" target="_blank">Bryan Sullivan at BlackHat</a>. Not a brand new exploit. We know <i>eval</i> is evil. What is worth note here is most developers wouldn't imagine this happening at the first go. From that perspective this exploit vector server side is novel. <br />
<br />
What do I see ugly? <b>The ugly parts</b> are the ones that introduce new attack vectors. There should have been default protection built-in ideally. The event driven single threaded programming model is not what web developers are used to. Node is single threaded and a simple error can create a denial of service condition as highlighted in the screenshot below.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://4.bp.blogspot.com/-IwfS3sfvKIk/TtdnjBlW9XI/AAAAAAAAAhY/_vbQIp78uQ0/s1600/errorcrash_semicolon.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="414" src="http://4.bp.blogspot.com/-IwfS3sfvKIk/TtdnjBlW9XI/AAAAAAAAAhY/_vbQIp78uQ0/s640/errorcrash_semicolon.png" width="640" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://1.bp.blogspot.com/-KQN6nOr1QO0/TtdWTmR0niI/AAAAAAAAAg4/Z0A_D3C8r0w/s1600/eval_SSI.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><br /></a></div>
As highlighted, hitting submit crashes the node server.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://2.bp.blogspot.com/-zgUttHL9GBY/Ttdn1oDnJYI/AAAAAAAAAhg/9_M76XvXdXg/s1600/errorcrash_semicolon_result.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="408" src="http://2.bp.blogspot.com/-zgUttHL9GBY/Ttdn1oDnJYI/AAAAAAAAAhg/9_M76XvXdXg/s640/errorcrash_semicolon_result.png" width="640" /></a></div>
<br />
Similar DoS condition would result when messing with global variables - intentionally or unintentionally. Above scenarios are quite likely considering JS developers are usually quite used to errors. I see thousands of live sites day in and out that have a number of errors showing up in Firebug console and running absolutely ok which will not be the case as you go server side.<br />
<br />
Another <b>ugly part</b> is that web developers are not quite used to service permissioning. Web developers had it outsourced to Apache/IIS, would now end up running their node services as <i>root</i>, that earlier ran as <i>nobody</i>.<br />
<br />
A 1000 feet high apple to apple comparison between let's say PHP and Node tells me - it took a step back in security. At least, you would come to expect a sanitization/validation library for a new programming language, if not a fancy new auto-sanitization module like PHP Filter (aah yes - Filter isn't a complete auto sanitization in PHP but you get what I mean).<br />
<br />
An honest look and I feel node isn't meant to be used as is. With a strong framework, is how it should be used. There are many in the fray right now - Express probably is the most widely used. I haven't tried it yet but from what I see, security in node is a work in progress.<br />
<br />
Being a Yahoo, how can I end without not mentioning <a href="http://developer.yahoo.com/blogs/ydn/posts/2011/11/yahoo-announces-cocktails-%E2%80%93-shaken-not-stirred/" target="_blank">Yahoo Cocktails</a>. Haven't played around with it yet, but this is something I have super high hopes with. The engineers I met there are fabulous. Come Q1 2012 it would be there for all of us to play around. Yahoo is a great company, the best I have worked for - no doubt I would love to see it scoring high.<br />
<br />
Learning more and more of Node, I keep reminding myself "Node is powerful, and with power comes responsibility".<br />
<br /></div>\0/ bish \0/http://www.blogger.com/profile/17332421144422015996noreply@blogger.com279tag:blogger.com,1999:blog-197897083390786397.post-63938355080621959422011-09-13T19:59:00.000+05:302011-09-14T16:48:24.796+05:30Exploiting iGoogle Gadgets<div dir="ltr" style="text-align: left;" trbidi="on">
Exploitation of iGoogle gadgets which uses iframes under the hood is well known. Here is an excellent paper on <a href="http://seclab.stanford.edu/websec/frames/post-message.pdf">Frame Navigation</a> that explores this attack vector on iGoogle gadgets.<br />
<div>
<br /></div>
<div>
Below is a quick demo on redirection attack on iGoogle gadgets. All the attacks that I mentioned on FB iframe tabs also apply here. It is just that iGoogle is less viral making FB a better ROI target.</div>
<div align="center">
<iframe allowfullscreen="" frameborder="0" height="349" src="http://www.youtube.com/embed/GSRtA0pVBIc?hl=en&fs=1" width="525"></iframe></div>
</div>
\0/ bish \0/http://www.blogger.com/profile/17332421144422015996noreply@blogger.com9tag:blogger.com,1999:blog-197897083390786397.post-59744388683546540802011-09-13T14:48:00.001+05:302011-09-14T18:38:07.278+05:30Exploiting FB Iframe tabs<div dir="ltr" style="text-align: left;" trbidi="on">
<br />
FBML was deprecated and <a href="http://developers.facebook.com/blog/post/462">Facebook iframe tabs</a> were introduced in Feb'11. As expected it caught significant traction from the developer and security researchers alike. While developers applauded introduction of existing mechanisms like iframes that enable writing 3rd party apps without any learning curve that traditionally existed with Facebook, the security community <a href="http://countermeasures.trendmicro.eu/facebook-open-javascript-hole/">alarmed concerns</a> over the viral nature of Facebook that combined with iframes further exacerbated their evil nature. Below is a screenshot of Levi's iframe tab on FB.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://1.bp.blogspot.com/-ZuQuzVfUe0A/Tm89O43WJNI/AAAAAAAAAgU/zCLD7-2Cv4I/s1600/FB_levis.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="488" src="http://1.bp.blogspot.com/-ZuQuzVfUe0A/Tm89O43WJNI/AAAAAAAAAgU/zCLD7-2Cv4I/s640/FB_levis.png" width="640" /></a></div>
<br />
<div>
<br /></div>
<div>
I love iframes. Haven't they existed there would have been shouts of killing HTTP and inventing a new protocol to support client side mashups. So in a sense, iframe is a blessing that enabled an unexpected requirement by chance although with some security implications. Another assurance on my belief that these great technologies - HTTP, iframe and JS are there to stay for a very very long time, if someone still doubted. I also believe the new specifications HTML5 Sandbox and ES5 are moving in the right direction to enable secure mashups - 1 day when those (IE6) are buried!</div>
<div>
<br /></div>
<div>
Back to the topic. Nothing new but worth visiting what all an attacker could technically exploit on FB iframe tabs. </div>
<div>
<br /></div>
<div>
<div>
1. Malicious Redirection via <span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;">top.location = http://s0m3phishing.com, </span><span class="Apple-style-span" style="font-family: inherit;">as seen in the video below. For demo I perform a redirect to http:///yahoo.com</span></div>
<div>
<br /></div>
<div>
<div class="separator" style="clear: both; text-align: center;">
<iframe allowfullscreen="" frameborder="0" height="349" src="http://www.youtube.com/embed/MzVGYO9siM8?hl=en&fs=1" width="560"></iframe></div>
<br /></div>
<div>
</div>
<div>
2. Fake Login / Malicious UI via <span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"><form..></form..></span> and<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"> window.open()</span><br />
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"><br /></span><br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://4.bp.blogspot.com/-EZ9n0PzjMnc/Tm86x-kbZUI/AAAAAAAAAgM/EjH6MUotfj0/s1600/fakelogin.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="538" src="http://4.bp.blogspot.com/-EZ9n0PzjMnc/Tm86x-kbZUI/AAAAAAAAAgM/EjH6MUotfj0/s640/fakelogin.png" width="640" /></a></div>
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"><br /></span><br />
<div style="text-align: left;">
<div class="separator" style="clear: both; text-align: center;">
<iframe allowfullscreen="" frameborder="0" height="349" src="http://www.youtube.com/embed/AV97kYyeSZc" width="560"></iframe></div>
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"><br /></span></div>
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"><br /></span></div>
<div>
3. Drive-by Downloads/ Install Malware via <span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;">Content-Disposition: attachment</span><br />
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"><br /></span><br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://4.bp.blogspot.com/-bVpqGPHvgzM/Tm88Am6VZFI/AAAAAAAAAgQ/SgZrW9YONF4/s1600/0711-Malware-D2_x582.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="298" src="http://4.bp.blogspot.com/-bVpqGPHvgzM/Tm88Am6VZFI/AAAAAAAAAgQ/SgZrW9YONF4/s400/0711-Malware-D2_x582.jpg" width="400" /></a></div>
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"><br /></span></div>
<div>
<br />
4. Denial of Service (DoS) and Noise by creating infinite <span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;">alert()</span>and <span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;">while</span> loops. This particularly is an issue not concerning many, including the security community, but for business it is, as an attacker can impact user engagement and experience which are of prime importance in this business.<br />
<br /></div>
<div>
<div class="separator" style="clear: both; text-align: center;">
<iframe allowfullscreen="" frameborder="0" height="349" src="http://www.youtube.com/embed/cda5OuB1QOs?hl=en&fs=1" width="560"></iframe> </div>
<br />
5. Browser History Sniffing/Mining via <span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;">getComputedStyle()</span><span class="Apple-style-span" style="font-family: inherit;">as highlighted in the screenshot below</span><br />
<span class="Apple-style-span" style="font-family: inherit;"><br /></span><br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://2.bp.blogspot.com/--XqXAUmlOhY/Tm85hUTL8rI/AAAAAAAAAgE/zssr2X8a8DA/s1600/iframe_FB_sniffHistory_FF3.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="484" src="http://2.bp.blogspot.com/--XqXAUmlOhY/Tm85hUTL8rI/AAAAAAAAAgE/zssr2X8a8DA/s640/iframe_FB_sniffHistory_FF3.png" width="640" /></a></div>
<span class="Apple-style-span" style="font-family: inherit;"><br /></span></div>
<div>
<br />
6. Referrer Leak like <span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;">Referrer: http://<ip>/r.html?a=secret&b=private</ip></span><br />
<span class="Apple-style-span" style="font-family: 'Courier New', Courier, monospace;"><ip><br /></ip></span><br />
<div class="separator" style="clear: both; text-align: center;">
<a href="http://2.bp.blogspot.com/-FfM5sAgaRGY/Tm86PQ5iRdI/AAAAAAAAAgI/7KNcuB3kTJE/s1600/referrerstealing.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="368" src="http://2.bp.blogspot.com/-FfM5sAgaRGY/Tm86PQ5iRdI/AAAAAAAAAgI/7KNcuB3kTJE/s640/referrerstealing.png" width="640" /></a></div>
</div>
<div>
<br />
7. LAN Scanning via JavaScript. A good write up on this is available <a href="http://www.thespanner.co.uk/2007/07/28/online-javascript-lan-scanner/">here</a></div>
</div>
<div>
<br /></div>
<div>
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<br /></div>
<br />
<div>
</div>
</div>
\0/ bish \0/http://www.blogger.com/profile/17332421144422015996noreply@blogger.com7tag:blogger.com,1999:blog-197897083390786397.post-81159583683587175042009-09-02T11:42:00.004+05:302009-09-02T11:49:58.858+05:30Another SQL Injection VariantHere is another variation of conducting successful SQL Injection attack, Truncation-Based SQL Injection, by Varun Sharma of Microsoft ACE team.<br /><br />http://msdn.microsoft.com/hi-in/security/ee216344%28en-us%29.aspx<br /><br />It is not a new vulnerability or something that defies existing security best practices against SQL Injection - use SQL Parameters, input validation, least privilege principle, but just highlights another way to break weak code.\0/ bish \0/http://www.blogger.com/profile/17332421144422015996noreply@blogger.com176tag:blogger.com,1999:blog-197897083390786397.post-19524823396636021302009-08-20T17:08:00.004+05:302009-08-20T18:02:27.766+05:30Linux NULL Pointer Dereference CVE-2009-2692<a href="http://www.owasp.org/index.php/Null-pointer_dereference">Refer here</a> for a quick read on what a NULL Pointer Dereference vulnerability is.<br /><br />Over the past week, the latest Linux NULL Pointer Dereference exploit has rendered millions of servers world-wide vulnerable to root compromise. Here's the <a href="http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2692">CVE reference CVE-2009-2692</a>.<br /><br />Several local exploits have been released so far, the ones I tried and worked like magic are at:<br />- The shorter one <a href="http://www.securityfocus.com/data/vulnerabilities/exploits/36038-4.tgz">http://www.securityfocus.com/data/vulnerabilities/exploits/36038-4.tgz</a><br />- The longer one <a href="http://www.securityfocus.com/data/vulnerabilities/exploits/wunderbar_emporium.tgz">http://www.securityfocus.com/data/vulnerabilities/exploits/wunderbar_emporium.tgz</a><br /><br />Here's how simply I get root on my box using the former exploit<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://4.bp.blogspot.com/_7Aqd1DA6IrQ/So07NWV3tCI/AAAAAAAAALM/xz4w08-e_hY/s1600-h/proto_ops.png"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer; width: 400px; height: 130px;" src="http://4.bp.blogspot.com/_7Aqd1DA6IrQ/So07NWV3tCI/AAAAAAAAALM/xz4w08-e_hY/s400/proto_ops.png" alt="" id="BLOGGER_PHOTO_ID_5372015031044518946" border="0" /></a>To understand the exploit in detail a good explanation can be found <a href="http://xorl.wordpress.com/2009/08/18/cve-2009-2692-linux-kernel-proto_ops-null-pointer-dereference">here.</a><br /><br />In summary - the exploit does a NULL pointer dereference that lands on page zero that is filled with bytes in your control. The exploit leverages <span style="font-style: italic;">pulseaudio</span>, a setuid binary, to load your code.\0/ bish \0/http://www.blogger.com/profile/17332421144422015996noreply@blogger.com4tag:blogger.com,1999:blog-197897083390786397.post-15152346037139173792009-08-13T10:59:00.006+05:302009-08-13T13:13:46.442+05:30Statefull/Authenticated/Deep Protocol Fuzzing with SulleyOkay so Sulley works, but creating a basic HTTP fuzzer was nothing so cool. It just scratched the protocol surface. How about statefull or in-state protocol with authentication? How but fuzzing the methods/functions and it's arguments deep within?<br /><br />Here is a proof-of-concept dig at leveraging <a href="http://code.google.com/p/sulley/">Sulley</a> to do just that for FTP. Same would be possible to achieve for various other protocols like SMTP, POP3.<br /><span style="font-style: italic;"><br />from sulley import *</span><br /><span style="font-style: italic;"> import socket</span> <span style="font-style: italic;"><br />import ftplib</span> <span style="font-style: italic;"><br /><br />s_initialize("ftp-cmds")<br /><br />if s_block_start("site"):<br /> s_string("status")<br /> s_static("\r\n")<br /> s_block_end() </span> <span style="font-style: italic;"><br /><br />def ftpcon(target):</span><br /> <span style="font-style: italic;"> ftp = ftplib.FTP('localhost','</span>cloner','cloner')<br /><div style="font-style: italic;" id=":5f" class="ii gt"><br />def do_fuzz():<br /> sess = sessions.session(session_<wbr>filename="ftptest.log")<br /> target = sessions.target('localhost', 21)<br /> sess.add_target(target)<br /> sess.pre_send=ftpcon<br /> sess.connect(s_get("ftp-cmds")<wbr>)<br /> sess.fuzz()<br /><br />if 1:<br /> do_fuzz()</div><br />Firing this generates 1076 test cases for fuzzing (ofcourse you could add to the existing Sulley attack library to generate more test cases) one ftp command post authentication.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://3.bp.blogspot.com/_7Aqd1DA6IrQ/SoO3u7Xq2wI/AAAAAAAAAK8/JP6NMVeqW8w/s1600-h/Sulley_FTP.png"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer; width: 374px; height: 400px;" src="http://3.bp.blogspot.com/_7Aqd1DA6IrQ/SoO3u7Xq2wI/AAAAAAAAAK8/JP6NMVeqW8w/s400/Sulley_FTP.png" alt="" id="BLOGGER_PHOTO_ID_5369337197594598146" border="0" /></a><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://2.bp.blogspot.com/_7Aqd1DA6IrQ/SoO3uNN469I/AAAAAAAAAK0/1A5vEi-qa0k/s1600-h/Wireshark_FTP.png"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer; width: 400px; height: 153px;" src="http://2.bp.blogspot.com/_7Aqd1DA6IrQ/SoO3uNN469I/AAAAAAAAAK0/1A5vEi-qa0k/s400/Wireshark_FTP.png" alt="" id="BLOGGER_PHOTO_ID_5369337185205545938" border="0" /></a><br />This code can be extended to fuzz all the ftp commands/methods and its arguments that are available post authentication in a statefull manner.<br /><br />Let's see what it really took to get this done. It was <a href="http://docs.python.org/library/ftplib.html">FTPLIB</a> that made it possible for us to take establish an authenticated session with the target Pure-FTPd server. The <a href="http://docs.python.org/contents.html">default python installation</a> comes with libraries for several other protocols like SMTP, HTTP and POP3 as well.<br /><br />For encrypted protocols <a href="http://docs.python.org/dev/library/ssl.html">SSL python library</a> is available in case you do not wish to use proto=ssl option from Sulley.<br /><br />How difficult is it to write something like FTPLIB or the authentication/statefull piece for your target protocol? The short answer is - it depends - on protocol specifications (if at all you have) and your mileage. Good skill set at <a href="http://docs.python.org/library/socket.html">Python socket programming</a> can boost your mileage considerably!<br /><br />Let's look at a snippet of FTPLIB and see what does it take.<br /><br /><span style="font-style: italic;"> def connect(self, host='', port=0, timeout=-999):</span><br /><span style="font-style: italic;"></span><span style="font-style: italic;"> self.sock = socket.create_connection((self.host, self.port), self.timeout)</span><br /><span style="font-style: italic;"> self.af = self.sock.family</span><br /><span style="font-style: italic;"> self.file = self.sock.makefile('rb')</span><br /><span style="font-style: italic;"> self.welcome = self.getresp()</span><br /><span style="font-style: italic;"> return self.welcome</span><br /><br />No wonder why hackers love Python!\0/ bish \0/http://www.blogger.com/profile/17332421144422015996noreply@blogger.com3tag:blogger.com,1999:blog-197897083390786397.post-34240605115244311292009-08-10T16:17:00.004+05:302009-08-10T18:10:27.176+05:30Network Protocol FuzzingArguably fuzzing is one leading technique hackers have leveraged over a decade to discover scores of software security issues.<br /><br />For a detailed look into techniques, tools, pros & cons a look at <a href="http://cansecwest.com/csw08/csw08-miller.pdf">Charlie Miller paper is worth a read</a>.<br /><br />There are two well-known fuzzing frameworks <a href="http://code.google.com/p/sulley/">Sulley</a> & <a href="http://peachfuzzer.com/">Peach</a> - that could be leveraged to create your own fuzzers. I haven't had had a dig at Peach as I haven't yet exhausted Sulley yet or run into major road blocks. The author of Sulley - <a href="http://code.google.com/u/pedram.amini/">Pedram</a> has been quite considerate to answer my queries and the tool looks promising so far.<br /><br />It is fairly straight forward to crank up your first fuzzer if your protocol is as simple as HTTP.<br /><br />Following code is what I needed to write to get a basic fuzzer ready to torture an HTTP server. The intention was just to have a feel of Sulley. The real goal otherwise is to do some really complex things. But yeah - the things below had to respond to get my confidence & investment.<br /><br /><span style="font-style: italic;">from sulley import *</span> <span style="font-style: italic;"><br /><br />s_initialize("HTTP VERBS BASIC")<br />s_group("verbs", values=["GET", "HEAD"])<br />if s_block_start("body", group="verbs"):<br /> s_delim(" ")<br /> s_delim("/")<br /> s_string("index.html")<br /> s_delim(" ")<br /> s_string("HTTP")<br /> s_delim("/")<br /> s_string("1")<br /> s_delim(".")<br /> s_string("1")<br /> s_static("\r\n\r\n")<br />s_block_end()<br /><br /></span> <span style="font-style: italic;">def do_http_fuzz() :</span><br /><span style="font-style: italic;"> sess = sessions.session(session_filename="audits/http_session_test.txt")</span><br /><span style="font-style: italic;"> target = sessions.target("127.0.0.1", 80) <br /></span> <span style="font-style: italic;"> sess.add_target(target)</span> <span style="font-style: italic;"> <br /> sess.connect(s_get("HTTP VERBS BASIC"))</span> <span style="font-style: italic;"> <br /> sess.fuzz()</span><br /><span style="font-style: italic;"> print "test completed"</span> <span style="font-style: italic;"> </span><br /><br /><span style="font-style: italic;">do_http_fuzz()</span><br /><br />Firing this script on a latest Apache web server results in 9062 test cases and the wireshark screenshot shows some of the attack patterns that are sent to Apache.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://4.bp.blogspot.com/_7Aqd1DA6IrQ/SoAN6lW7YaI/AAAAAAAAAKA/SjiCWuvo7Cs/s1600-h/Sulley_HTTP.png"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer; width: 400px; height: 301px;" src="http://4.bp.blogspot.com/_7Aqd1DA6IrQ/SoAN6lW7YaI/AAAAAAAAAKA/SjiCWuvo7Cs/s400/Sulley_HTTP.png" alt="" id="BLOGGER_PHOTO_ID_5368306055937483170" border="0" /></a><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://4.bp.blogspot.com/_7Aqd1DA6IrQ/SoAOUQC0_FI/AAAAAAAAAKI/1n1S6dtGuAI/s1600-h/Wireshark_HTTP.png"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer; width: 400px; height: 224px;" src="http://4.bp.blogspot.com/_7Aqd1DA6IrQ/SoAOUQC0_FI/AAAAAAAAAKI/1n1S6dtGuAI/s400/Wireshark_HTTP.png" alt="" id="BLOGGER_PHOTO_ID_5368306496892632146" border="0" /></a><br />This was simple. But then this is HTTP. How about session oriented or stateful protocols like FTP or even better with encryption SSH? And how about fuzzing deep within a protocol? Fuzzing FTP methods or the protocol methods that are reachable only after a valid secure authenticated session is created? The answer is yes, a framework that can facilitate all this would be a great asset for many security testers.<br /><br />In my next post we will look at fuzzing a stateful protocol. Precisely we will look at fuzzing deep within a stateful protocol post authentication.\0/ bish \0/http://www.blogger.com/profile/17332421144422015996noreply@blogger.com2tag:blogger.com,1999:blog-197897083390786397.post-1216504499015022152009-06-01T18:34:00.000+05:302009-07-01T18:30:02.039+05:30SIP Protocol Fuzz TestingFuzzing is a black-box testing technique heavily leveraged to discover flaws in software and protocol implementations. There are several tools that exist today to help a security tester automate or allow crafting fuzz test cases.<br /><br />I have used open-source tools like WebScarab, some commercial ones and the proprietary ones for several years for testing web applications. In between had chance to fuzz test standalone applications and Internet browser clients as well.<br /><br />Recently I had an opportunity to fuzz test VoIP applications and servers. This is when I came across this interesting project called <a href="http://www.ee.oulu.fi/research/ouspg/protos/">PROTOS</a>. It provides test suites for testing several protocol implementations. The ones that I found interesting due to my subject knowledge were <a href="http://www.ee.oulu.fi/research/ouspg/protos/testing/c07/sip/index.html">SIP</a>, <a href="http://www.ee.oulu.fi/research/ouspg/protos/testing/c05/http-reply/index.html">HTTP-REPLY</a> and <a href="http://www.ee.oulu.fi/research/ouspg/protos/testing/c06/ldapv3/index.html">LDAP</a>. Nevertheless it provides test suite for <a href="http://www.ee.oulu.fi/research/ouspg/protos/testing/c09/dns/index.html">DNS</a> and several others.<br /><a href="http://www.ee.oulu.fi/research/ouspg/protos/testing/c07/sip/index.html"><br />PROTOS Test-Suite: c07-sip</a> has been accredited for discovering flaws in several open-source and commercial SIP protocol implementations ranging from Cisco, Alcatel, Nortel to IPTel. It contains 4527 tests. I used this test suite to test <a href="http://www.iptel.org/ser">SIP Express Router</a> (SER) and <a href="http://www.asterisk.org/">Asterisk</a> both open-source SIP proxy implementations. I could successfully reproduce the <st1:stockticker>CERT</st1:stockticker> advisory <a href="http://www.cert.org/advisories/CA-2003-06.html">CA-2003-06</a> for SER’s vulnerable SIP implementation version. The c07-sip test suite crashed SER within the first 10 tests leveraging a format string attack. The screenshots below highlight the status of SER before and after the attack.<p></p><br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://2.bp.blogspot.com/_7Aqd1DA6IrQ/SkjBdHib8AI/AAAAAAAAAHk/qVq6rRUeQhI/s1600-h/ser_running.PNG"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer; width: 400px; height: 203px;" src="http://2.bp.blogspot.com/_7Aqd1DA6IrQ/SkjBdHib8AI/AAAAAAAAAHk/qVq6rRUeQhI/s400/ser_running.PNG" alt="" id="BLOGGER_PHOTO_ID_5352740863113687042" border="0" /></a><p></p><br /><br /><p class="MsoNormal"><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://4.bp.blogspot.com/_7Aqd1DA6IrQ/SkjBxZEoJwI/AAAAAAAAAHs/5batYMdv9S8/s1600-h/ser_crashed.PNG"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer; width: 400px; height: 74px;" src="http://4.bp.blogspot.com/_7Aqd1DA6IrQ/SkjBxZEoJwI/AAAAAAAAAHs/5batYMdv9S8/s400/ser_crashed.PNG" alt="" id="BLOGGER_PHOTO_ID_5352741211417880322" border="0" /></a></p><br />Tests conducted on the latest version of SER and Asterisk did not bring up any security issues. Nevertheless great but this test suite should not be considered comprehensive in itself as it only tests a subset of SIP methods, namely INVITE messages. For a comprehensive test some commercial solution like <a href="http://www.codenomicon.com/products/d3-sip-uas.shtml">Codenomicon</a> or <a href="http://www.mudynamics.com/">MuDynamics</a> probably would be a better bet. I haven’t used both of these thus far so I can’t really ascertain their value. Codenomicon had sponsored the PROTOS project with their testing framework so quite likely they would be good as well. <p></p> At the end of the day, lack of coverage doesn’t undermine the importance of PROTOS suite in any manner. It is base minimum that a related protocol implementation must pass!\0/ bish \0/http://www.blogger.com/profile/17332421144422015996noreply@blogger.com3tag:blogger.com,1999:blog-197897083390786397.post-23425883050656493782008-08-09T17:33:00.008+05:302009-07-01T18:14:02.628+05:30Additional Security Issues: Hacme Casino<a href="http://www.foundstone.com/us/resources/proddesc/hacmecasino.htm">Hacme Casino</a> from Foundstone is a well known vulnerable web application from the Hacme series used as a learning platform for secure software development. It is accompanied with a solution guide that demonstrates security issues in the application.<br /><br />During my own usage – for self-learning, developer group trainings and security group demonstrations I have discovered a few more vulnerabilities that I am sharing here for the benefit of those who wish to get more out of Hacme Casino.<br /><br /><span style="font-weight: bold;">1. Vulnerability Exploited: Insecure Direct Object Reference<br /></span><br />For vulnerability description <a href="http://www.owasp.org/index.php/Top_10_2007-A4">refer here</a>.<br /><br />As seen in the screenshot below, it is possible to download potentially any file from the web server's file system without authentication by guessing and directly referencing it's path. Here we have downloaded <span style="font-style: italic;">boot.ini</span> which is arguably not sensitive. Nevertheless sensitive files can be potentially downloaded as well.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://2.bp.blogspot.com/_7Aqd1DA6IrQ/SktWz4PdvJI/AAAAAAAAAI0/wgkLCriABd0/s1600-h/HC_IDOR_1.PNG"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer; width: 400px; height: 197px;" src="http://2.bp.blogspot.com/_7Aqd1DA6IrQ/SktWz4PdvJI/AAAAAAAAAI0/wgkLCriABd0/s400/HC_IDOR_1.PNG" alt="" id="BLOGGER_PHOTO_ID_5353468031330532498" border="0" /></a><br /><br /><span style="font-weight: bold;">2. Vulnerability Exploited: Session Fixation</span><br /><br />For information on Session Fixation <a href="http://www.owasp.org/index.php/Session_Fixation">refer here</a>. Following steps confirm the vulnerability.<br /><br /><span style="font-style: italic;">Step 1: Login with a fixed session ID as seen in the <a href="http://www.parosproxy.org/index.shtml">Paros proxy</a> screenshot.</span><br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://2.bp.blogspot.com/_7Aqd1DA6IrQ/SktW0GhswYI/AAAAAAAAAI8/m64WgKt_HVM/s1600-h/SF_1.PNG"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer; width: 400px; height: 258px;" src="http://2.bp.blogspot.com/_7Aqd1DA6IrQ/SktW0GhswYI/AAAAAAAAAI8/m64WgKt_HVM/s400/SF_1.PNG" alt="" id="BLOGGER_PHOTO_ID_5353468035165110658" border="0" /></a><span style="font-style: italic;">Step 2: Check the trapped response from Paros. As we see the session ID is same as what we fixed.</span><br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://4.bp.blogspot.com/_7Aqd1DA6IrQ/SktW0q7Aa7I/AAAAAAAAAJM/0XnGnrCX95w/s1600-h/SF_4.PNG"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer; width: 400px; height: 179px;" src="http://4.bp.blogspot.com/_7Aqd1DA6IrQ/SktW0q7Aa7I/AAAAAAAAAJM/0XnGnrCX95w/s400/SF_4.PNG" alt="" id="BLOGGER_PHOTO_ID_5353468044934933426" border="0" /></a><br /><span style="font-style: italic;">Step 3: This step is not really required but just for a double check. Let's access the OPTIONS link. The </span><span style="font-style: italic;">trapped session ID in Paros is definitely the one that we fixed as seen. The next screenshot confirms</span> <span style="font-style: italic;">indeed it was possible to access OPTIONS with this session ID.</span><br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://1.bp.blogspot.com/_7Aqd1DA6IrQ/SktW0ElDegI/AAAAAAAAAJE/vPG_a174ppI/s1600-h/SF_3.PNG"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer; width: 400px; height: 259px;" src="http://1.bp.blogspot.com/_7Aqd1DA6IrQ/SktW0ElDegI/AAAAAAAAAJE/vPG_a174ppI/s400/SF_3.PNG" alt="" id="BLOGGER_PHOTO_ID_5353468034642311682" border="0" /></a><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://3.bp.blogspot.com/_7Aqd1DA6IrQ/SktW0k7HEjI/AAAAAAAAAJU/_MsZZEi7te4/s1600-h/SF_2.PNG"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer; width: 400px; height: 259px;" src="http://3.bp.blogspot.com/_7Aqd1DA6IrQ/SktW0k7HEjI/AAAAAAAAAJU/_MsZZEi7te4/s400/SF_2.PNG" alt="" id="BLOGGER_PHOTO_ID_5353468043324756530" border="0" /></a><span style="font-weight: bold;"><br />3. Vulnerability Exploited: Cross Site Request Forgery</span><br /><br />For vulnerability description <a href="http://www.owasp.org/index.php/Top_10_2007-A5">refer here</a>. Below are additional functions that are vulnerable to CSRF. The exploitation method is same as described in Hacme Casino guide.<br /><br /><span style="font-style: italic;">http://localhost:3000/account/cash_out</span><br /><span style="font-style: italic;">http://localhost:3000/account/update_options</span><br /><span style="font-style: italic;">http://localhost:3000/blackjack/bet</span><br /><span style="font-style: italic;">http://localhost:3000/video_poker/bet</span>\0/ bish \0/http://www.blogger.com/profile/17332421144422015996noreply@blogger.com38tag:blogger.com,1999:blog-197897083390786397.post-57615404762501650002008-05-15T11:40:00.000+05:302009-06-25T12:27:48.537+05:30CSRF ProtectionAs of this posting CSRF (Cross Site Request Forgery) stands as fifth top most threat for web applications. For information on what CSRF is, read on http://www.owasp.org/index.php/Top_10_2007-A5<br /><br />1. A good protection against this attack is to re-authenticate (like transaction password) or better use two-factor authentication for critical transactions like fund transfer. Taking the CSRF vulnerability from <a href="http://www.foundstone.com/us/resources/proddesc/hacmecasino.htm">Hacme Casino</a> a good solution would be ask for transaction password as shown in the screenshot below -<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://3.bp.blogspot.com/_7Aqd1DA6IrQ/SkMfGnmLqGI/AAAAAAAAAHc/hIgLBPQxDf0/s1600-h/Anti-CSRF.PNG"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer; width: 400px; height: 339px;" src="http://3.bp.blogspot.com/_7Aqd1DA6IrQ/SkMfGnmLqGI/AAAAAAAAAHc/hIgLBPQxDf0/s400/Anti-CSRF.PNG" alt="" id="BLOGGER_PHOTO_ID_5351154980815087714" border="0" /></a><br />2. Another solution is to implement one time nonces. For more information refer the link mentioned above.<br /><br />3. <span style="font-weight: bold;">ASP.Net</span><br />Myth: Having ViewState enabled in a .Net web app would prevent against CSRF attacks.<br /><br />Fact: Having ViewStateUserKey set and set to something that is distinct to each user like "ViewStateUserKey = Session.SessionID" will save you against CSRF attacks.Unknownnoreply@blogger.com3tag:blogger.com,1999:blog-197897083390786397.post-61688090106800043782008-05-03T14:30:00.000+05:302009-06-25T13:25:48.480+05:30Gmail Session Hijacking in 7stepsSession tokens are crown jewels of user identity on a web application. It's no hidden fact that attacks such as XSS (Cross Site Scripting) are on all time rise that steal these tokens leading to user identity theft.<br /><br />Although adequate community emphasis has been laid on XSS & its countermeasures, there are other prevalent techniques and wide-spread issues that can steal session tokens perhaps more easily.<br /><br />The one that I share here is network eavesdropping/sniffing.<br /><br />A vast majority of the web applications that I have come across use HTTP, post authentication. Example: Gmail, Yahoo, Orkut or for that matter any popular public portal. The list includes several intranet/online financial and payroll apps we see day in and day out.<br /><br />Below we see a step-by-step attack where we steal session ID of a Gmail user and hijack it in the process. <strong>(The credit for this exercise is shared with my colleague, Raj, rajaol@gmail.com)</strong>:<br /><br />1. The screenshot below simulates a victim (c00kytest@gmail.com) who is currently accessing his/her Gmail account over a corporate LAN, Cyber Cafe' or Wi-fi hotspot. As we see in the URL bar, the communication is happening over HTTP, i.e. plain text.<br /><br /><a href="http://bp2.blogger.com/_7Aqd1DA6IrQ/SB6tVbVpk6I/AAAAAAAAABQ/p-AVBIAdCgA/s1600-h/1-c00kie.png"><img id="BLOGGER_PHOTO_ID_5196781603659551650" style="margin: 0px auto 10px; display: block; text-align: center;" alt="" src="http://bp2.blogger.com/_7Aqd1DA6IrQ/SB6tVbVpk6I/AAAAAAAAABQ/p-AVBIAdCgA/s400/1-c00kie.png" border="0" /></a><br /><br />2. The second screenshot simulates an attacker sitting somewhere in the same LAN. Though the LAN is a switched environment, the attacker has used a tool called Cain & Abel to become man-in-the-middle (MITM) (there are many tools that can be used to set this up. Ettercap is a good example. We use Cain & Abel for our long time friendship with the tool. We have used it to sniff passwords travelling on SMTP and POP on numerous occasions).<br /><br /><a href="http://bp1.blogger.com/_7Aqd1DA6IrQ/SB6t_LVpk7I/AAAAAAAAABY/2XdDwC47GC8/s1600-h/2-Cain.PNG"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://bp1.blogger.com/_7Aqd1DA6IrQ/SB6t_LVpk7I/AAAAAAAAABY/2XdDwC47GC8/s400/2-Cain.PNG" alt="" id="BLOGGER_PHOTO_ID_5196782320919090098" border="0" /></a><br /><br />The blue circle in the screenshot (IP: 192.168.0.1) highlights the Internet gateway address that we ARP spoof for victim (IP: 192.168.0.110), highlighted in red circle. The second red circle below confirms the success of first step of attack where all victim traffic is getting routed from attacker's machine. By now we should be able to see all traffic going from victim machine.<br /><br />Let's fire up wireshark to read the victim data (again, you can use any sniffing tools for this) The above screenshot shows wireshark getting started.<br /><br />3. As shown in the next screenshot we steal victim's gmail cookie details. This is highlighted in the red circle (IP: 192.168.0.110)<br /><br /><a href="http://bp2.blogger.com/_7Aqd1DA6IrQ/SB6uZbVpk8I/AAAAAAAAABg/YwvgDVbD8I0/s1600-h/3-Wireshark.PNG"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://bp2.blogger.com/_7Aqd1DA6IrQ/SB6uZbVpk8I/AAAAAAAAABg/YwvgDVbD8I0/s400/3-Wireshark.PNG" alt="" id="BLOGGER_PHOTO_ID_5196782771890656194" border="0" /></a><br /><br />4. We copy the cookie details and paste it on a notepad as shown below<br /><br /><a href="http://bp3.blogger.com/_7Aqd1DA6IrQ/SB6u_rVpk9I/AAAAAAAAABo/ym-kkYG9d8Q/s1600-h/4-GX.PNG"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://bp3.blogger.com/_7Aqd1DA6IrQ/SB6u_rVpk9I/AAAAAAAAABo/ym-kkYG9d8Q/s400/4-GX.PNG" alt="" id="BLOGGER_PHOTO_ID_5196783429020652498" border="0" /></a><br /><br />Gmail uses GX token from cookie to track users. It's highlighted in the screenshot above. We just need this value to hijack victim's account.<br /><br />5. As shown in the screenshot below, we go back to attacker's login (rajaol@gmail.com) and use a firefox add-on called Cookie Editor to insert the stolen cookie.<br /><br /><a href="http://bp1.blogger.com/_7Aqd1DA6IrQ/SB6vKLVpk-I/AAAAAAAAABw/RgMk-SWxesE/s1600-h/5-Cookie-Editor.PNG"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://bp1.blogger.com/_7Aqd1DA6IrQ/SB6vKLVpk-I/AAAAAAAAABw/RgMk-SWxesE/s400/5-Cookie-Editor.PNG" alt="" id="BLOGGER_PHOTO_ID_5196783609409278946" border="0" /></a><br /><br />6. We now paste the stolen GX value in the cookie editor as shown below. (We did some trial and error and removed many other cookies. We also changed token value for gmailchat=c00kytest@gmail.com)<br /><br /><a href="http://bp3.blogger.com/_7Aqd1DA6IrQ/SB6vTrVpk_I/AAAAAAAAAB4/BEg_1vN8nTI/s1600-h/5-Edit.PNG"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://bp3.blogger.com/_7Aqd1DA6IrQ/SB6vTrVpk_I/AAAAAAAAAB4/BEg_1vN8nTI/s400/5-Edit.PNG" alt="" id="BLOGGER_PHOTO_ID_5196783772618036210" border="0" /></a><br /><br />7. Alright. We are done. Now change the URL in the attacker's browser to the one highlighted in the screenshot below (some other gmail links were logging us out directly. This one didn't. There might be others too that could give you the access similarly. It's all trial and error). Gmail shows you logged on as victim !!!<br />(highlighted in second red circle)<br /><br /><a href="http://bp1.blogger.com/_7Aqd1DA6IrQ/SB6vcLVplAI/AAAAAAAAACA/P_Q1AjqO92o/s1600-h/6-Hacked.PNG"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer;" src="http://bp1.blogger.com/_7Aqd1DA6IrQ/SB6vcLVplAI/AAAAAAAAACA/P_Q1AjqO92o/s400/6-Hacked.PNG" alt="" id="BLOGGER_PHOTO_ID_5196783918646924290" border="0" /></a><br /><br />Now that we have seen how simple this attack can be (Wi-fi would be even easier. No ARP spoofing required. It's all broadcast. On top of that many still use WEP. WEP is trivial to crack) and the associated threats, let's look at the countermeasures.<br /><br /><strong>Countermeasures:</strong><br /><br />1. Use HTTPS<br />CAVEAT: On a switched LAN, MITM is still possible but your browser will warn you. It will show a certificate error. Users need to take this error seriously and alert the support/security staff. Gmail provides optional email access over https://gmail.com but it is insufficient as it makes other requests over HTTP. Nevertheless you will get a browser warning as soon as the MITM happens (certificate error). You can act upon it accordingly. Yahoo & majority of the other public portals do not provide options HTTPS access.<br /><br />2. If HTTPS is not possible for performance reasons, use multiple cookies & continuous (page-wise or request-wise) tracking mechanism that detects a sudden new connection & logs out the user automatically.<br />CAVEAT: This might still be breakable by an attacker if the MITM started before victim's first access to the site.Unknownnoreply@blogger.com21tag:blogger.com,1999:blog-197897083390786397.post-46988635226622233552008-04-13T18:27:00.000+05:302009-07-01T18:28:13.809+05:30Building Highly Secure ApplicationsBuilding highly secure applications need much more than an after thought Penetration Test and a rare Secure Code Review. Over the past two years the need to integrate security into the SDLC has become larger than ever. There is a growing acceptance & place for security within the application development teams these days. Challenge however has been <span style="font-style: italic;">what, where & how</span>. A key need is to not overdo since it might repel potential adopters.<br /><br />Recently there have been several resources flooding the Internet on how to meet this challenge. I found several that were over-blown & several that were inadequate. Having said that there were fairly good ones. The one that I liked the most & thought met my perception was the <a href="http://msdn.microsoft.com/en-us/security/cc448177.aspx">Secure Development Lifecycle</a> from Microsoft.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://1.bp.blogspot.com/_g1p_D0f-BFM/Sj_T26Xgb2I/AAAAAAAADkE/Cn4_6Hi-8MU/s1600-h/cc448177.SDL-Lifecycle-gradient_0609%28en-us,MSDN.10%29.jpg"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer; width: 400px; height: 70px;" src="http://1.bp.blogspot.com/_g1p_D0f-BFM/Sj_T26Xgb2I/AAAAAAAADkE/Cn4_6Hi-8MU/s400/cc448177.SDL-Lifecycle-gradient_0609%28en-us,MSDN.10%29.jpg" alt="" id="BLOGGER_PHOTO_ID_5350227822673686370" border="0" /></a>As seen above it highlights <span style="font-style: italic;">what</span> security practices need to be incorporated and <span style="font-style: italic;">where</span> in an SDLC. As you dig deeper it addresses the <span style="font-style: italic;">how </span>part as well http://msdn.microsoft.com/en-us/security/cc420639.aspx. I personally like OWASP guides for the <span style="font-style: italic;">how </span>part specifically following<br />- Secure Coding Guide http://www.owasp.org/index.php/Category:OWASP_Guide_Project<br />- Static Analysis/Code Review http://www.owasp.org/index.php/OWASP_Code_Review_Guide_Table_of_Contents<br />- Dynamic Analysis/Penetration Test http://www.owasp.org/index.php/Category:OWASP_Testing_Project<br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://i.msdn.microsoft.com/cc448177.SDL-Lifecycle-gradient_0609%28en-us,MSDN.10%29.jpg"><br /></a>\0/ bish \0/http://www.blogger.com/profile/17332421144422015996noreply@blogger.com5tag:blogger.com,1999:blog-197897083390786397.post-49484135658393153932008-04-05T18:20:00.000+05:302009-07-01T18:21:36.555+05:30J2EE / ASP.Net XSS Protection<span style="font-weight: bold;">J2EE</span><br /><br />We again leverage <a href="http://www.foundstone.com/us/resources/proddesc/hacmebooks.htm">Hacme Books</a> for an example vulnerable code.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://4.bp.blogspot.com/_7Aqd1DA6IrQ/SktOY4CT-RI/AAAAAAAAAH0/gYinU12eEHQ/s1600-h/main_XSS_J2EE_1.PNG"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer; width: 400px; height: 54px;" src="http://4.bp.blogspot.com/_7Aqd1DA6IrQ/SktOY4CT-RI/AAAAAAAAAH0/gYinU12eEHQ/s400/main_XSS_J2EE_1.PNG" alt="" id="BLOGGER_PHOTO_ID_5353458771325876498" border="0" /></a>Here the victim requests <span style="font-style: italic;">feedbackitem</span> that may potentially comprise malicious code.<br /><br />We fix this using output encoding method. Here we use Struts <span style="font-style: italic;">bean:write</span> tag that supports output filtering of dangerous characters in the HTTP Response by default.<br /><br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://4.bp.blogspot.com/_7Aqd1DA6IrQ/SktOZMTilgI/AAAAAAAAAH8/QaE_XN6aEzw/s1600-h/main_XSS_J2EE_2.PNG"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer; width: 400px; height: 54px;" src="http://4.bp.blogspot.com/_7Aqd1DA6IrQ/SktOZMTilgI/AAAAAAAAAH8/QaE_XN6aEzw/s400/main_XSS_J2EE_2.PNG" alt="" id="BLOGGER_PHOTO_ID_5353458776766846466" border="0" /></a>As you might have noticed, we did not do any input validation and instead accepted the malicious code in first place. Depending on the use cases or the functional requirements, it might or it might not be required. If needed, <span style="font-style: italic;">Struts Validator</span> class could be used. As a best practice it is always recommended to do input validation as well.<br /><br /><span style="font-weight: bold;">ASP.Net</span><br /><br />Below is a vulnerable code <a href="http://www.foundstone.com/us/resources/proddesc/hacmebank.htm">Hacme Bank</a>.<br /><br /><span style="font-style: italic;">string messageSubject = txtSubject.Text;</span><br /><span style="font-style: italic;">string messageText = txtText.Text;</span><br /><br />Here <span style="font-style: italic;">txtSubject.Text</span> and <span style="font-style: italic;">txtText.Text</span> could be injected with malicious code.<br /><br />However if we use <a href="http://msdn.microsoft.com/en-us/library/aa973813.aspx">Microsoft Anti-Cross Site Scripting Library</a> the malicious code would be encoded when displayed to a victim and hence rendered harmless.<br /><br /><span style="font-style: italic;">string messageSubject = AntiXss.HtmlEncode(txtSubject.Text);</span><br /><span style="font-style: italic;">string messageText = AntiXss.HtmlEncode(txtText.Text);</span><br /><br />Again we allowed the application to accept malicious input in first place. If threat profiling of use cases necessitate, ASP.Net in-built validation routine called <span style="font-style: italic;">RegularExpressionValidator</span> could be leveraged to filter the unwanted input.<br /><br />The example below enforces txtSubject.Text and txtText.Text to accept alphabets and numbers only.<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="http://4.bp.blogspot.com/_7Aqd1DA6IrQ/SktOZWQdfnI/AAAAAAAAAIE/UY0aWrZAfkU/s1600-h/main_XSS_ASPNEt.PNG"><img style="margin: 0px auto 10px; display: block; text-align: center; cursor: pointer; width: 400px; height: 117px;" src="http://4.bp.blogspot.com/_7Aqd1DA6IrQ/SktOZWQdfnI/AAAAAAAAAIE/UY0aWrZAfkU/s400/main_XSS_ASPNEt.PNG" alt="" id="BLOGGER_PHOTO_ID_5353458779438284402" border="0" /></a>\0/ bish \0/http://www.blogger.com/profile/17332421144422015996noreply@blogger.com3tag:blogger.com,1999:blog-197897083390786397.post-91681797339917968292008-04-04T18:17:00.000+05:302009-07-01T18:18:57.013+05:30J2EE / ASP.NET SQL Injection Protection<span style="font-weight: bold;font-size:100%;" >J2EE</span><span style="font-size:100%;"><br /><br />Let's take a vulnerable code example from <a href="http://www.foundstone.com/us/resources/proddesc/hacmebooks.htm">Hacme Books</a>.<br /><br /></span><span style="font-style: italic;font-size:100%;" >String query = "select * from products where " + “lower(title) like '%" + keyword.toLowerCase() + "%‘”;</span><span style="font-size:100%;"><br /><br />As seen </span><span style="font-style: italic;font-size:100%;" >keyword</span><span style="font-size:100%;"> is passed to the interpreter without validation or encoding.<br /><br />For SQL Injection protection, the secure version with Prepared Statement as shown below can be used.<br /><br /></span><span style="font-style: italic;font-size:100%;" >PreparedStatement query = con.prepareStatement( “select * from products where lower(title) like ?");</span><span style="font-size:100%;"><br /></span><span style="font-style: italic;font-size:100%;" >query.setString(1, keyword);</span><span style="font-size:100%;"><br /></span><span style="font-style: italic;font-size:100%;" >updateSales.executeUpdate():</span><span style="font-size:100%;"><br /><br /></span><span style="font-weight: bold;font-size:100%;" >ASP.Net</span><span style="font-size:100%;"><br /><br />A vulnerable code example from <a href="http://www.foundstone.com/us/resources/proddesc/hacmebank.htm">Hacme Bank</a> looks like this.<br /><br /><span style="font-style: italic;">string sqlQuery = "select user_id from fsb_users where login_id = '" + loginID+ "' and password = '" + password + "'";</span><br /><br />Here the <span style="font-style: italic;">loginID</span> and <span style="font-style: italic;">password</span> are passed to the MS SQL server without validation or encoding .<br /><br />Using a secure replacement with SQLParameters as below this attack can be mitigated.<br /><o:shapelayout ext="edit"></o:shapelayout><o:idmap ext="edit" data="1"></o:idmap><span style="font-size:100%;"><p:colorscheme colors="#FFFFFF,#000000,#808080,#000000,#BBE0E3,#333399,#009999,#99CC00"></p:colorscheme></span></span><span style="font-style: italic;font-size:100%;" ><br />string sqlQuery = "select user_id from fsb_users where login_id = @loginID and password = @password";</span><span style="font-size:100%;"><br /></span><span style="font-style: italic;font-size:100%;" >//Assuming you have defined a command called 'cmd'</span><span style="font-size:100%;"><br /></span><span style="font-style: italic;font-size:100%;" >cmd.Parameters.Add(New SQLParameter("@loginID", loginID))</span><span style="font-size:100%;"><br /></span><span style="font-style: italic;font-size:100%;" >cmd.Parameters.Add(New SQLParameter("@password", password))</span><span style="font-size:100%;"><span style="font-size:100%;"><br /></span><br /></span>\0/ bish \0/http://www.blogger.com/profile/17332421144422015996noreply@blogger.com0