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.

27 of 621 comments (clear)

  1. Another IDN bug on Firefox by IO+ERROR · · Score: 5, Informative
    When trying this out on Firefox on Linux, I noticed that the URL in the address bar is rendered two or three pixels lower than normal. If you're paying close attention, this is easy to spot. Also, the "real" URL appears in the status bar while the spoofed page is being loaded, i.e. "Looking up www.xn--pypal-4ve.com..."

    To disable IDN as a workaround for this problem (on Gecko-based browsers): hit about:config and set network.enableIDN to false.

    --
    How am I supposed to fit a pithy, relevant quote into 120 characters?
    1. Re:Another IDN bug on Firefox by vivin · · Score: 5, Informative

      Who says this is a Linux vulnerability? This is a browser vulnerability.

      Browsers != Linux.

      And it's not FUD - it is an actual problem. It sure tricked Firefox running on my windows machine.

      --
      Vivin Suresh Paliath
      http://vivin.net

      I like
    2. Re:Another IDN bug on Firefox by Troed · · Score: 4, Informative

      Works 100% as advertised in Opera. No easy way to spot it's fake.

      On the other hand, this is nothing new. This was predicted a long time ago when debating on how to handle websites with charactersets incompatible with the ones used in Western countries ..

    3. Re:Another IDN bug on Firefox by squiggleslash · · Score: 4, Informative
      Just tried it on Safari, and unfortunately none of the "bugs" that occur in Firefox that give the game away are present. Mouseover looks like Paypal. Connecting message shows nothing untoward. Renders as "www.paypal.com" in the regular font and location on the URL bar.

      I wonder if there's a quick and easy fix for this for Safari users, like there is for Firefox (about:config, network.enableIDN -> false.)

      --
      You are not alone. This is not normal. None of this is normal.
    4. Re:Another IDN bug on Firefox by duvie · · Score: 3, Informative
      One: the setting of enableIDN to false appears to have NO effect.

      Two: The only way to see that you are not at paypal (unless you notice the flash-by in the status bar) is to look at the certificate details. For the POC site, the certificate was issued to "www.xn--pypal-4ve.com"

      We all read those certs every time, neh?

    5. Re:Another IDN bug on Firefox by finkployd · · Score: 5, Informative

      To disable IDN as a workaround for this problem (on Gecko-based browsers): hit about:config and set network.enableIDN to false.

      That is a great suggestion, except for the part where it does not work.

      Go ahead, make the change, then restart your browser. Now go look at about:config again. Yup, still set to false. Now go see if it the setting worked. It does not. So at least with Firefox 1.0 just took a bad situation and made it worse. Now people will think turning off this setting will actually accompolish something and protect them and it will not.

      Finkployd

    6. Re:Another IDN bug on Firefox by aWalrus · · Score: 4, Informative

      It worked for me (firefox in OS X). What it does is fix the lookup, not the display, so the links will still look as they did, but when you click on them it says "domain not found"

      --
      Overcaffeinated. Angry geeks.
    7. Re:Another IDN bug on Firefox by double-oh+three · · Score: 4, Informative

      And when this was presented at Shmoocon they mentioned that, IIRC they said that it was first thought up in 2001. Safari's fooled too, with the source code thing not apparently working. However if you try to save the page the international characters will disappear from the filename.

      --
      "For years, I struggled with reality... but I'm happy to say I finally won out over it." -- Elwood P. Dowd
    8. Re:Another IDN bug on Firefox by AstroDrabb · · Score: 4, Informative
      Hmm, I stand corrected. Setting enableIDN and then testing worked right away for me. Until I restarted my browser. About:config still shows enableIDN set to false, but the spoof works again. However, if I go back into about:config and reset enableIDN to false, it again stops the spoof.

      Maybe it is a problem in the Firefox startup code not setting enableIDN properly.

      --
      If Tyranny and Oppression come to this land,
      it will be in the guise of fighting a foreign enemy. -James Madison
    9. Re:Another IDN bug on Firefox by AstroDrabb · · Score: 3, Informative

      Restart you browser and then try again. I thought it was working until a restart of Firefox and it appears that the Firefox startup code doesn't properly set enableIDN based on your profile settings. As soon as you restart, the spoof works again. However, go into about:config and you will see that enableIDN is still set to false, so toggle it to true and then false again and the spoof won't work. Rinse, repeat.

      --
      If Tyranny and Oppression come to this land,
      it will be in the guise of fighting a foreign enemy. -James Madison
    10. Re:Another IDN bug on Firefox by strider44 · · Score: 3, Informative

      It's obvious without even looking for it on my 1280x1024 low-size font resolution. However most users will just think "that's odd" and not take any precautions.

    11. Re:Another IDN bug on Firefox by bahamat · · Score: 4, Informative

      It was probably cached, which does nothing to help anyone. Any user no matter how long they've been using computers is apt to think that disabling it will make a difference right away. I've been developing websites for close to 10 years, and browser cache is the biggest thorn in my side in that area.

      While you can view the certificate in Firefox, it takes a whopping 4 clicks to get the info that shows the page is bogus (double click the lock icon, click security tab, click view cert). The average user will never find it. Even the above average users will be thrown by the General tab which shows the spoofed URL as though it were the real one. If they don't actively hunt down all indications that a site may be spoofed, they're going to be fooled.

      What's worse, is that Safari doesn't even give the option to view certificates that it thinks are valid (not expired and signed by a valid root CA).

      Ouch.

    12. Re:Another IDN bug on Firefox by bunratty · · Score: 5, Informative

      This has been reported as bug 281377.

      --
      What a fool believes, he sees, no wise man has the power to reason away.
  2. IE also fails! (kinda) by grandmofftarkin · · Score: 4, Informative
    The first thing I did was fire up IE (a rare occurrence) and test this. IE also failed (for me). Then I remembered that I have the i-Nav plug-in installed. Granted, this isn't actually a fault of IE then but rather the plugin. Though it should be noted that IE is only spared because (in it's default configuration, i.e. without the plugin) it doesn't support standards. In this case that standard is Punycode.

    This would actually appear to be a flaw in the Punycode standard rather than the browsers themselves, given that all IDN (internationalized domain name) aware browsers similarly fail.

    Looks like someone may have to fix Punycode. Then we can update the browsers. In the mean time perhaps Opera, Firefox, etc. can given some kind of visual notification when Punycode is used, in the same way the URL turns yellow when a secure URL is entered in Firefox.

  3. Firefox 1.0 by rubypossum · · Score: 4, Informative

    If you "View Source" for some weird reason the real address shows up in the title bar.

    --
    I have a theory that the truth is never told during the nine-to-five hours. - Hunter S. Thompson
  4. Opera won't fix it? by MoonFog · · Score: 5, Informative

    From the text:
    VI. Vendor Responses

    Verisign: No response yet.
    Apple: No response yet.
    Opera: They believe they have correctly implemented IDN, and will not be making any changes.
    Mozilla: Working on finding a good long-term solution; provided clear workaround for disabling IDN.

    So, Opera won't fix it? They have a proof of concept, and Opera believe their implementation is correct? Maybe, but they still need to provide an update, and something tells me they will .. eventually.

  5. network.enableIDN doesn't fix things by openSoar · · Score: 5, Informative

    The 'fix' they mention (setting network.enableIDN to false via about:config) only works until you restart the browser - when you reopen the browser, things are back to the same even though the setting is still false..

    1. Re:network.enableIDN doesn't fix things by finkployd · · Score: 4, Informative

      I was fully prepared to test this myself, find out you were either full of it (or a troll), and let /. know you were wrong.

      My plan was going perfectly, right up to the point where what you said turned out to be 100% correct :(

      Shame on Firefox for taking a bad situation and making it worse. If about:config reports that a security related setting is X when in fact it is Y, this is worse than not providing a fix at all. A false sense of security (from a browser that is supposed be better) is worse than being aware of the security problems and reacting accordingly.

      Finkployd

  6. ICANN is worried too by Peter_Pork · · Score: 5, Informative
    From ICANN's log:
    There are many technical problems with this change. It essentially undermines IDNA, which is now on standards track, by adding a level of guessing to the DNS that IDNA is explicitly designed to avoid. Further, it makes it appear that IDNs are only useful in domain names for web sites (and only for sites in .com and .net), and only at the second level. VGRS has said that their plug-in will not work with most of the ccTLDs, for example.

    For example, if you enter .com in Internet Explorer for Windows, where "" is the single hex octet 0xE5, you see the screen shown in the attached file called "[lynn-message-to-iab-06jan03-]e5.tif". (Sorry about the TIFF image, but it's the only reliable format for PC screen dumps.) As you can see, VGRS makes wild guesses about what the user wanted, some of which are very clearly impossible. Worse yet, they do not include all of the legal guesses that they could have made. And, just to make it completely confusing to the user, not all of the choices work.

    The DNS is not supposed to be a best-guess service, yet VGRS has turned .com and .net into this just before IDNA is to be an RFC. VGRS should not be allowed, through its monopoly on the .com and .net gTLDs, to destroy the coherence of the DNS for its own short-term profit. ICANN should demand that VGRS immediately stop giving incorrect answers to any query in .com and .net, and should instead follow the IETF standards. If VGRS refuses, ICANN should re-delegate the .com and .net zones to registries that are more willing to follow the DNS standards.
    See this also.
    1. Re:ICANN is worried too by gowen · · Score: 3, Informative

      Neither of those are about this concern (homographs between Cyrillic and Latin alphabets). That's a concern about Verisign using non-IDN methods to do DNS-lookups, and (like the late, unlamented SiteFinder) doing fuzzy matches in the case of unrecognised UTF domain names.

      --
      Athletic Scholarships to universities make as much sense as academic scholarships to sports teams.
  7. notepad by leuk_he · · Score: 5, Informative

    If i copy /paste the link into notepad it just looks right And if i copuy /past it back to firefox i get the "spoofed" page back again.

    next:

    Trolls can have a couple of days fun on slashdot.

    And verisign van sell a lot of domains to phishers. (profit!)

    1. Re:notepad by Myen · · Score: 3, Informative

      Probably depends on Windows version - on 2k/XP at least, Notepad is a Unicode app and can handle non-ASCII characters; not the case in 9x.

      Use the command prompt; by default that wouldn't be able to handle the right characters and should show up as '?'. Actually, I think the default raster font for that just doesn't have the character.

    2. Re:notepad by kerrle · · Score: 3, Informative
      Microsoft didn't "get something right", they just don't support the feature that this takes advantage of.

      IDN support is probably a good thing - we just need a way to show the user the difference between URLs if international characters are used.

  8. IDN pain in the but anyway by spectrokid · · Score: 5, Informative

    Here in Scandinavia, the letters Å,Æ,Ø, are actually quite new. It is acceptable to spell them as AA, AE and OE respectively on non-scandinavian keyboards. With IDN adresses now becomming available, you constantly have to remember which spelling is used on which website. It would be a hell of a lot more practical if only the 26 alphabeth was used and software would automatically expand ingeniøren.dk to ingenioeren.dk. This way you could use whatever you want. And websites will not be too happy about using special characters, because it makes them almost impossible to reach on non-scandinavian computers.

    --

    10 ?"Hello World" life was simple then

  9. Re:This isn't a newly discovered exploit. by mithras+the+prophet · · Score: 3, Informative
    Here's the earlier article: Spoofing URLs With Unicode. Summary:
    "Scientific American has an interesting article about how a pair of students at the Technion-Israel Institute of Technology registered "microsoft.com" with Verisign, using the Russian Cyrillic letters "c" and "o". Even though it is a completely different domain, the two display identically (the article uses the term "homograph"). The work was done for a paper in the Communications of the ACM (the paper itself is not online). The article characterizes attacks using this spoof as "scary, if not entirely probable," assuming that a hacker would have to first take over a page at another site. I disagree: sending out a mail message with the URL waiting to be clicked ("Bill Gates will send you ten dollars!") is just one alternate technique. While security problems with Unicode have been noted here before, this might be a new twist."

    Incidentally, it seems that Slashdot's ASCII-only URL reporting system successfully deflects such spoofing here: Go to paypal.com

    --
    four nine eighteen twenty-7 thirty-nine forty-7 fiftyeight sixty-nine seventy-9 eighty-8 one-hundred-and-nine one-twenty
  10. Unicode has already fixed this problem by fizbin · · Score: 4, Informative

    There is already a fix for this IDN problem in the unicode spec, if people would just use it:

    Before resolving, all domain names should be normalized according to normalization form KC. (see http://www.unicode.org/unicode/reports/tr15/) Once that's done, anything that looks like an "a" really will be an "a", and not something that looks identical in Cyrillic.

    That simple (SIMPLE!) step would avoid this problem, almost completely. There'd still be an issue with people using "paypál" instead of "paypal", but at least then the user has some vague chance of seeing the difference in the URL in the browser window.

    It would also be good if responsible registrars refused to accept domain registrations for domains not normalized according to NFKC, but asking companies to refuse business simply because someone else would get hurt is probably not going to be effective.

  11. A few more browser tests (and IE *is* affected) by Reziac · · Score: 4, Informative

    Where "sees" means "displays it this way on the status line":

    Netscape 3.04 sees http://www.p?ypal.com/ -- looks the same in docsource

    OffByOne 3.4a sees http://www.p0ypal.com/ -- looks the same in docsource

    K-Meleon 0.9 sees http://www.p?ypal.com/ -- looks like http://www.pypal.com/ in docsource

    IE 5.00.2314.1003 (yes, minor builds can make a *big* difference in how IE displays stuff) sees it as http://www.paypal.com/, but the "a" is about half normal size (this is at 1024x768). Docsource as IE feeds it to notepad looks like http://www.pypal.com/

    Mozilla 1.5 sees it exactly the same as IE5.00 (above), including docsource

    AOLpress (HTML editor with built-in browser) sees it exactly the same as OffByOne (above), including docsource

    Netscape 4.50 sees http://www.p?ypal.com/ but displays http://www.pypal.com/ in docsource

    Firebird 0.7 sees it exactly the same as Moz 1.5 and IE5.00 (above), including docsource

    And Mosaic 0.9 can't figure out WHAT to do with the page and wants to save it to disk.

    At this point, I ran out of installed browsers. :)

    --
    ~REZ~ #43301. Who'd fake being me anyway?