I know Arian Evans from Whitehat Security has been working on the .NET request validation bypass that we talked about last month for a while now. He actually went through and mapped it out much further. Here’s his writeup:
So basically here’s the anatomy of this attack vector:
(everything in [brackets] including the brackets represents a variable)
So for the IE exploit vector you have:
1. HTML close tag. The tag is arbitrary.
2. Escaping & padding between the HTML tag and STYLE attribute + between HTML tag and STYLE attribute you need a “/” some padding, any will do (e.g.-%20), and another “/”
3. After the STYLE tag you need an arbitrary declaration; e.g.- “color:” will work, and “a:” will work. And “z:” will work.
4. Then you insert one of IE’s dynamic properties, like expression(). However, this too must be passed/escaped to bypass the .NET request validator.
5. The only escaping I’ve found to work so far, that gets *parsed* by Internet Explorer is /**/ (unlike the above padding between tag and attribute). You can, however, put this anywhere: e/**/expression == expressio/**/n == espre/**/ssion == etc
For some reason IE is particular about only reading /**/ for padding/escaping. I fuzzed a subset of metachars; mostly combinations from 2-3 “top rows” and others like colons, periods, etc., and even ones that get by the input filter break the dynamic property so that IE won’t execute it.
Pretty interesting stuff. I think this will all get fixed in the future, but for now it works. I’ve never understood why you can add style attributes to end tags in the first place. Seems superfluous and error prone to me, not to mention murder on filters!