Posts Tagged ‘XSS’

Newer Entries »

Exploiting IE8 UTF-7 XSS Vulnerability using Local Redirection

Tuesday, May 12th, 2009

Conventions:
Attacker Domain – Securethoughts.com
Target Domain – 50webs.com

If you don’t remember, there was an important XSS vulnerability reported in all major browsers a while ago – IE7, Firefox and Opera. More Information is available in the Secunia advisories here. The vulnerability was that if you don’t specify a charset in your application page, then it is susceptible to inherit the charset in the parent page via iframes. So, if you accidently land on an evil site, an attacker might be able to steal your application session since your usual XSS prevention stuff [<,>,",',etc] will not filter the utf-7 encoded chars and XSS will execute in your vulnerable domain. Proof of Concept that works in IE7 but not in IE8 -
http://www.securethoughts.com/security/ie8utf7/ie7utf-7.html

This vulnerability was patched in Firefox 2.0.0.2, Opera 9.20 and recently in Internet Explorer 8. Ideally, we should not be vulnerable to this attack anymore. However, I have found a way to attack the fix that was done in Internet Explorer 8. I have tested it working with IE8 RC1 and final release version IE8.0.6001.18702. I call this a “Local Redirection Attack”.

The attack works as follows:

1. You are authenticated to vulnerable domain e.g. 50webs.com.

2. You land onto the evil site via link –
http://www.securethoughts.com/security/ie8utf7/ie8utf-7.html.

3. The page loads into your IE8 browser.

4. IE8 thinks that it is loading a child page -
[http://www.securethoughts.com/security/ie8utf7/utf-71.html] from the same domain and hence removes the restriction on charset inheritance.

5. This is where Local Redirection Attack comes into play. The attacker sets a temporary redirect on the child page to vulnerable site [http://webappsec.50webs.com/utf-71.html]. Make sure that the link to vulnerable site is a page with your UTF-7 injected characters [Persistent/Reflected XSS]. In this case, my utf-71.html page on 50webs.com has a persistent XSS with UTF-7 characters.

6. The XSS executes in the context of vulnerable site. E.g. if you see below, you can see my 50webs.com member cookie appended with ‘XSS’ in an alert box.

IE8 UTF-7 Charset Inheritance Exploit using Local Redirection

I have been in touch with Jack from Microsoft Security Response Center (MSRC) team for the last 2 months. I would like to thank the Microsoft Security Team for their timely responses and letting me discuss these issues with the security community. They are actively working to resolve this issue and a fix for this vulnerability is expected to arrive in the next version of Internet Explorer, IE9.

Share:
[del.icio.us] [Digg] [Facebook] [Google] [LinkedIn] [Reddit] [StumbleUpon] [Technorati] [Twitter] [Yahoo!] More »

Tags: , , , , , ,
Posted in Browsers, Exploits, WebAppSec, XSS | 18 Comments »

HP’s SWFScan does not find simple XSS in Flash Apps

Tuesday, April 21st, 2009

This will a short post on my review of the new HP’s solution for auditing Flash apps – SWFScan. It has a variety of features, some of which are highlighted on the HP’s Blog here.

Before that, I have used Stefano’s Tool, SWFIntruder. It is a nice tool to audit Actionscript 2 apps, but it only reports XSS issues and does not support Actionscript 3. This time, I was out of luck, since I needed to audit a Actionscript 3 App. Also, I could not decompile and study its source code since the free tool Flare does not work on Actionscript 3.

So, I decided to give HP’s tool a try. I had a lot of expectations from this tool, since HP already has a popular tool WebInspect which is known in the industry for its website and web services auditing capabilities. I ran this tool on my app and it decompiled beautifully the complete source code of the flash app. It has a useful search feature which can aid in manually studying source code for vulnerabilities. However, I wanted to see some of its automatic auditing capabilities. So, I ran the scan and found it to find some issues like crypto issues(sha0/sha1), stacktraces, etc. Apart from that, it didn’t report any serious issues like XSS, etc. It also does report a large number of false positives in checks that start with “Possible/Potentially – - – -”. But i am willing to ignore those as long as the tool can effectively find some important vulnerabilities.

I didn’t know my app had any XSS issues or not, so I decided to use the free test.swf which is provided as part of SWFIntruder.

To my surprise, HP’s SWFScan tool did not report any of the 5 XSS issues reported by SWFIntruder.

If you see the screenshots below, swfscan shows you the vulnerabilities it found and the decompiled source code. Using manual inspection, a penetration tester can easily locate XSS issues in parameters such as _root.obj and _root.sd which are directly written into html without any escaping/filtering. I hope this free SWFScan tool improves in the near future and does not miss auditing such simple vulnerabilities.

SWFScan

SWFIntruder

Share:
[del.icio.us] [Digg] [Facebook] [Google] [LinkedIn] [Reddit] [StumbleUpon] [Technorati] [Twitter] [Yahoo!] More »

Tags: , , , , ,
Posted in Flash, Solutions, Tools, WebAppSec, XSS | No Comments »

Hacking for XSS inside noscript html tags

Saturday, February 14th, 2009

I have found a XSS vector inside html noscript tags. It is very simple and easy. This attack method is not new as it is already discussed in the context of other html tags such as title, textarea, style, etc.

For understanding this attack, first lets compose a simple html file with the following contents:

<noscript>
<script>alert('XSS')</script>
</noscript>

Then lets run this file in your browser (Example – noscript.html). You would notice that it won’t execute the javascript to show an alert box. The reason being:

  1. If you have javascript enabled, then any content inside noscript tags does not get parsed. Check the standards here.
  2. If you don’t have javascript enabled, then content inside noscript tags will be parsed. However, since javascript content is globally disabled, the javascript code inside noscript tags won’t execute as well.

So, then the only way left to execute our malicious XSS inside noscript html tags is to come out of the noscript tag using </noscript> and then use our simple XSS vector. Also, you should add the html comments start tag at the end to prevent any html parser errors. The complete attack vector looks like this:

"></noscript><script>alert('XSS')</script><!--

I have seen some real world examples where this attack is possible. It looks like that Developers have a false illusion in their minds that it is not required to escape user supplied content inside noscript html tags. This posting should help to open some eyes.

The example code given below comes from the html page of a mid-size company that aims to put the world wide web offline. Despite several attempts to contact the site owner, I have not received any response. Since this vulnerability still exists, I have removed the site’s name from the various images below.

1. Javascript content inside title tag is escaped.

2. Javascript content inside input tag is escaped.

3. Javascript content inside noscript tag is NOT escaped.

Share:
[del.icio.us] [Digg] [Facebook] [Google] [LinkedIn] [Reddit] [StumbleUpon] [Technorati] [Twitter] [Yahoo!] More »

Tags: , , ,
Posted in WebAppSec, XSS | 1 Comment »

Newer Entries »