Advisory: E*TRADE security problems in full (fwd)

Date view Thread view Subject view Author view

From: Tom Whore (tomwhore@inetarena.com)
Date: Mon Sep 25 2000 - 13:16:55 PDT


---------- Forwarded message ----------
Date: Mon, 25 Sep 2000 10:36:01 -0700
From: Jeffrey W. Baker <jwbaker@ACM.ORG>
To: BUGTRAQ@SECURITYFOCUS.COM
Subject: Advisory: E*TRADE security problems in full

On Sun, 24 Sep 2000, Marc Slemko wrote:

> For better or worse, I have no compunctions about making exploits
> for poorly designed applications public after a company has refused
> to take action despite knowing about the risks, plus I felt like
> doing some quick and dirty coding tonight. There is no way they
> (whoever "they" are; this may well be code developed by some outside
> company) should have written the code this way to begin with, and
> there is no way it should have been missed in the security audits
> that etrade hopefully did.

Since Marc spilled the beans, there isn't much point in protracting this
further. Below is the PGP-signed advisory that I promised in my original
User Alert. E*TRADE seems to have rolled out a new cookie scheme over the
weekend, but it isn't going to do one bit of good unless they plug the
dozens of cross-site scripting problems littering their site.

Will I continue to release this style of Alert? I think so. The ratio of
encouragement to flames was about 5 to 1. I don't think it is smart to
release exploit code against a financial institution. I regard that as
giving away the combination to the vault at the bank. I think my User
Alert is more like handing out flyers to the bank customers warning them
that the bank doesn't bother locking the vault at night.

Finally, E*TRADE customer service representatives have been flatly denying
the security problems all weekend, while also calling my BugTraq alert
"spam". I take this sort of defamation very seriously, and I hope that
E*TRADE will issue a public apology today.

Best,
Jeffrey Baker

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

Security Advisory: E*TRADE Usernames and Passwords Remotely Recoverable

*Date

21 September 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

E*TRADE is a company which allows its customers to trade securities using
the World Wide Web. In E*TRADE's own words, they have "some of the most
advanced technology for Web security." E*TRADE compares their services to
a steel vault, a moat, and Fort Knox.[1]

Between 17 and 21 August 2000, I discovered a number of vulnerabilities in
the security of E*TRADE's systems. E*TRADE was contacted via the email
aliases security@etrade.com and webmaster@etrade.com on 21 August 2000.
Soon thereafter I was in contact with the Director of System Security and
the Manager of Security Threat Analysis. Emails were exchanged on 21, 22,
and 23 August 2000. E*TRADE officials indicated that they were already
aware of the security problems listed herein, but had not fixed them due
to various kinds of corporate inertia. At the time of this writing, the
problems were still outstanding in E*TRADE production systems, and no
estimated date has been mentioned for fixing them.

*Synopsis

A combination of cross-site scripting and an incredibly bone-headed cookie
authentication scheme allows a remote third-party attacker to recover the
username and password of any E*TRADE user. The attacker can use this
information to gain full control over the E*TRADE account.

*Details

E*TRADE uses a cookie authentication scheme which they apparently wrote
themselves. When a user logs in, E*TRADE concatenates the username and
password, transforms it with a lookup table, and sends the string back to
the user's browser as a cookie. This string is then sent back to E*TRADE
on every request. If the user chooses to have a persistent login, the
cookie is stored on the user's disk.

This is the lookup table they are using. The single characters on the
left are converted into the double characters on the right:

! HI 9 IA Q OI i LA
" HJ : IB R OJ j LB
# HK ; IC S OK k LC
$ HL < ID T OL l LD
% HM = IE U OM m LE
& HN > IF V ON n LF
' HO ? IG W OO o LG
( H@ @ NH X O@ p MH
) HA A NI Y OA q MI
* HB B NJ Z OB r MJ
+ HC C NK [ OC s MK
' HD D NL \ OD t ML
- - HE E NM ] OE u MM
. HF F NN ^ OF v MN
/ HG G NO _ OG w MO
0 IH H N@ ` OH x M@
1 II I NA a LI y MA
2 IJ J NB b LJ z MB
3 IK K NC c LK { MC
4 IL L ND d LL | MD
5 IM M NE e LM } ME
6 IN N NF f LN ~ MF
7 IO O NG g LO
8 I@ P OH h L@

Example: the user "fred" with a password of "123" would get a login cookie
"LNMJLMLLIIIJIK". The cookie "LELIMJMAILIMIN" can be reversed to obtain
"mary" and "456".

The cookie can be obtained remotely via cross-site scripting. There are
input validation errors in multiple places on the E*TRADE site. As a
proof of concept, try this URL:

https://trading.etrade.com/cgi-bin/gx.cgi/AppLogic+LoginPage?userid=%22><script>alert(%27Have%20a%20nice%20day%27)</script><input%20value=%22

If JavaScript is enabled, your browser should show an alert dialog with
the text "Have a nice day". This bug could be exploited independently of
the cookie bug to make the user execute an unwanted trade or transfer of
money.

*User Impact

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

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

2) not use the 6-month persistent login option. This option will cause
the cookie to be stored in a file on the user's disk, which opens up
another vector of attack (via e.g. "brown orifice" in Netscape Navigator)

3) stop using the E*TRADE web site.

*Suggested Resolution

E*TRADE should examine their programs to ensure proper input validation,
and replace their cookie authentication scheme with a random session key
which can be destroyed on the server.

*Footnotes

[1]http://www.etrade.com/cgi-bin/gx.cgi/AppLogic+About?gxml=hpc_disc_secure_c.html&lvl=about
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE5y3v0MAHoQs8KQqwRAogjAKChk/Qz/uvJGW+lDdm5yGm6QajdsACgq4RZ
hr6oWMxwEbL0BbgmR02o/UA=
=Obc7
-----END PGP SIGNATURE-----


Date view Thread view Subject view Author view

This archive was generated by hypermail 2b29 : Mon Sep 25 2000 - 13:18:24 PDT