Re: IE URL obfuscation

From: James C. Slora Jr. (Jim.Slora_at_PHRA.COM)
Date: 12/14/03

  • Next message: Russ: "Re: IIS user credentials caching" 
    Date:         Sun, 14 Dec 2003 17:52:46 -0500
To: NTBUGTRAQ@LISTSERV.NTBUGTRAQ.COM

    The main point of the bug is that it makes standard reality checks
    untrustworthy. It takes only a tiny amount of creativity to extend
    exploitation far beyond the narrowly defined phishing scenario.

    The bug also helps start page (tested), favorites (tested) and possibly
    search page (not tested - probably useful on pre-XP systems) hijackers by
    hiding the fact that the browser has been compromised - without needing to
    modify the hosts file or DNS settings. The slash character behavior Russ
    mentioned is less of a mitigator in these circumstances, since so many users
    have the IE default www.msn.com as their start page and search engines
    normally run at the top of their domain. Also, it is easy enough to create
    credible workarounds to the slash issue. See below.

    The bug might or might not make the initial hijacking easier, but it helps
    hide the fact that anything has happened afterwards while avoiding making
    system changes that would be likely to attract an admin's attention.

    This gives the vulnerability commercial potential in the gray area inhabited
    by adware, spyware and browser helpers, and pretty much guarantees that it
    will be exploited in the wild on at least a moderate scale by more than just
    outright criminal phishers.

    I would like to see Microsoft make this issue a very high priority because
    it potentially can expand into a whole family of exploitable weaknesses in
    all sorts of stored URLs, not all of which will necessarily be closed with a
    single fix.

    How many more things could this bug help people exploit? Any of these could
    possibly be candidates.
    TypedURLs entries - you can't even trust your own previous typing
    CA URLs stored in the registry - maybe help fake SSL connections more
    effectively
    Product update pages - obvious consequences
    etc etc

    A %5C or %255C (or similar variations) after the fake URL but before the
    unprintable character will allow the fake URL to be extended to subpages
    while appearing fairly authentic - and it will probably pass muster with
    many admins as well since both resolve to a slash. &#5c after the URL will
    display a little square instead of the slash separator - probably still
    close enough for a lot of end users. At most, people will think Explorer has
    gone quirky instead of knowing that they were not visiting the page they
    expected. XP Pro, IE6 up to rev.

    And what do you know - the exploitation of this bug also hides the page
    visit from the user's History file. Neither the fake URL nor the actual page
    show up in the IE History at all. Another reality check hidden from the
    user. XP Pro, IE6 up to rev.

    On top of this, now we get to deal with more reports of getting malware from
    visiting some site - but the site may not even be the one the user reported.
    How many log and analysis packages will also get screwed up by this? Maybe
    even the admin's central records won't show the proper URL visited.

    Shouldn't the vulnerability be addressed now instead of waiting for months
    upon months of far more creative variations that are finally exploited on a
    scale large enough to embarrass Microsoft into action? Or should we let the
    bad guys take the lead on this and see where they go with it?

    -----
    Want to reply to the person who sent this message?

    This list is configured such that just hitting reply is going to result in the message coming to the list, not to the individual who sent the message. This was done to help reduce the number of Out of Office messages posters received. So if you want to send a reply just to the poster, you''ll have to copy their email address out of the message and place it in your TO: field.
    -----

  • Next message: Russ: "Re: IIS user credentials caching"

    Relevant Pages