a/sec-schwab3

Date:         Wed, 6 Dec 2000 12:03:54 -0800
From: Elias Levy <aleph1@SECURITYFOCUS.COM>
Subject:      Charles Schwab Online Trading Vulnerability
To: BUGTRAQ-PRESS@SECURITYFOCUS.COM

Today Jeffrey Baker announced to BUGTRAQ a vulnerability in the
Charles Schwab online trading web site. The vulnerability is of a
type known as Cross Site Scripting and is not all that different
from the one Etrade suffered not very long ago. If successful
an attacker can take control of the session of a user logged on
to the Schwab trading site.

The vulnerability is Cross Site Scripting vulnerability. This is
basically a trust problem in which user's client (the browser)
is fooled into sending some data in a request to a vulnerable server
(usually via a link) which the vulnerable servers then inserts into
a web page which it displays to the client without sanitizing and which
the client assumes is the servers data and thus trusts as such.

In this way malicious users can fool other user's web clients to interpret
malicious data (e.g. JavaScript) in the trust context of the vulnerable
web server which allows them to do things such as stealing that
client/server's cookies.

This is a common flaw of web based applications which is the result for
the web's ease of referrals and data transfers between non-related
web pages (what makes the web what it is: the link) and the lack of
input validation by the web based applications when displaying possibly
untrusted data to the user. The later is the result of the lack of good
programming practices by programmers of web based applications and by
the lack of a web based programming environment that implements features
to support more than a simple trust model such as data tainting or
mandatory access controls.

Until web based applications are written in an environment that supports
some trust model that is enforced we'll continue to see this type of
problems.

Return-Path: <owner-bugtraq@securityfocus.com>
Delivered-To: bugtraq@lists.securityfocus.com
Received: from securityfocus.com (mail.securityfocus.com [207.126.127.78])
	by lists.securityfocus.com (Postfix) with SMTP id 7D23024CF3B
	for <bugtraq@lists.securityfocus.com>; Tue,  5 Dec 2000 11:00:54 -0800 (PST)
Received: (qmail 4036 invoked by alias); 5 Dec 2000 19:00:50 -0000
Delivered-To: bugtraq@securityfocus.com
Received: (qmail 4033 invoked from network); 5 Dec 2000 19:00:50 -0000
Received: from mta6.snfc21.pbi.net (206.13.28.240)
  by mail.securityfocus.com with SMTP; 5 Dec 2000 19:00:50 -0000
Received: from desktop ([63.197.31.211])
 by mta6.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.2000.01.05.12.18.p9)
 with ESMTP id <0G5300JMZYWJCL@mta6.snfc21.pbi.net> for
 bugtraq@securityfocus.com; Tue,  5 Dec 2000 10:48:25 -0800 (PST)
Date: Tue, 05 Dec 2000 10:53:56 -0800 (PST)
From: "Jeffrey W. Baker" <jwbaker@acm.org>
Subject: Charles Schwab online trading various lame vulnerabilities
X-Sender: jwb@desktop
To: bugtraq@securityfocus.com
Message-id: <Pine.LNX.4.21.0012051050460.24886-100000@desktop>
MIME-version: 1.0
Content-type: TEXT/PLAIN; charset=X-UNKNOWN

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Security Advisory: Various Charles Schwab online trading problems

*Date

4 December 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

Charles Schwab operates an online securities trading service.  On 25
August 2000 I discovered three security problems with this service.  
Between 25 August and 28 August 2000, I had discussions with Schwab staff,
but with no result.  As of the time of this writing, the flaws still exist
and I have no reason to believe that they are in the process of being
fixed.

*Synopsis

Through cross-site scripting[1], an attacker can gain control of the
account of a Charles Schwab customer who uses the online trading service.  
The attacker can choose to either gain interactive use of the service, or
to cause the account holder to perform inadvertent unwanted actions on the
attacker's behalf.

Additionally, it may be possible to predict a user's login cookie.

*Details

The Schwab trading web site does not properly validate form input.  In
some places, the form input is echoed back to the user's browser without
proper HTML escaping.  Therefore, it is possible for an attacker to cause
JavaScript code to be executed in the user's browser.  The attacker could
use this ability to retrieve the HTTP cookie which Schwab uses for user
authentication.

As a proof-of-concept, a Schwab user could visit this URL, and their login
cookie will be presented to them in a JavaScript alert dialog.  The
proof-of-concept can be easily modified to instead send the login cookie
to an arbitrary HTTP server.  The URL is:

https://investing.schwab.com/trading/trdmoesverify/?menu=2&submenu=1&ADOrderEntryNumber=0&AffirmativeDetermination=0&prenv=N&numOrders=3&Symbol0=foo%22><script>alert(document.cookie)</script><input%20value=%22&TradeType0=Select+One&Quantity0=&OrderType0=&LimitPrice0=&Minimum0=&MinimumQuantity0=&TimeLimit0=Day+Only&StopPrice0=&DoNotReduce0=&AllOrNone0=

There are other locations on the site which exhibit the cross-site
scripting problem.  For example, the forms at
https://investing.schwab.com/trading/quotexec/

Typically, the attacker would need to exploit this problem by causing a
Schwab user to make an HTTP request while logged on to the Schwab service.  
The likely vector for such an attack would be a link or image embedded in
an email or a message on a stock trading bulletin board.  Heavy users of
the service are the most vulnerable.

While I investigated these problems, I noted that the Schwab login cookie
only varied in the first five character positions at each login.  The
first character was always a hex digit, and the other four were in the
range [0-9A-Z].  I did not attempt a cryptanalysis, but I have a moderate
suspicion that it may be possible to predict the login cookie with
reasonable success.

*User Impact

This bug affects potentially all Schwab users.  To defend against this
attack, the user should:

1) disable JavaScript in the browser.  I do not know if the Schwab site
relies on JavaScript for proper operation.

2) not visit any other web sites, read email, or use bulletin boards while
using the Schwab web site.

3) always log off of the Schwab web site when done using it.

4) always close and restart the browser before and after using the Schwab
web site.

*Suggested Resolution

Schwab should examine their programs to ensure proper input validation.  
Their system should use a form key to ensure that form input comes from
the authenticated user interactively.

As an organization, Schwab should strive to fix problems when given
five-month advance notice.  They should raise their ethical standards to
alert their paying customers whenever a system vulnerability is reported.

*Footnotes

[1] CERTŽ Advisory CA-2000-02 Malicious HTML Tags Embedded in Client Web
Requests.  http://www.cert.org/advisories/CA-2000-02.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.3 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE6LTjfMAHoQs8KQqwRAqkgAJ0frXTDU7Bkw71iz9lH5N89UEkC4gCgj9ze
bZLbX3xIcEs3B8Iq3bagJds=
=iOWQ
-----END PGP SIGNATURE-----


----- End forwarded message -----

--
Elias Levy
SecurityFocus.com
http://www.securityfocus.com/
Si vis pacem, para bellum