__________________________________________________________
The U.S. Department of Energy
Computer Incident Advisory Capability
___ __ __ _ ___
/ | /_\ /
\___ __|__ / \ \___
__________________________________________________________
INFORMATION BULLETIN
Cryptographic weaknesses in Kerberos v4 protocol
[MIT krb5 Security Advisory 2003-004]
March 18, 2003 19:00 GMT Number N-057
______________________________________________________________________________
PROBLEM: 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.
PLATFORM: Kerberos v4
DAMAGE: The more serious of these vulnerabilities could lead to
root-level compromise of a Key Distribution Center (KDC),
along with compromise of any hosts that rely on authentication
provided by that KDC.
SOLUTION: Apply available patch or workaround.
______________________________________________________________________________
VULNERABILITY The risk is HIGH. These attacks can subvert a site's entire
ASSESSMENT: Kerberos authentication infrastructure.
______________________________________________________________________________
LINKS:
CIAC BULLETIN: http://www.ciac.org/ciac/bulletins/n-057.shtml
ORIGINAL BULLETIN: http://web.mit.edu/kerberos/www/advisories
/MITKRB5-SA-2003-004-krb4.txt
PATCHES:
http://web.mit.edu/kerberos/www/advisories
/2003-004-krb4_patchkit.tar.gz
______________________________________________________________________________
[***** Start MIT krb5 Security Advisory 2003-004 *****]
-----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@mit.edu>, or
Marshall Vale <mjv@mit.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@ATHENA.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-----
[***** End MIT krb5 Security Advisory 2003-004 *****]
_______________________________________________________________________________
CIAC wishes to acknowledge the contributions of MIT for the
information contained in this bulletin.
_______________________________________________________________________________
CIAC, the Computer Incident Advisory Capability, is the computer
security incident response team for the U.S. Department of Energy
(DOE) and the emergency backup response team for the National
Institutes of Health (NIH). CIAC is located at the Lawrence Livermore
National Laboratory in Livermore, California. CIAC is also a founding
member of FIRST, the Forum of Incident Response and Security Teams, a
global organization established to foster cooperation and coordination
among computer security teams worldwide.
CIAC services are available to DOE, DOE contractors, and the NIH. CIAC
can be contacted at:
Voice: +1 925-422-8193 (7x24)
FAX: +1 925-423-8002
STU-III: +1 925-423-2604
E-mail: ciac@ciac.org
Previous CIAC notices, anti-virus software, and other information are
available from the CIAC Computer Security Archive.
World Wide Web: http://www.ciac.org/
Anonymous FTP: ftp.ciac.org
PLEASE NOTE: Many users outside of the DOE, ESnet, and NIH computing
communities receive CIAC bulletins. If you are not part of these
communities, please contact your agency's response team to report
incidents. Your agency's team will coordinate with CIAC. The Forum of
Incident Response and Security Teams (FIRST) is a world-wide
organization. A list of FIRST member organizations and their
constituencies can be obtained via WWW at http://www.first.org/.
This document was prepared as an account of work sponsored by an
agency of the United States Government. Neither the United States
Government nor the University of California nor any of their
employees, makes any warranty, express or implied, or assumes any
legal liability or responsibility for the accuracy, completeness, or
usefulness of any information, apparatus, product, or process
disclosed, or represents that its use would not infringe privately
owned rights. Reference herein to any specific commercial products,
process, or service by trade name, trademark, manufacturer, or
otherwise, does not necessarily constitute or imply its endorsement,
recommendation or favoring by the United States Government or the
University of California. The views and opinions of authors expressed
herein do not necessarily state or reflect those of the United States
Government or the University of California, and shall not be used for
advertising or product endorsement purposes.
LAST 10 CIAC BULLETINS ISSUED (Previous bulletins available from CIAC)
N-047: Microsoft Windows ME Help and Support Center Vulnerability
N-048: SendMail MTA Vulnerability
N-049: Snort RPC Preprocessing Vulnerability
N-050: Sun sendmail(1M) ".forward" Constructs Vulnerability
N-051: Red Hat Updated OpenSSL Packages Fix Timing Attack
N-052: PeopleSoft PeopleTools Remote Command Execution Vulnerability
N-053: Increased Activity Targeting Microsoft Windows Shares
N-054: Unchecked Buffer in Windows Component Could Cause Web Server Compromise
N-055: Samba smbd Buffer Overrun Vulnerability
N-056: Red Hat Updated 2.4 Kernel Fix for ptrace Vulnerability
TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2024 AOH
