Slashdot Mirror
Shmoo Group Finds Exploit For non-IE Browsers
shut_up_man writes "Saw this on Boing Boing: East coast hacker con Shmoocon ended today and they had a nasty browser exploit to show off... using International Domain Name (IDN) character support to display fake domain names in links and the address bar. Their examples use Paypal (with SSL too) and this looks very useful for phishing attacks. Interesting note that it works in every browser *except* IE (which makes this exploit a lot less dangerous in the end, I suppose)."v The reason IE isn't vulnerable is because it doesn't natively support IDN; with the right plug-in, it too is vulnerable.
I'm surprised to hear that Microsoft's refusal to adopt international standards in their browser actually thwarts a potential phishing attack rather than aiding it. If the problem can't be fixed in the browsers, maybe email clients and websites can find some way of decoding, detecting, and disabling such links. Are phishers going to bother trying to use this exploit if it works on less than 10% of their potential victims?
You are in error. No-one is screaming. Thank you for your cooperation.
Seriously, it's been known for years that adding international character sets was going to cause the problem of multiple identical (or almost identical) characters.
On the other hand, no-one really seems sure of the best way to fix it... One option is obviously to mark somehow when non-ASCII characters are used, but while this will help the people who only want ASCII URLs, it will still leave the problem for everyone who wants to use this extended system, making it effectively useless....
Combination - fun iPhone puzzling
Except when implemented in their own country code namespace of course.
There are so many characters that look alike, that it is trivial to register a domain name that will look the same as another one. Typically the different character would only be recognised by a native that used that character, although using it alongside normal English characters would probably throw them off as well.
Solution? Maybe an "IDN" icon in the URL bar, or a warning if an IDN uses a mixture of normal English characters with some foreign characters in an IDN.
It doesn't seem to work with Lynx, either. The URLs are obviously different from what they're supposed to be, and they don't point to any site at all.
Lynx does try the URL, though, so it may be possible to set up another domain to catch it, but the URL would still be obviously wrong (something like p%a%y%p%a%l.com)
One man's -1 Flamebait is another man's +5 Funny.
This brings up the amusing problem of character recognition by human and non-human intelligences. Douglas Hofstadter discusses this issue in on seeing A's and seeing As.
In the case of this exploit, a deep flaw in IDN and computer fonts means that character #1072 is rendered typographically as an "a". The irony is that this is one of the few cases in which a computer can readily tell the difference between "a" and #1072 and a person cannot. The only solution would be rules that prohibit isomorphic characters in typefaces or a in-browser warning system that analyses the potential for ambiguity and alerts the user.
Two wrongs don't make a right, but three lefts do.
You mean most users will never, ever, notice it. Even I as a Slashdot reader don't look at the URL constantly.
Recon spyware coders will implement this in their programs now so it'll work in MSIE.
If Tyranny and Oppression come to this land,
it will be in the guise of fighting a foreign enemy. -James Madison
I don't claim to be a Unicode expert, but I don't think that normalization form KC will convert U+0430 to 'a', because the Latin small letter A is not its compatability decomposition.
On the other hand, it would prevent spoofing of Greek names using mu and capital omega, or capital A with ring above, or ff ligatures, since there are characters that have them as compatibility decompositions.