Microsoft IIS self decoding behavior leads to WAF Bypass/information disclosure

Author: Itzhak Avraham
Blog : http://imthezuk.blogspot.com
article source: http://imthezuk.blogspot.com/2010/02/microsoft-iis-5051-possibly-60.html

Affects :
IIS 5.0, IIS5.1, Maybe 6.0 as-well. Didn't work for >= 7.0.

I’ve done some fuzzing in-order to find some weaknesses at one application I was testing for fun, but in the middle of doing this process I’ve found a neat security bug which is not in common knowledge and that’s what makes it a risk.

Let's create a weird circumstances where this could become handy : Let’s say a content-filtering program wants to block anything that goes into a gif file “blockedkeyword.gif" in upload directory (i.e I’ve seen this in for example dotdefender Web-Application Firewall),

WAF's job would be blocking anything that translates into blockedkeyword.gif (in UTF8, UTF7, etc...) If a word would translate to blockedkeyword.gif, WAF's job would be dropping the request.

But if we’ll use special characters which are not in common-knowledge to block, we can bypass this one and many other mechanism.

Instead of writing:

<img src="http://www.siterunningiis5.1.com/upload/blockedkeyword.gif">

we can write :

<img src="http://www.siterunningiis5.1.com/upload/blockedkeyw&#937;rd.gif">


i.e put the HTML code above in firefox or IE8 and you'll find out that for IIS had decided to translate on his own the Greek-Letter OMEGA to "o". Why would IIS do that? I have no idea. It also works for other letters such as &#964; for "t", &#954; for "k" etc...

Usually pentesters/hackers will look for special ways to write requests such as : Unicode, or other encodings. But it shouldn’t be, in any way, that IIS decides to translate &#937; or other greek letters to plain English.

Impact: Under certain terms, it might lead to :
	a.  Information Disclosure (tells which version of the website if site had decided to remove it from headers) - I will try to contact tenable to create a plugin out of this information described here.

	b.  Bypass security restrictions.

	c.  Bypass security mechanism checks for common letters such as “t” in every encoding, but not as &#964; which 	shouldn’t be translated to “t” at server side.

	d.  More research could lead to other findings with this issue such as low chances of : Directory Traversal/Remote Code Execution/Other information disclosure : Might lead to directory traversal/security bypass (it depends if there’s another unknown letters who translates to “.” or “/” or “//”).

I havn't had any success in exploiting this issue in using malformed client-side code (i.e : xss) since it doesn't parse like real t's or 'o's for client side code havn't yet checked impact on Server side code. Filenames restrictions does seem to be vulnerable to this issue though.