Hi vuln-dev readers, This could be entitled "A year later, Microsoft(c)(tm) still vulnerable to the unicode double decoding security hole", or "the IIS unicode hack strikes Krosoft(r) again", but i am tired of stupid titles. People wanting interesting things can skip the junk bytes here and read the "vulnerability" paragraph only. (for dummies: please note that IIS is *not* affected by this vulnerability, i am talking about a similar hole in Microsoft's webmail) BLAH BLAH I found the following a few months ago, just after publishing another flaw on the hotmail's html/javascript filter. I forgot it. A month later I realized it was still there, so I warn Microsoft about it. The funny thing is that I didn't remember a specific example of exploitation at this time, so i told them the concept. They asked for more details, i tried to help, but they were unable to reproduce and fix the security hole until I provide them with an exploit. Then they understood and fixed it very quickly (thanks !). [ For newbies: javascript could be inserted in html emails, so cookie could get stolen, and emails read/destroyed/etc... not even mentionning the potentially desastrous webmail worm. And yes, it is still possible, sure, so don't use webmails to store personal/sensitive data and make backups. ] CHALLENGE So Microsoft was very responsive, very good at fixing it, but here is my problem. I cannot understand that: I was able to find this vulnerability in a few hours without access to their source code, and without knowing where and what to search for. HOW is it possible that the security engineers from hotmail, having access to the source code, having the following details about the vulnerability, where unable to find it ? I'd like to know if the problem is me (bad explanations) or them (or maybe i am a genius ;) So here is the challenge: can you provide me (by email) with an exploit, which you think could have worked at the time, for this vulnerability ? (without being an hotmail engineer, you cheater; no troll please, give an exploit or nothing) (WELL-KNOWN CLASS OF) VULNERABILTY(IES) I provide the details of the vulnerability here (without the exploit) so that people programming filters of *any* kind can think about it, and maybe fix their broken codes. Better realize that now than never. The idea is: don't modify the data parsed by your filter ! If you apply a filter on an input, you want to give the user, as an output, the *same* input, not a modified one. Why ? Cause if you don't do that, the output you will give to the user will not have been really parsed by your filter (yeah, your filter did its job, but on another flow of data). Very basic example: a filter that strips out the string 'abcd' will give on input 'ababcdcd' the ouput 'abcd'. Not good... Of course you could replace 'abcd' by 'void', that's what many filters do, but it could be a potential risk. So don't modify things. Either reject the whole input and give nothing as output, or if you had to modify it, then take the output and pass it through the filter again. (more than two steps if necessary, of course; and beware of infinite loops). So what about Hotmail ? Well, where can we put unicode in an html message ? Into an url as %xx, yep, but that's not the point here. There is a thing called "html entities" : you can replace *any* printable character by its ascii/unicode value in the values of the parameters of html tags, for instance in the parameters of the STYLE tag (hint !). "A" is A, "B" is B, etc. What the hotmail filter did is replacing any html entity by its corresponding character, then trying to filter out any bad string (forbidden keywords), THEN giving the output to the user, without re-applying the filter on this output. But, if there are still html entities into this output, the user's browser will interpret them, that will possibly give birth to some interesting forbidden keywords... and fire a script. The double decoding issue in IIS was triggered by things like %252e were %25 is the hex unicode value for '%'. I let it you find the equivalent for html entities, it is obvious. TO CONCLUDE Never use webmails if you care about one of the three aspects of the word "security". Don't even put a webmail on your server for your users, since they will use the same password as their local account. A good filter is similar to firewall rules, accept some keywords, then deny all. BTW, Yahoo finally fixed the <<script> issue. Regards, FozZy Hackademy & Hackerz Voice Director PS: what about a filter-bypass contest at Defcon ? ;)
This archive was generated by hypermail 2b30 : Mon Jul 15 2002 - 09:03:18 PDT