[2326] in Kerberos
Local password validation (was: kerberizing xlock)
daemon@ATHENA.MIT.EDU (Barry Jaspan)
Sun Nov 1 14:45:38 1992
Date: Sun, 1 Nov 92 14:23:15 -0500
From: "Barry Jaspan" <bjaspan@Athena.MIT.EDU>
To: Greg Wohletz <greg@duke.cs.unlv.edu>
Cc: Barry Jaspan <bjaspan@Athena.MIT.EDU>, hendrick@neptune.ctron.com,
In-Reply-To: [2325]
(Disclaimer: I am fairly certain that what I say here is correct. It
certainly possible, however, that I've made a mistake.)
Date: Fri, 30 Oct 92 20:57:58 -0800
From: Greg Wohletz <greg@duke.cs.unlv.edu>
>If I can create a fake tgt response from Kerberos, then presumably I
>can create a fake service ticket response from Kerberos, *and* I can
>fake a response from the verification service you propose.
Um, doesn't that require you to know the verification processes password?
No, it does not. Notice that I said "I can fake a response from the
verification service." They key word is FAKE. Perhaps working
through the attack step by step will make it more clear.
Suppose that I can trying to break into host A as user U. I have
already described how an attacker can trick the login program into
thinking it received a valid tgt when it did not; see question 2.1 in
the Kerberos Users' FAQ. Therefore, suppose that login already posses
an *invalid* tgt for U to which I know the key (and which would
not be accepted by the TGS, because the key being used is not really
U's key, which I do not know).
In your proposed scheme, login would acquire a service ticket for
{U,V}, where V is the verification service. As an attacker, I know
that login is going to do this. Also, since I provided the (fake) tgt
it is going to use, I know the session key it will use. Therefore,
when login sends its request to the TGS, I can reply with a fake
service ticket for {U,V} encrypted in any key of my choosing.
Eventually the service ticket request will get to the TGS and generate
an error (because the tgt is invalid), but by then login will no
longer be listening for the response.
So now login has what it thinks is a service ticket for V, but (a) I
know the key, because I created the ticket, and (b) of course the
ticket is invalid and V will not honor it. Login sends it off to V
and requests mutual authentication. Before V responds with an error,
I produce the correct mutual authentication response (which I can,
because I know the session key in the ticket I created). Since the
mutual authentication succeeded, login is tricked into thinking I am
the user U.
In summary, here is a timeline showing the attack:
1. login sends tgt request {U,TGS} to KDC
2. attacker responds with {U,TGS}_fake
3. KDC responds with error, login is no longer listening
4. attacker enters correct fake password for {U,TGS}_fake
5. login sends service ticket {U,V} reques to KDC
6. attacker responds with {U,V}_fake using session key from {U,TGS}_fake
7. KDC responds with error, login is no longer listening
8. login's decryption succeeds
9. login sends mutual auth request to V
10. attacker responds to mutual auth request
11. V responds with error, login is no longer listening
12. login is tricked
Do you detect a pattern here? :-)
The moral of the story is simple: Once I know "the user's password"
and "the TGS password" I can break all Kerberos-based authentication.
However, unless login has a local copy of a shared secret with
Kerberos, I can lie to it about "the user's password" and "the TGS
password"; it has no choice but to believe me.
Does this mean that Kerberos provides no security and is therefore
useless? **NO**, it does not. At no point in the attack does the
attacker have credentials that will allow him to trick a real
Kerberos-authenticated service. Thus, he has convinced host A that he
is user U, but is still unable to convince any Kerberos authenticated
network service that he is user U. Host A must be assumed to be
insecure anyway, however, since it had no shared secret with Kerberos
(either an /etc/srvtab, or if you are really paranoid a ROM key or the
like).
Furthermore, this kind of attack does not allow an attacker to fake
mutual authentication from a service like V with a *real* user with a
valid tgt; the attack above assumed the attacker knew the session key
inside the user's tgt, which the attacker wouldn't know for a valid
user.
KERBEROS IS A NETWORK AUTHENTICATION SYSTEM, NOT A PASSWORD VALIDATION
SYSTEM. If you use it as the latter, you must exercise extreme
caution. In particular, using Kerberos for screensaver/keyboard lock
programs is a tricky business.
Barry Jaspan
