[5027] in Kerberos
Re: Kerberos Limitations in FAQ
daemon@ATHENA.MIT.EDU (Jonathan I. Kamens)
Sun Apr 23 18:42:53 1995
To: kerberos@MIT.EDU
Date: 23 Apr 1995 22:39:27 GMT
From: jik@cam.ov.com (Jonathan I. Kamens)
In article <3n5u7s$7il@lynx.unm.edu>, datkins@spam.unm.edu (Drexel Atkinson) writes:
|> The discussion in part 2.1 of the FAQ indicate a spoofing mechanism which
|> I'm not sure i understand entirely. If a user walks up to a public workstation
|> and attempts a login as a non-existent user how can he run any other program,
|> as suggested in the faq. He has not logged in yet or completed the login.
|> I'm sure i'm missing something here, but we're not running kerberos yet....just
|> investigating its pros and cons.
|> Could someone reword that description with a little more detail...
When the FAQ says that the attacker "can arrange for another program to
deliver a fake response to login," it does not mean that the attacker runs
that program on the machine he's trying to attack; he has to have the program
running on a *separate* machine.
Suppse your KDC's host name is "KDC", and the client that the attacker is
trying to break into is "CLIENT1". Suppose, further, that the attacker has
the ability to monitor either the subnet that KDC is on or the subnet that
CLIENT1 is on, and to send packets to CLIENT1. Finally, suppose that the
attacker has a program (call it SPOOF-KDC) that knows how to generate fake
encrypted TGT packets that will look authentic to CLIENT1's login program
unless they are verified against a known key as described in the FAQ.
Now, here's what the attacker does to break into CLIENT1.
* Start up a program (we'll call it WATCHER) that is watching either KDC's or
CLIENT1's subnet for packets from CLIENT1 to KDC requesting an initial ticket.
* Start up another program to bombard KDC with requests, so that its response
time is degraded.
* Connect to CLIENT1 (or walk up to its console) and specify a non-existent
user at the "login:" prompt.
* As soon as WATCHER detects the request from CLIENT1 to the KDC, it runs
SPOOF-KDC to send a fake TGT, encrypted in the password known to the attacker,
back to CLIENT1. SPOOF-KDC's packet gets to CLIENT1 faster than KDC's
response does, because KDC is being bombarded with fake requests so it's
responding slowly.
* The attacker types the known password and CLIENT1 lets him log in.
It doesn't have to happen exactly that way, but that's the basic idea.
|> also, has
|> anyone found a way around it for a public workstation. If we go with kerberos,
|> we will certainly have a number of public workstations so it kinda defeats the
|> purpose of kerberos if it can be easily spoofed.
The reason this is not considered a significant problem is that public
workstations should not have any private data on them and should not be
trusted by other machines on the network. If your public workstations are not
trusted and don't contain private data, then it doesn't matter if someone
breaks into one of them using a spoofing attack -- they still don't have real,
valid Kerberos tickets for the local realm, so they can't authenticate to any
Kerberized services in order to gain access to private data.
If that answer isn't acceptable to you, then you're going to have to install
keytabs on all of your machines, so that login can verify initial tickets as
described in the FAQ.
--
Jonathan Kamens | OpenVision Technologies, Inc. | jik@cam.ov.com
