Affects : IIS 5.0, IIS5.1, Maybe 6.0 as-well. Didn't work for >= 7.0.
Information :
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
we can write
we can write
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 τ for "t", κ 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 Ω 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 τ 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.
Real life example : Big commerce website such as ebay does have a reason to hide its server version (running IIS or Apache, which version, etc...). Although this is not the case this post can confirm you're not being mislead by a wrong header (which someone put there for letting attackers failed at the first attempt and anyone would be ready when they try more attempts).
Can you see that logo in the top left of ebay?
Let's abuse the logo's name in-order to get relevant information about this server... is it running an out-dated IIS or new IIS/APACHE?
Image path is : http://pics.ebaystatic.com/aw/pics/logos/logoEbay_x45.gif let's change the "o"s for Ωs and try again after building the following custom html page :
If you want to try it out you can also check out : with this image as-well from a very popular news website
Few decodings you can use now :
t <== τ ==>
%CF%84
%%43%46%%38%34
%%%43%46%38%34
o <== Ω ==>
%CE%A9
%%43%47%%41%39
%%%43%47%41%39
Or just the alpha presentation of them, i.e : Τ α Ω etc.%CF%84
%%43%46%%38%34
%%%43%46%38%34
o <== Ω ==>
%CE%A9
%%43%47%%41%39
%%%43%47%41%39
Vendor Contacted (Microsoft) : 31/12/2009
Vendor response :"After investigation we have determined that this functionality is by design. ...
Character encoding issues are complex and servers behave in different ways. If a particular Web Application Framework cant deal with different encodings the general consensus is that it is the WAF's fault due to the fact that it is trying to make a security guarantee that it can not live up to".
My response to Vendor response :
This problem can be used for information disclosure. I know it works for IIS 5.0, and IIS 5.1....
It doesn't work on IIS >= 7.0.
If that was planned then why this functionality had been removed from later versions?
I don't think it's the WAF's fault since no-one is aware of this issue (WAF's writers)...
This bug is definitely not critical or harmful, but it can be dangerous in some cases (i.e : telling the user that the server is running old IIS to try some exploits on it which he wouldn't have tried before because admin removed server header, or bypassing some applications with this encoding)."
I got better advisories which I'm waiting for other vendors to patch before I publish. I've published this because Microsoft will not release a patch (probably) for this issue, although it did make EBAY to switch from IIS to APACHE after few days of contacting them. I wonder if that got any impact on Microsoft.
Enjoy!
Posts
