> 3. Now, if while composing new message G1 directly types e-mail > address g2at_private instead of G2, Outlook will compose address as > "g2at_private" <bat_private> and message will be received by B. What an elegant attack! Effectively, the software is doing *exactly* what it's supposed to: Allow individuals to be mailed according to their chosen name instead of their direct email address. But since it's rendering chosen names in the exact same manner as the fallback direct address, by *choosing* a name that *appears* to be a fallback address one can choose to be any name they want to be--and since Outlook Express gives higher precedence to chosen names than it does to direct emails, the wrong person will be mailed every time and the user can be none the wiser. After all, pixel for pixel, *everything* is doing just what it should. Now, email spoofing has existed for a long time, but hasn't been abused much since one can only *send* spoofed messages, not receive their replies. Even Reply-To manipulation shows up in one way or another...but not this. This is totally invisible, and I think even more effective than NNOV noted. Incidentally, *nothing* prevents messages from being further forwarded once they've been illicitly received. This may be one of the more dangerous methods of executing a man in the middle attack with email alone. Microsoft is correct that the problem is not a trivial fix: The problem is one of user confusion, driven strongly by the fact that the user is being shown *exactly* what they'd be seeing in a normal, non-attack scenario. There isn't the case of a bug in the code; this is primarily a design issue. An immediate design fix would be to use a different coloring and fontfacing scheme to refer to full names, rather than quoted email addresses from the address book. This should self-document decently, since over the course of sending a number of mails users should learn to associate one character type with one form of name and the other with the other. Then, when the attack hits, people see things "backwards" and some method of investigation can be made available. Things get a little sticky if you start trying to autodetect this attack, because of situations where parts of an email address are removed(like bobat_private -> bobat_private, for instance), but I think a decent method could be engineered. Personally, a tooltip popping over an appropriately drawn chosen name whenever the mouse was held over it would be both very useful and a decent fix. *Something*, however, does need to be done. Autocomplete on address book names is easily one of the top 1% of features in OE5, and it really depends on auto-adding on reply(which filters out spam). IT depts aren't going to be able to get away with a mass disable of this feature, it simply won't happen. (Things like this are moderately common when the bug attacks user perceptions rather than simply broken code.) Due to the severity of this issue(yes, someone might eventually hysterically report "NEW ATTACK LETS ME READ YOUR EMAIL BEFORE YOU EVEN GET IT"), I do think it'd be appropriate for an update in a reasonable timeframe, with backporting to all affected platforms. Yours Truly, Dan Kaminsky, CISSP Cisco Systems, Inc. http://www.doxpara.com
This archive was generated by hypermail 2b30 : Tue Jun 05 2001 - 18:02:09 PDT