Fwd: Re: Security flaw found in Microsoft Web browser

[InfoSec News <isn () c4i org>]

---------- Forwarded message ----------
Date: Thu, 15 Aug 2002 16:09:24 -0400
From: Ian Grigg <iang () systemics com>
To: dbs () philodox com
Subject: Fwd: Re: [ISN] Security flaw found in Microsoft Web browser

I'm not actually on InfoSec News, but here's a personal
reply that seems to merit sharing.

----------  Forwarded Message  ----------

Subject: Re: [ISN] Security flaw found in Microsoft Web browser
Date: Thu, 15 Aug 2002 07:49:38 -0400
From: Ian Grigg <iang () systemics com>
To: <someone>

On Thursday 15 August 2002 00:53, you wrote:
> On Wed, Aug 14, 2002 at 04:34:58AM -0500, InfoSec News wrote:
> > Not that anyone will believe them, but in this case, it is indeed
> > appropriate to assure that MITM attacks are hard.
>
> Hello Ian. They aren't hard, they're trivial in many places where
> most people could be shopping from, like university or student's
> house networks, internet caffees etc.

You see, it all turns on the definition of hard. I postulate to you
(and the world) that what is easy for the techie is hard for the
crook.

It is hard for the thief to employ an MITM because:

    1.  he (Mallory) needs access to the traffic

    2.  Mallory needs to sift through a *lot* of
    traffic in order to find one CC.  I'll leave the
    quantity as an exercise...

I grant you that WiFi or similar makes access to the data easier, much
more so than in the past, but see 2., above.  In the past, access to
traffic more or less implied a trusted position such as a network
administrator.  Which ruled out thievery, as the two are, in general,
incompatible occupations.

But, Mallory is still stuck with 2.  He takes a large degree of risk
in sitting there condicting his attack, whilst waiting for his credit
card.

Alternatively, he could just use his talents to hack into some windows
machine on the net somewhere, and scarf up a database load of credit
card information.  All pre-filtered for quality, and collected in a
nice format.

That's what I mean by being hard.  Thieves are not fools and they are
not techies.  They have a mission, and the generally choose the most
cost-effective way of doing it.  And, in this case, sniffing credit
cards from the net is so low on the success ratings that

> Take a look at my demonstration at
> http://arch.ipsec.pl/inteligo.var, which I tried to perform for
> plain curiosity, and it worked very nice.

Right!  One of the things that your average Mallory will need is such
demos, but even then, the barriers are significant.  BTW, you have,
coincidentally, identified yourself as a non-Mallory type :-)

The issue that we, as security professionals face, is that we are
still fixated on the inadequate 100% security model:  Fix 100% of
issues within the code.

In the real world, security doesn't work like that.  There are risks
that are too small too worry about, and there are costs that make some
risks not worth worrying about.

Practically speaking, the browsers fix an issue that is a very low
risk, but impose mammoth costs on the server providers:  SSL servers
are forced to have certs.

Consequence of this is that SSL usage is way down below what it should
be for a successful protocol.  It's hard to come up with a good
comparison, but consider SSH versus telnet, as against SSL versus
straight HTTP.

So, the way to re-address this balance is to fix the browsers to
create *two* security locks. One for certified sessions (advised for
confidential user data) and one for encrypted sessions (advised for
general private browsing).

The fix is simple:  don't discriminate against un-certified sessions,
and let the user enjoy straight old boring encryption-protected
sessions, albeit with slight risk of Mallory's interest.

My bet:  use of certificates will go up.  I'll leave the business
logic of that for now...

--
iang




-
ISN is currently hosted by Attrition.org

To unsubscribe email majordomo () attrition org with 'unsubscribe isn'
in the BODY of the mail.