NYT Article...IP spoofing: bugtraq article by Jim Duncan

[Jana Vasiljev Tesar]

Dobry den,

Vcera jsem byla upozornena na dost znepokojujici problem v Internetu,
o kterem jsem pak diskutovala s nasimi "sitari" a myslim, ze by nekoho
ze ctenaru mohl zajimat. Prosim za prominuti ty, ktere diskusi o clanku
v New York Times sleduji na bugtraq.

Srdecne zdravi

--Jana Vasiljev

-----------------------------------------------------------------------
Date: Wed, 25 Jan 1995 10:51:51 +0000 (WET)
From: Charles Curran <charles.curran at computing-services.oxford.ac.uk>
Subject: Re: NYT Article...IP spoofing: bugtraq article by Jim Duncan
To: cvxsec at convex.ox.ac.uk

For those of you who do not (yet!) receive bugtraq or who haven't
managed to read the hundreds of messages already circulated this
week about the latest security alert, I recommend the following
lucid response by Jim Duncan sent yesterday.

--
--Charles


>From owner-bugtraq at fc.net Tue Jan 24 18:55:33 1995
Message-Id: <199501241551.KAA06712 at augusta.math.psu.edu>
To: perry at imsi.com
Cc: bugtraq at fc.net, rens at imsi.com
Subject: Re: NYT Article this morning
In-Reply-To: Your message of "Mon, 23 Jan 1995 08:38:12 EST." <9501231338.AA11040 at snark.imsi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 24 Jan 1995 10:51:06 -0500
From: Jim Duncan <jim at math.psu.edu>
Sender: owner-bugtraq at fc.net
Precedence: bulk

"Perry E. Metzger" writes:
> Yes. Its far worse than mere IP spoofing -- that would only get you in
> to places which stupidly trust things like .rhosts files. The Times
> did not accurately describe the scope of the problem. This is a Very
> Bad Problem. People should legitimately worry about this one.

This is correct.  It's the most insidious problem I've seen on the net.

> I know this is a full disclosure list, but I was asked when I learned
> about this several days ago not to divulge details -- I was only told
> on that condition. I'm trying to get in touch with my informant to get
> relased from my promise so that I can describe the situation in
> detail.
>
> Having been in the situation of being an administrator worried about
> such things and not knowing where to turn, I believe in full
> disclosure. I'll try to post as full a disclosure as I can in a few
> hours.

This problem was discussed at length _in the open_ at the CERT BOF last
Thursday night at USENIX in New Orleans.  In fact, it was the nicest CERT
BOF in years mainly because the one time somebody began the old "security
through obscurity" argument, someone else in the audience quickly pointed
out that there were folks there who side on either side of that argument,
but that it couldn't possibly be decided right then in that room.  Instead
the audience concentrated on constructive dialogue and we all learned a
lot.  I can't remember the last time I attended such a useful CERT BOF.

Here, in a nutshell, is what to be worried about.  Far too many systems on
the Internet rely on IP addresses for authentication.  This is bad, in that
IP addresses provide identification, not authentication.  In addition, far
too many routers and gateways will route packets with "bad" source IP
addresses; i.e., they will accept and deliver a packet in which the source
IP address and the destination IP address should be on the same side of the
router.  This could be described as incorrect behavior, but in the past I
think most implementors have viewed this error as somebody else's fault.
Lastly, TCP sequence numbers can be guessed with great accuracy, and Bellovin
and Cheswick, among others, have suggested methods to make this impossible.

The bad guy's machine sends a legitimate packet to the victim's machine,
which could be anywhere in the Internet, destined for a legitimate service.
The victim's machine responds with a legitimate acknowledgement, including
a sequence number.  The bad guy's machine then uses the incoming sequence
number to guess the next number and sends a packet for some service, rsh,
for example, to the victim's machine with a forged source address of some
other machine which is trusted by the victim's machine.  It, and the few
packets which follow, are done entirely in the blind -- the bad guys don't
need to see the responses -- and do something like "echo '+ +' >> .rhosts"
on the victim's machine.  In the meantime, they distract the other machine,
the one which is trusted by the victim's machine, by sending it some noise
like TCP packets with intentionally bad sequence numbers.

Did your face turn gray?  It should.  The only quick solution is to make
your routers stop forwarding packets with bad source addresses.  The long
term solution is to make programmers understand the difference between
identification and authentication.

This is not a new problem.  Programmers, as well as the general public, get
this concept wrong with alarming consistency.  For example, it's all too
common for a bank employee or medical clerk in the United States to base
a customer's authentication on their ability to recite the customer's Social
Security Number.  That is to say, to prove your identity, you will be asked
for your SSN; if you can recite it, you must be who you say you are.  SSN's
are, however, merely used for identification, not authentication, and should
never be used for the latter purpose.

Although this specific attack is targeted at Unix systems, it is not unique
to them.  Any system which authenticates hosts or users based on IP addresses
is vulnerable.  I was glad to see that mentioned in the CERT advisory.

By the way, folks using multihomed workstations as routers are pretty much
helpless unless they can turn off IP forwarding and run screend.  I haven't
tried this myself, but it was suggested to me.  If you're reasonably sure
you won't have this problem from inside, then you might rest a little easier.
Of course, if you have a better authentication method, you should use it; then
this whole problem goes away.

	Jim


--