Vulnerability

    Kerberos

Affected

    Kerberos

Description

    Dug  Song  found  following.   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.

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

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

Solution

    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.