[ On Sunday, May 28, 2000 at 00:25:49 (-0700), Erik Fair wrote: ]
> Subject: Re: inetd.conf defaults
>
> All these protocols suck unless you have IP security in transport 
> mode using ESP (AH is not sufficient). However, for telnet and ftp, 
> at least you have to give a password. The rhosts mechanism is totally 
> insecure in its current incarnation. We could reasonably turn it on 
> again if a hook to test for IPsec/ESP was added as a requirement to 
> accept authentication.

I think your understanding of trusted computing systems when networks
are involved cannot be the same as mine if you say this.

The rhosts mechanism is in fact not all that untrustworthy if the
requisite bits of infrastructure that it uses are correctly configured
and deployed, and provided it's used only within the trusted domain.

In the end if you're running NFS on your local LAN then you MUST trust
your LAN neighbours a *lot* more anyway, especially if you're the one on
the diskless workstation!  ;-)

I won't even try to put remote boot protocols into this equation though....

> False.

No, fortunately it is true.  Utilities using rhosts authentication are
*more* trustworthy than passwords in the clear, especially if you have
light risk from internal attack.  Maybe not trustworthy enough to allow
a non-root user to access root on a LAN-local box (so to avoid typing
the root password over the LAN) though, and maybe not even trustworthy
enough to allow root-to-root access (at least not if you have engineers
on your LAN! ;-).

I.e. the threat of sniffing is much much greater, especially inside a
LAN segment, even a switched one, than is the risk of someone performing
a TCP connection theft attack.  It is much much higher than the risk of
them spoofing DNS and successfully foiling rhosts authentication (and of
course DNS spoofing can be greatly, maybe even completely, mitigated by
putting authoritative nameserver directly onto the target hosts).

What I think you're thinking of are generic TCP vulnerabilities, and in
that case it matters not what authentication mechanism is used to
authorise the connection -- they're all equally vulnerable.

Speaking purely of authentication attacks, telnet (and thus any other
protocol that requires password authentication, such as non-anonymous
ftp) also suffers from all of the problems with fixed passwords too --
eg. guessing attacks (see my PR#10206 for cracklib!).  One-time
passwords are a somewhat better defense, but there's all kinds of
lesser-known issues with them too, ranging from widely deployed broken
implementations and common configuration problems to the fact that you
still have to trust the security of the response caclculator to some
extent too.

> All an attacker has to do to get in via r* is prevent your 
> host from transmitting anything (i.e. crash it or muzzle it with a 
> DoS), and then pretend to be you! This is how Kevin Mitnick attacked 
> Tsutomu Shimomura's machines, totally remotely. No password sniffing 
> or physical access required. (OK, there was some TCP sequence number 
> guessing in there too).

In the cases I'm thinking of that's rather hard to do, especially from
outside the target network for example.  TCP sequence number guessing is
only part of the trick.  You may also have to break into my DNS servers
and force them first to forget their authoritative zones and second to
load your bogus RRs into their caches before they're able to retrieve
the same RRs from some other authoritative server.  Finally you have to
get your packets past my anti-spoof network border filters (and probably
past similar filters on the hosts themselves if you try to come in
through the back door of a multi-homed host).  If I make damn sure that
nobody can spoof source addresses into my network, and if I keep my DNS
servers secure and only point my local resolvers at local secure server
I'll raise the bar on any rhosts or connection-thef attack quite a bit.

Of course if you start not to trust your LAN segment (as I went on to
discuss below) then all those bets are off too!  ;-)

Mind you if you're talking about remote, or semi-remote access then any
protocol running over TCP, short of SSH or SRP of course, is vulnerable
to connection theft and as I show above the attacker doesn't give a hoot
what authentication mechanism you've used.

So in the end the specific threats are much more important to consider
in this situation than the generic risks.

BTW, I'm even going to reserve judgment on IPsec protection for
otherwise bare protocols such as telnet -- I don't think there's been
much (enough) attention focused against it yet by the black-hat
community.  One of the problems that seems could exist is that the
generic hook you suggest for testing for IPsec coverage of a given
connection may not be sufficient -- additional firewall checks may be
necessary too, especially when the target host and the IPsec device are
not one in the same.

> That's easy - replace all your 10base-T hubs (and thinnet) with 
> switches. Can't sniff what you can't see. 8-port 10/100 FDX switches 
> are around $100 now.

If you add one rogue host to that mix then you may have lost all the
security you gained, and then some.  There are at least two known near
skript kiddie level tools available for hacking switched ethernet
networks.  (I don't know of their viability in real life, but in theory
they're very scary propositions -- see "HUNT Project" at
<URL:http://www.cri.cz/kra/>).

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>