Security Advisory: Cross-site scripting vulnerability compromises accounts on Altavista, ICQ, US West/Qwest, others *Date 21 August 2000 *Author Jeffrey W. Baker, email jwbaker@acm.org *Copyright statement This security advisory is Copyright 2000 by Jeffrey William Baker (jwbaker@acm.org). 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): Click here for hot, naked teens! 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.