Re: Advisory: E*TRADE security problems in full

[Gunther Birznieks <gunther () EXTROPIA COM>]

I think this brings up an interesting point about disclosure which is close
to home.

That is, what is the best way to notify users? What percentage of users
read BUGTRAQ versus security aficionados and hackers? The problem of
disclosure on a list like this is that the majority of real users will NOT
be reading the messages here and will never realistically find out about
this until they read it on the front page of the New York Times or E*TRADE
actually bothers to email its own customers.

Unfortunately it seems that many posts on here say the vendors don't listen
or don't care. On the other hand, I've seen stuff posted in the past about
our stuff where the author of the post never emailed me first and
therefore, hackers would find out about a bug before I could generate a
mailing to all the people who used my software (I don't give out our
mailing list).

Of course, the disadvantage of lack of vendor cooperation is that (A) The
user's lose out on knowing about the problem and (B) The exploit and any
posted fix may reflect an amateur insight into the problem and not really
solve the issue -- that is, the vendor should actually endorse whatever fix
is posed rather than someone who doesn't know all the details of the
software's design coming up with the fix.

I don't know what to suggest. Although perhaps it would be useful if
vendors would voluntarily have their users subscribe to a special filtered
version of BUGTRAQ based on the vendor name. So, for example, Schwab would
link to a special Bugtraq security mailing list that they encourage their
users to subscribe to incase Schwab ever had a security hole. If there are
no security holes, the user would get no emails. ever. But if one ever did
pop up, it wouldn't be Scwab telling the user's it would be BUGTRAQ.

Vendors of security sensitive web services could use this as a selling
point of their service. That they give a highly trusted 3rd party the
capability of letting them know about any problems so they cannot ever hide
a problem. I know if BUGTRAQ offered such a service, I would link to them
and encourage our users to use them. As it is, the traffic on a real
BUGTRAQ mailing list is too much to expect the common user who has minimal
computer skills to read and filter BUGTRAQ on their own.

<SOAPBOX (Stating The Obvious)>

Of course, I hope this exploit becomes front-page material but who knows.
Although maybe its not front page news since  to people who have worked in
the financial industry, the lack of general security is well known. Many
financial houses put an extreme amount of pressure to deliver products on
their IT departments and this leads to pressure to cut security corners all
over the place.

The fact is that in many financial places an Internal Audit department is
really there in order to satisfy the minimal requirements of the Feds not
because of any semblance of real security. Not all financial houses operate
this way, but there are many that do.

And who can blame a company like E*TRADE. They've been in business how many
years without being caught? Yet if they spent 2 months longer on each app
making it work "right", then they would slowly fall behind their other
competitors who may pay equal disregard to security. Paying attention to
security, unless you are likely to get caught, is simply not a competitive
advantage. They must have felt that they were unlikely to get caught.

</SOAPBOX>

At 09:18 PM 9/25/2000 -0700, Ben Galehouse wrote:
> "Jeffrey W. Baker" wrote:
>
> > 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.
>
> I think that the idea of slow disclosure is workable. I think it does
> give the end users a little bit of a head start on the black hats. But
> spreading the disclosure out over weeks or months might be too big of a
> delay.
>
> As was demonstrated here, security problems are often easy to find once
> you know where to look.  A week after an initial advisory on a problem
> like this, and anybody who really wants to know the problem is likely
> to.  I think that your initial advisory should have broadcast intent to
> publish on a commesurate timeline.  Seriously.  Once the blackhats have
> it figured, the game is up.
>
> The end user accounts were never _really_ secure, and during the week
> following such an advisory they become less secure.  This is the price
> of any sort of disclosure, therefore the price of security. I think it
> is safe to say that the only way to make systems secure is for the
> managers who run them to be responsible. Public disclosure serves to
> make them responsible.

__________________________________________________
Gunther Birznieks (gunther.birznieks () extropia com)
eXtropia - The Web Technology Company
http://www.extropia.com/