Message-ID: <ldv65qi2yl2.fsf@cathode-dark-space.mit.edu>
Date: Mon, 17 Mar 2003 03:20:57 -0500
From: Tom Yu <tlyu@....EDU>
To: kerberos-announce@....edu
Cc: bugtraq@...urityfocus.com
Subject: MITKRB5-SA-2003-004: Cryptographic weaknesses in Kerberos v4
 protocol


-----BEGIN PGP SIGNED MESSAGE-----

                 MIT krb5 Security Advisory 2003-004

2003-03-17

Topic: Cryptographic weaknesses in Kerberos v4 protocol

Severity: CRITICAL

SUMMARY
=======

A cryptographic weakness in version 4 of the Kerberos protocol allows
an attacker to use a chosen-plaintext attack to impersonate any
principal in a realm.  Additional cryptographic weaknesses in the krb4
implementation included in the MIT krb5 distribution permit the use of
cut-and-paste attacks to fabricate krb4 tickets for unauthorized
client principals if triple-DES keys are used to key krb4 services.
These attacks can subvert a site's entire Kerberos authentication
infrastructure.

Kerberos version 5 does not contain this cryptographic vulnerability.
Sites are not vulnerable if they have Kerberos v4 completely disabled,
including the disabling of any krb5 to krb4 translation services.

IMPACT
======

* An attacker controlling a krb4 shared cross-realm key can
  impersonate any principal in the remote realm to any service in the
  remote realm.  This can lead to root-level compromise of a KDC,
  along with compromise of any hosts that rely on authentication
  provided by that KDC.

* This attack may be performed against cross-realm principals, thus
  allowing an attacker to hop realms and compromise any realm that
  transitively shares a cross-realm key with the attacker's local
  realm.

* Related, but more difficult attacks may be possible without
  requiring the control of a shared cross-realm key.  At the very
  least, an attacker capable of creating arbitrary principal names in
  the target realm may be able to perform the attack.

* An attacker may impersonate any principal to a service keyed with
  triple-DES krb4 keys, given the ability to capture network traffic
  containing tickets for the target client principal.

* A leak has occurred of an unpublished paper containing enough
  details about the vulnerability that an attacker familiar with the
  krb4 protocol can easily construct an exploit.  No exploit is known
  to be circulating at this time, though.

AFFECTED SOFTWARE
=================

* These are protocol vulnerabilities; ALL implementations of
  vulnerable functionality are vulnerable.

* All implementations of the Kerberos version 4 Key Distribution
  Center that allow cross-realm authentication are vulnerable.

* All implementations of the Kerberos version 5 Key Distribution
  Center that also implement a KDC for the Kerberos version 4 protocol
  and use the same keys for version 4 and version 5 are vulnerable.

* MIT implementations of krb5 that include support for triple-DES keys
  in krb4 are vulnerable.

FIX
===

* These are PROTOCOL vulnerabilities; fixes inherently involve
  restricting the functionality of the protocol.

* If you are using the implementation of krb4 contained in the MIT
  krb5, apply the patch kit, which is available at

  http://web.mit.edu/kerberos/www/advisories/2003-004-krb4_patchkit.tar.gz

  The detached PGP signature of the patch kit is available at

  http://web.mit.edu/kerberos/www/advisories/2003-004-krb4_patchkit.sig

* Release 1.3 of MIT krb5 will include a fix.  The fix has also been
  committed to our development source tree.

* If you are running MIT release krb5-1.2.6 or later, and you are
  unable to patch your production code, setting the DISALLOW_ALL_TIX
  or the DISALLOW_SVR attributes on all cross-realm principals should
  disable cross-realm authentication without losing key information.
  This will, of course, cause loss of krb5 cross-realm functionality.
  Note that the functionality of these principal attributes has not
  been extensively tested.

* If using the Kerberos v4 implementation contained in MIT krb5, and
  you are unable to patch your production systems, cease use of
  triple-DES keys for Kerberos v4 services.

* If using a different implementation of krb4, disable all krb4
  cross-realm functionality, both in KDC implementations and in any
  krb524d implementations.

* A possible workaround is to randomize all cross-realm keys.  This
  should be considered to be a last resort, as re-establishing
  cross-realm keys can be time-consuming, and krb5 cross-realm
  functionality will be lost.

* The following text describes the patch kit for the MIT krb5
  implementation.

PATCH KIT DESCRIPTION
=====================

** FLAG DAY REQUIRED **

One of the things we decided to do (and must do for security reasons)
was drop support for the 3DES krb4 TGTs.  Unfortunately the current
code will only accept 3DES TGTs if it issues 3DES TGTs.  Since the new
code issues only DES TGTs, the old code will not understand its v4
TGTs if the site has a 3DES key available for the krbtgt principal.
The new code will understand and accept both DES and 3DES v4 TGTs.

So, the easiest upgrade option is to deploy the code on all KDCs at
once, being sure to deploy it on the master KDC last.  Under this
scenario, a brief window exists where slaves may be able to issue
tickets that the master will not understand.  However, the slaves will
understand tickets issued by the master throughout the upgrade.

An alternate and more annoying upgrade strategy exists.  At least one
max TGT life time before the upgrade, the TGT key can be changed to be
a single-des key.  Since we support adding a new TGT key while
preserving the old one, this does not create an interruption in
service.  Since no 3DES key is available then both the old and new
code will issue and accept DES v4 TGTs.  After the upgrade, the TGT
key can again be rekeyed to add 3DES keys.  This does require two TGT
key changes and creates a window where DES is used for the v5 TGT, but
creates no window in which slaves will issue TGTs the master cannot
accept.

* What the patch does
=====================

1) Kerberos 4 cross-realm authentication is disabled by default.  A
   "-X" switch is added to both krb524d and krb5kdc to enable v4
   cross-realm.  This switch logs a note that a security hole has been
   opened in the KDC log.  We said while designing the patch, that we
   were going to try to allow per-realm configuration; because of a
   design problem in the kadm5 library, we could not do this without
   bumping the ABI version of that library.  We are unwilling to bump
   an ABI version in a security patch release to get that feature, so
   the configuration of v4 cross-realm is a global switch.

2) Code responsible for v5 TGTs has been changed to require that the
   enctype of the ticket service key be the same as the enctype that
   would currently be issued for that kvno.  This means that even if a
   service has multiple keys, you cannot use a weak key to fake the
   KDC into accepting tickets for that service.  If you have a non-DES
   TGT key, this separates keys used for v4 and v5.  We actually relax
   this requirement for cross-realm TGT keys (which in the new code
   are only used for v5) because we cannot guarantee other Kerberos
   implementations will choose keys the same way.

3) We no longer issue 3DES v4 tickets either in the KDC or krb524d.
   We add code to accept either DES or 3DES tickets for v4.  None of
   the attacks discovered so far can be implemented given a KDC that
   accepts but does not issue 3DES tickets, so we believe that leaving
   this functionality in as compatibility for a version or two is
   reasonable.  Note however that the attacks described do allow
   successful attackers to print future tickets, so sites probably
   want to rekey important keys after installing this update.  Note
   also that even if issuance of 3DES v4 tickets has been disabled,
   outstanding tickets may be used to perform the 3DES cut-and-paste
   attack.

REFERENCES
==========

This announcement and related security advisories may be found on the
MIT Kerberos security advisory page at:

        http://web.mit.edu/kerberos/www/advisories/index.html

The main MIT Kerberos web page is at:

        http://web.mit.edu/kerberos/www/index.html

[note that these CERT Vulnerability Notes have not yet been published]

CERT VU#623217

        http://www.kb.cert.org/vuls/id/623217

CERT VU#442569

        http://www.kb.cert.org/vuls/id/442569

ACKNOWLEDGMENTS
===============

This advisory was written by Sam Hartman and Tom Yu.  Ken Raeburn
participated in the analysis of the cryptographic vulnerabilities.

Steve Bellovin provided some hints that led us to discover this
vulnerability.

Sam Hartman developed the patch kit for MIT krb5 implementations.

CONTACT
=======

For more information, contact Sam Hartman <hartmans@....edu>, or
Marshall Vale <mjv@....edu>.

DETAILS
=======

* Abstract
==========

Several cryptographic vulnerabilities exist in the basic Kerberos
Version 4 protocol that could allow an attacker to impersonate any
user in a Kerberos realm and gain any privilege authorized through
that Kerberos realm.  Knowledge of the key shared between two realms
for Kerberos 4 cross-realm authentication or the ability to create
arbitrary principals in a realm is sufficient to print any ticket in
the realm.  As an example, knowing krbtgt.ZONE.MIT.EDU@...ENA.MIT.EDU
is sufficient to print an Athena TGT for any Athena realm client.
Additional vulnerabilities in a MIT extension to use triple DES keys
for Kerberos 4 tickets may allow attackers who can passively observer
the network to construct tickets for some users if certain alignment
constraints are met.

The Kerberos 5 protocol is not vulnerable to this issue.  However,
implementations that implement both Kerberos 4 and Kerberos 5 tend to
use the same keys for both protocols.  As a result, the Kerberos 4
vulnerabilities can be used to compromise Kerberos 5 services at sites
using these implementations.

* Brief Problem Description
===========================

Kerberos version 4 tickets include neither a cryptographic hash of the
encrypted data, random padding, nor a random initial vector.  As such,
if an attacker can cause the right text to be encrypted in a Kerberos
service key, then the attacker can fabricate a ticket.  Normally an
attacker does not control much of the text in the ticket so this
cryptographic weakness is hard to exploit.

The initial portion of a Kerberos 4 ticket is a one-byte flags field
(either 0 or 1) followed by the client name.  Since all of this
initial text is constant, the beginning of a ticket for a given
client/service will be the same.  An attacker thus knows the
encryption of the initial plaintext in the service key.  If an
attacker can control client principals whose names he chooses, then he
can get the encryption of these plaintext values in the service key.

As a result of concerns about single DES weaknesses, MIT implemented
support for Kerberos 4 tickets encrypted in triple DES service keys.
This support shares all the cryptographic weaknesses of single DES
Kerberos 4.  In addition, since it uses CBC mode rather than PCBC
mode, it introduces new weaknesses not found in other Kerberos 4
implementations.  When certain alignment constraints are met, it is
possible to splice two tickets together, allowing an attacker to get a
ticket with a known session key for a client without knowing that
client's long term key.  This attack does require sniffing a ticket
for that client.

We do not believe the password changing service is vulnerable to the
single DES attacks as the KDC will never issue password changing
tickets in an appl request.  It is probably vulnerable to the triple
DES splicing attacks.

* Specific Vulnerabilities
==========================

1) ECB Oracle for Single DES

    By controlling principals of an attackers choice, an attacker can
    encrypt arbitrary plaintext in a single DES service key.

2) ECB Oracle for Triple DES

    By controlling principals of an an attacker's choice, an attacker
    can encrypt arbitrary plaintext in a triple DES service key.

3) PCBC First Block

    It turns out that being able to encrypt arbitrary plaintext is not
    quite enough to construct a ticket for a single DES service key.
    You also need to be able to construct the first block of the
    ticket; you don't know what plaintext to use because the IV for
    the first block is the long-term service key.  However since the
    only thing in the first block of the ticket is the first seven
    bytes of the client, controlling a principal with the same first
    seven bytes as the principal being attacked is sufficient to get
    the first block.  As a practical matter, principals whose
    principal and instance components fit within six bytes (including
    trailing nulls) may be harder to attack.

4) Cross Realm

    If realms A and B share a cross-realm key and the attacker knows
    that key or can get arbitrary plaintext encrypted in that key,
    then the attacker may get A to issue tickets for any principal
    claiming to be in realm B and vice versa.  This is sufficient to
    meet conditions of vulnerabilities (1) and (2) above and to
    encrypt arbitrary plaintext in the service keys of realm A and B.

5) Kerberos 4 Ticket Printing

    The conditions of (2) above are sufficient to print arbitrary
    tickets in a triple DES service key.  The conditions of (1) and
    (3) are sufficient to print any ticket in a single DES service
    key.

6) Kerberos 5 Ticket Printing

    The conditions of (1) above are sufficient to construct a
    des-cbc-md4 or des-cbc-md5 Kerberos 5 ticket if the KDC uses the
    same DES key for v4 and v5.  While the Kerberos 5 ticket does have
    a confounder and checksum, the checksum is not keyed and thus the
    confounder and checksum can be fabricated by an attacker.  We
    believe that des-cbc-crc is safe unless you can contain a
    ciphertext block and a corresponding plaintext block.  However,
    most Kerberos implementations will allow des-cbc-md5 to be used
    even if des-cbc-crc is normally used.  We are not aware of any
    vulnerabilities in des3-hmac-sha1-kd or rc4-hmac-md5.

7) Ticket Splicing Attack

    A Kerberos 4 ticket contains an eight-byte session key.  If client
    principal names are chosen carefully then this session key will
    line up with a DES block boundary.  For triple DES service keys
    this creates an opportunity for an attack.  Consider the case
    where an attacker has obtained a ticket t1 with a known session
    key K and has sniffed a ticket t2 with unknown session key for the
    same service.  The attacker can create a new valid ticket t2' by
    replacing the part of t2 starting with the session key block with
    the session key from t1.  This new ticket will have a session key
    K XOR-ed with the ciphertext blocks proceeding the session key in
    t1 and t2.  In other words, if triple DES service keys are used,
    client principals with the wrong name lengths are inherently
    vulnerable to sniffing.

8) Realm Hopping

    Kerberos 4 does not normally support multi-hop cross-realm
    authentication.  However cross-realm tickets are just normal
    service keys; points (1), (2) and (3) are sufficient to satisfy
    the conditions of point (4) for a service key.  That is, an
    attacker can hop through realms, exploiting these vulnerabilities
    against any realm that is in the transitive closure of the initial
    realm.  Anyone who shares keys with ATHENA.MIT.EDU now trusts
    ZONE.MIT.EDU.

9) Krb 524 Does Not Help

    Traditionally realms desiring higher security but still wishing to
    have some Kerberos 4 services have disabled KDC support for V4 and
    used krb524d to issue only the services that are needed.  These
    vulnerabilities work as well against any service key that the
    krb524d knows as they do against service keys in a v4 KDC.  Of
    course a fabricated krb5 ticket can be converted to Kerberos 4
    using krb524d.

* Potential Solutions
=====================

1) V4 Cross Realm Considered Harmful

    Kerberos implementations should gain an option to disable Kerberos
    4 cross-realm authentication both in the KDC and in any
    implementations of the krb524 protocol.  This configuration should
    be the default.

2) Application Migration

    Application vendors and sites should migrate from Kerberos version
    4 to Kerberos version 5.  The OpenAFS community has introduced
    features that allow Kerberos 5 to be used for AFS in OpenAFS
    1.2.8.  Patches are available to add Kerberos 5 support to
    OpenSSH.  Several other implementations of the SSH protocol also
    support Kerberos 5.  Applications such as IMAP, POP and LDAP
    already support Kerberos 5.

3) TGT Key Separation

    One motivation for the V4 triple DES support is that if a single
    DES key exists for the TGT principal then an attacker can attack
    that key both for v4 and v5 tickets. Kerberos implementations
    should gain support for a DES TGT key that is used for v4 requests
    but not v5 requests.

4) Remove Triple DES Kerberos 4 Support

    The cut and paste attack is a critical failure in MIT's attempt at
    Kerberos 4 Triple DES.  Even without cross-realm authentication,
    this can be exploited in real-world situations.  As such the
    support for 3DES service keys should be disabled.

REVISION HISTORY
================

2003-03-15      A draft version of this text was leaked to the
                full-disclosure list by unknown persons.

2003-03-17      original release
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (SunOS)

iQCVAwUBPnWBm6bDgE/zdoE9AQEqywP/djVs+A4aTwJUTXzUHno5kGz1qEEzeF6v
Uda7/NZyswe7Prc4J8vP9NEUSb/aETLcWuUmSmzViy0yCl4LwiVRPwtQNnTkjHbb
aWp1xqbEjGmXlEpsf2y5vylbGBC0fBImf38UD8mw0qmjByLJ9+MQGUX0ggIgN72H
GtnGXq1m+Jw=
=ws8J
-----END PGP SIGNATURE-----

Powered by blists - more mailing lists