Kerberos password authentication issues

[Dug Song <dugsong () MONKEY ORG>]

Kerberos password authentication issues
---------------------------------------

Kerberized programs that perform password authentication may be
vulnerable to an attacker with the ability to spoof KDC responses
(either as a race condition on the LAN, or via DNS cache poisoning,
spoofed ICMP redirects or router advertisments, etc.).

This is an old, well-known issue among Kerberos developers, but with
more application developers adding Kerberos password authentication to
their software (esp. with the advent of such support in Windows 2000),
some review may be necessary.

Standard (undocumented) procedure for Kerberos password authentication
involves the acquisition of a Kerberos ticket-granting ticket (TGT)
using the user's password, verification of the TGT via acquisition of
a service ticket for the host itself, and verification of the service
ticket using the host's key (known only to the host and the real KDC).

However, many programs still allow login in certain exceptional cases,
as described in the BSD klogin.c:

         /*
          * If we got a TGT, get a local "rcmd" ticket and check it so
          * as to ensure that we are not talking to a bogus Kerberos server.
          *
          * There are 2 cases where we still allow a login:
          *      1: the VERIFY_SERVICE doesn't exist in the KDC
          *      2: local host has no srvtab, as (hopefully) indicated by a
          *         return value of RD_AP_UNDEC from krb_rd_req().
          */

Such cases are commonplace in large Kerberos realms with poorly
centralized administrative control, where participating hosts don't
always get keys, much less keytabs installed containing them.

The correct, arguably draconian behaviour is to simply disallow login
for these cases instead (as OpenBSD does). Programs without access to
the host's keytab, however, will always be vulnerable to such an
attack, as they have no way to verify the validity of a KDC reply.

Microsoft Kerberos v5 domain login in Windows 2000 is not vulnerable
to this attack, as it requires the recovery of authorization data in
the decrypted service ticket acquired with the TGT.

Demonstration code to perform Kerberos v4, v5, and AFS KDC AS spoofing:

        http://www.monkey.org/~dugsong/kdcspoof.tar.gz

-d.

---
http://www.monkey.org/~dugsong/