-----BEGIN PGP SIGNED MESSAGE----- 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.EDUat_private is sufficient to print an Athena TGT for any Athena realm client. Additional vulnerabilities in a MIT extension to use tripple 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 with 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. An attached paper details how to choose principal names in order to encrypt arbitrary plaintext and how to use this ability to construct tickets for both Kerberos 4 and Kerberos 5. 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. The attached paper discusses mechanisms for mounting such an 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; the paper discusses situations where this is possible. 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. Obtaining Patches ================= The following Kerberos implementations have provided statements on how vendors should obtain patches: MIT: Patches are available for the 1.2.x and 1.3 versions of MIT Kerberos 5. Contact Sam Hartman <hartmansat_private> or Tom Yu <tlyuat_private> for patches. Acknowledgements ================ This description was written by Sam hartman. The attached paper detailing the cryptographic details of the attack was written by Tom Yu. The exploit was written by Ken Raeburn and Sam Hartman. All parties were involved in discovering the vulnerabilities. *) Paper by Tom on weaknesses - ---------------------------------------- ADAPTIVE CHOSEN-PLAINTEXT ATTACKS AGAINST KERBEROS 4 Introduction ============ The Kerberos 4 protocol is vulnerable to a number of adaptive chosen-plaintext attacks. Some of these attacks may be used, indirectly, against Kerberos 5 as well, and an attack exists that can generate arbitrary tickets in any realm that either directly or transitively shares a key with a realm controlled by an adversary. These attacks have their basis in the ability of an adversary to create an Electronic Code Book (ECB) oracle for a block cipher with a fixed unknown key, given: * the ability to choose a single block of a larger plaintext for a victim to encrypt with that key using the block cipher in a chaining mode * the output ciphertext block of the chaining-mode encryption corresponding to the chosen plaintext * prior knowledge of the feedback block that will be XORed with the chosen plaintext block prior to ECB-encryption The existence of this oracle permits the attacker, without knowledge of the key, to construct a ciphertext that will decrypt with a chained block cipher to any desired plaintext (with the possible exception of the first block). This constructed ciphertext can be the entirety of an arbitrary Kerberos 4 ticket. Kerberos 4 is vulnerable to this attack due to the lack of random confounders, the lack of random initialization vectors, and the lack of cryptographically strong integrity checking in its use of block ciphers. Kerberos 5 is somewhat less vulnerable, but a related weakness permits a cross-protocol attack from Kerberos 4 to Kerberos 5 when single-DES is used to encrypt tickets. In addition, these vulnerabilities render any realm that either directly or transitively shares a key with an adversary-controlled realm vulnerable to compromise. Definitions and notation ======================== [ heavily adapted from B. Schneier, _Applied Cryptography_, 2nd ed., John Wiley & Sons, Inc., 1996, chapter 9 ] A ^ B = A XOR B C[n] = nth ciphertext block P[n] = nth plaintext block E(k, x) = x ECB-encrypted with key k D(k, x) = x ECB-decrypted with key k Cipher Block Chaining (CBC) mode is used in the implementation of triple-DES in krb4 that is used in the MIT krb5 release: C[n] = E(k, P[n] ^ C[n-1]) P[n] = D(k, C[n]) ^ C[n-1] Propagating Cipher Block Chaining (PCBC) mode is used for single-DES encryption in krb4: C[n] = E(k, P[n] ^ C[n-1] ^ P[n-1]) P[n] = D(k, C[n]) ^ C[n-1] ^ P[n-1] It is useful to generalize these block cipher chaining modes by considering the block that is to be ECB-encrypted as being a plaintext block XORed with a feedback block: F[n] = nth feedback block (not transmitted) C[n] = E(k, P[n] ^ F[n]) P[n] = D(k, C[n]) ^ F[n] F[0] = initialization vector (IV) for CBC: F[n] = C[n-1] for PCBC: F[n] = C[n-1] ^ P[n-1] There are other, more obscure modes, e.g. Block Chaining (BC) mode: F[n] = F[n-1] ^ C[n-1] but this document will not discuss them further, since the krb4 protocol does not use them. General ECB oracle attack on chained block ciphers ================================================== An ECB oracle for a block cipher can be constructed from a block-chaining mode of that cipher if an attacker has access to the ciphertext block corresponding to a chosen plaintext block of a larger plaintext, under certain conditions. To learn E(k, x) for arbitrary x, note that C[n] = E(k, P[n] ^ F[n]) in the generalized form for chained block ciphers. Let x = P[n] ^ F[n] , and assume that the attacker has prior knowledge of the block F[n] that will be used when the victim encrypts the complete plaintext containing the chosen plaintext block P[n]. The attacker may then manipulate the chosen plaintext block P[n] to produce C[n] = E(k, x) by choosing P[n] = x ^ F[n] , since the XOR operation is its own inverse. The attacker now has an oracle that can ECB-encrypt arbitrary plaintext using the key k, without knowing the key. The complete set of requirements for the attacker to construct this ECB oracle is: * the ability to choose a plaintext block P[n] as part of a (possibly) larger plaintext to be chaining-mode encrypted with the fixed key k * prior knowledge of the feedback block F[n] that will be XORed with P[n] when this chaining-mode encryption occurs * knowledge of the ciphertext block C[n] that results from the chaining-mode encryption In a well-designed cryptosystem, an attacker should have significant difficulty assembling such an oracle, since it should be difficult to determine F[n] ahead of time. If F[n] is known to be constant between two instances of the chaining-mode encryption, an attacker may rather easily construct the ECB oracle. As an example of how to mount this attack, assume that the attacker has access to the output of a black box that produces ciphertext that is encrypted in a chaining mode with a fixed key k. Additionally, assume that the attacker can vary a constrained subset of inputs to the black box such that the only resulting changes in the ciphertext, up to and including C[n], are in C[n] itself, and that the feedback block F[n] associated with C[n] does not change. The ciphertext following C[n] is not important. If the attacker can manipulate the constrained subset of the black box's inputs in a way that completely controls the contents of the plaintext block P[n] that will encrypt to C[n], then the attacker has an ECB oracle for the fixed key k. Note that the attacker does _not_ need to control the entire plaintext that the black box encrypts; it is sufficient to manipulate one aligned block of plaintext. Also, note that the condition of fixed output ciphertext up through C[n] is slightly less restrictive in the general case; the attacker only needs to ensure that F[n] does not vary with manipulation of the constrained subset of inputs to the black box, though this usually implies that the output ciphertext up to C[n] is also fixed. Using an ECB oracle to construct arbitrary ciphertext ===================================================== To construct a complete ciphertext that a chained block cipher will decrypt to a desired plaintext, it is necessary to proceed one block at a time, taking into account the feedback block each time. Since C[n] = E(k, P[n] ^ F[n]) , it is only necessary to take the desired plaintext block P[n], XOR it with the feedback block F[n], and encrypt it using the ECB oracle. The construction of C[0] for a desired P[0] using the ECB oracle is only easily possible if the initialization vector F[0] that will be used for decryption is known. If F[0] is not known, it will be necessary to manipulate P[0] to be encrypted in the chaining mode by k using the unknown value of F[0], which is not in general possible. In general, the attacker will know F[n] for non-zero values of n because F[n] will depend solely on the previously constructed blocks of ciphertext (or, additionally, the previous plaintext block in the case of PCBC). In the specific case of single-DES used in PCBC mode in krb4, F[0] is the key k, and is not known to an attacker, even if the ECB oracle can be obtained. To produce a C[0] that decrypts to a desired value, the attacker must be able to manipulate the P[0] that will be encrypted by k. In the case of triple-DES used in CBC mode used in recent krb4 implementations in the krb5 sources, F[0] is an all-zeros IV, so the ECB oracle can be used to produce a C[0] that decrypts to an arbitrary P[0] even if P[0] cannot be directly manipulated to be encrypted with k in CBC mode by the attacker. Building an ECB oracle using krb4 tickets ========================================= A krb4 ticket is encrypted in the long-term key of the service. The plaintext contents of the ticket are: unsigned char flags namely, HOST_BYTE_ORDER string pname client's name string pinstance client's instance string prealm client's realm 4 bytes paddress client's address 8 bytes session session key 1 byte life ticket lifetime 4 bytes time_sec KDC timestamp string sname service's name string sinstance service's instance <=7 bytes null null pad to 8 byte multiple The fields labeled "string" are NUL-terminated ASCII strings, each limited to 40 characters (including the terminal NUL). The following example of ECB oracle construction assumes that the attacker varies P[1] to obtain the ECB-encryption of a desired plaintext in C[1]. It may be generalized to use manipulation of an arbitrary P[n], though. Assume that the attacker controls a realm "HAX0R.EXAMPLE", and the attacked realm is "VICTIM.EXAMPLE", and that they share a key. Since the realms "HAX0R.EXAMPLE" and "VICTIM.EXAMPLE" share a key, the attacker knows the key for the principal "krbtgt.HAX0R.EXAMPLEat_private" (which has the same key as "krbtgt.VICTIM.EXAMPLEat_private" in krb4). The attacker can fabricate a cross-realm ticket for the client principal "a234567XXXXXXXXat_private" , where "a234567" is a constant string, and "XXXXXXXX" is chosen to produce the ECB encryption of an arbitrary plaintext by the key to be attacked. The service principal of this magic ticket will of course be for the service principal "krbtgt.VICTIM.EXAMPLEat_private" , since it is a cross-realm TGT. The attacker then uses the cross-realm ticket to obtain a service ticket for the key that will be attacked, for example, "krbtgt.VICTIM.EXAMPLEat_private" (for maximum damage). The attacked KDC (which acts as the black box assumed in the section "General ECB oracle attack") encrypts the client principal's name, instance, and realm from the cross-realm TGT with the attacked service's key, thus providing ciphertext corresponding to a partially known plaintext. Note that the session key, timestamp, etc. may not be known to the attacker before encryption, but they do not affect the ciphertext blocks of interest. The fixed string "a234567", appended to the one-byte flags field, becomes the first plaintext block P[0]. This means that chosen plaintext string "XXXXXXXX" is the entirety of the second plaintext block P[1]. C[0] will be a fixed value, given the fixed string, since the flags don't change, the first 7 characters of the principal name don't change, the IV and key don't change, and there is no prepended confounder (unlike in krb5 uses of block-chaining modes). Likewise, F[1] won't change, since it is based on fixed values (C[0], which is additionally XORed with P[0] in PCBC mode). The attacker merely has to change the variable string "XXXXXXXX", which is P[1], to be the result of F[1] XORed with the desired plaintext to be ECB-encrypted. The C[1] in the resulting ticket will then be the ECB encryption of the desired plaintext. The attacker can obtain the initial fixed value of F[1] by performing one pass with the chosen P[0] and discarding C[1]. If any P[1] obtained by XORing F[1] with the desired plaintext contains one NUL character, the value of P[1] will be split between the "pname" and "pinstance" fields, rather than being completely contained within the "pname" field. This is still acceptable. If there are two or more NUL characters in the resulting P[1], the KDC will probably not create a useful ticket, so the previously fixed string P[0] must be permuted to obtain a F[1] value that does not result in an unacceptable number of NUL characters in P[1]. It may also be possible to permute P[0] such that P[1] will not need to contain any "suspicious" characters, e.g. non-alphanumerics, in order to obtain a desired C[1]. Note that almost none of this attack is specific to the particular block-chaining mode (CBC or PCBC), provided that the mode is of the general form described under "Definitions". Note also that it is not necessary to control a cross-realm key with the realm "VICTIM.EXAMPLE"; it is merely sufficient to be able to create or control a large number of principals in "VICTIM.EXAMPLE" and to know their keys. Having control of a cross-realm key merely makes the attack much easier. Even that level of control may not be required, if the attacker has control of a key for a principal whose name is of the correct length to cause the "paddress" field to begin on a block boundary. Then, assuming that the attacker can receive arbitrary UDP packets originating from the attacked KDC and that are addressed to arbitrary IP addresses, the attacker can effectively vary the "paddress" field, by sending from arbitrary source IP addresses, in order to obtain control over 4 bytes of plaintext. Note that this increases the work factor to O(2**32) per ciphertext block, since the immediately following 4 bytes are the first half of the (presumed) random session key, which the attacker can obtain only after the KDC issues the ticket. Obviously, controlling smaller amounts of address space will result in a proportionally increased work factor, but it can still be significantly below O(2**56). The downside to this attack is that the large volume of ticket requests required may be quite noticeable to a KDC administrator. Most of the the "life" field and some of the "time_sec" field are also under the control of an attacker, and can be used as chosen plaintext with which to mount the ECB oracle attack, though this method may be somewhat more difficult, and suffers from the same drawbacks as the address space attack. Constructing an arbitrary krb4 ticket using the ECB oracle ========================================================== Given the ECB oracle, it is possible to construct an arbitrary krb4 ticket, subject to certain conditions. The attacker must usually build up the ciphertext of the fabricated ticket one block at a time, since the feedback blocks are required; there may be optimizations that permit multiple ciphertext blocks to be produced and spliced in at once, but the length constraints inherent in krb4 principal names, in addition to the NUL-terminated string condition, limit these optimizations somewhat. An arbitrary block of ciphertext C[n] corresponding to a chosen plaintext P[n] may be produced as described above in "General ECB oracle attack". Production of the first ciphertext block, C[0], may be difficult if F[0] is not known. This is the case in krb4 single-DES in PCBC mode, since the key is used as the initialization vector F[0]. In the krb4 usage of triple-DES CBC mode, the IV is all zeros, so it is not necessary to force encryption of a chosen P[0] in order to obtain a desired C[0]. Since, in the krb4 usage of single-DES PCBC, C[0] will be constant for a constant P[0], it is sufficient to somehow obtain a C[0] corresponding to the desired P[0]. This may be trivially done by controling a realm with a shared key, since the C[0] may be obtained directly in that case. Consider an attacker who wants to fabricate a ticket for "someluserat_private" . The attacker may simply synthesize a cross-realm ticket for the client "someluat_private" , since the resulting P[0], "\000somelu" ends immediately prior to the terminating NUL of the "somelu" principal name string. Upon using the cross-realm ticket to obtain a service ticket in the "VICTIM.EXAMPLE" realm, the first block of the ticket will be exactly the C[0] required to synthesize the remainder of the ticket, even though F[0] is unknown. Note that fabricating a ticket in this manner for a client whose total length of principal name and instance (including terminating NUL characters) is less than 7 bytes is probably impossible unless the attacker's realm name and the victim's realm name share an initial substring. This constraint is a consequence of the requirement that the client realm name in the ticket must match the issuing realm of the ticket. Without access to a realm with a shared key, it suffices to sniff a C[0] corresponding to a desired P[0] off the network. This may be difficult if the client principal(s) being attacked are careful not to obtain or use krb4 tickets for authentication. There are other ways to obtain the desired initial ciphertext block C[0], as described in later sections. Cross-protocol attack from krb4 to krb5 ======================================= If a service is authenticated with krb5, accepts tickets encrypted with single-DES, and does not necessarily accept krb4 authentication, it is still possible to mount an attack against it using the krb4 ECB oracle if the KDC for the service's realm can issue krb4 tickets for the service. The format of a krb5 single-DES plaintext immediately prior to encryption is concat(confounder, checksum, data, pad) . The confounder is one block of random bytes. The checksum may be CRC-32, MD4, or MD5. None of these checksums is keyed, which is the crucial feature that enables this attack. For des-cbc-md4 and des-cbc-md5, the IV is all zeros. For des-cbc-crc, the IV is the key. The checksum is computed over the entire concatenated plaintext, with the checksum field zeroed out. This frustrates ciphertext generation via chosen-plaintext manipulation if the attacker has no knowledge of the confounder; an adversary will find it very difficult, if not impossible, to create an ECB oracle based on manipulating krb5 tickets. For des-cbc-md4 and des-cbc-md5, an attacker can simply fabricate any desired confounder using the ECB oracle, since the IV is known and constant. For des-cbc-crc, the attack is somewhat more difficult, since the IV is the key and not known to the attacker. For this particular attack, it is necessary to obtain the ciphertext block C[0] corresponding to the desired confounder, possibly by the same method that can be used for the C[0] attack on PCBC krb4, i.e. by forcing the KDC to encrypt an intial P[0] with the attacked key (which also requires control of a realm with a shared key). An easier method for obtaining C[0] for attacking krb5 des-cbc-crc is to sniff, or otherwise acquire, any krb4 ticket encrypted in the attacked key, provided that the first block of plaintext is known. The first ciphertext block of both the krb5 des-cbc-crc encryption and the krb4 PCBC encryption of the same plaintext will be identical, as they both use the same key and an IV equal to the key. Incidentally, if krb524d is running on the attacked KDC, the cross-protocol attack from krb4 to krb5 may be extended back into an attack on single-DES krb4, circumventing the problems of constructing C[0] for the krb4 ticket, especially the difficulties inherent in fabricating a ticket for a client with a short principal name. The attacker acquires C[0] of a krb4 ticket encrypted for the target service, provided that the corresponding P[0] is known. Note that this is trivial if the attacker knows _any_ client principal key in the attacked realm. The attacker can then use this C[0] as the encrypted confounder for a krb5 des-cbc-crc ticket, and proceed to construct a krb5 ticket for that service, complete with correct checksum. Then, the attacker merely submits the fabricated krb5 ticket to krb524d, which converts it into a valid krb4 ticket. This weakness of the single-DES krb5 cryptosystems results largely from the practice of encrypting plaintext checksums. Without knowing the key, an attacker can still fabricate ciphertext that decrypts and appears to have valid integrity. [ S. M. Bellovin, personal communication, 1999 ] This would not be possible if a keyed checksum or a HMAC were used. Note, however, that checksumming of the random confounder along with the data prevents several types of chosen-plaintext cut-and-paste attacks. Attack on transitive closure of trust ===================================== Normally, cross-realm trust in krb4 is not transitive, because the code in the KDC implementation forbids realm-hopping by use of cross-realm tickets. This can be circumvented by an adversary, though. The nature of cross-realm trust in krb4 means that any remote realm, if it can synthesize tickets for services in the local realm, can synthesize tickets for services in any other realm sharing keys with the local realm. Consider a local target realm "VICTIM.EXAMPLE", which shares keys with an attacker's realm "HAX0R.EXAMPLE" and with another target realm "OWNZ0RED.EXAMPLE". The attacker can not only synthesize tickets for clients in "VICTIM.EXAMPLE" for services in "VICTIM.EXAMPLE", but can also synthesize a ticket for an arbitrary client in the "VICTIM.EXAMPLE" realm for the service "krbtgt.OWNZ0RED.EXAMPLEat_private" . This ability to synthesize arbitrary cross-realm tickets between "VICTIM.EXAMPLE" and "OWNZ0RED.EXAMPLE" means that the attacker can synthesize a ticket for a client in "OWNZ0RED.EXAMPLE" for any service in "OWNZ0RED.EXAMPLE" by using the ECB oracle attack against the service key. The attacker may recurse this attack indefinitely, compromising the entire web of trust. Combined with the krb4-to-krb5 cross-protocol attack, the results may be devastating. Conclusions =========== The Kerberos 4 protocol has weaknesses in its uses of cryptography that permit an attacker to mount an adaptive chosen-plaintext attack to obtain an ECB oracle. This oracle can then be used to fabricate arbitrary tickets in any realm that shares a key with one under the attacker's control. This attack has some limitations, but the combination of cross-protocol attack to the Kerberos 5 protocol with the related cross-protocol attack back to Kerberos 4 permits the attacker to circumvent most of these limitations. Additionally, these fabricated tickets permit the attacker to extend the attack to all transitively trusted realms, in spite of the normal lack of cross-realm trust transitivity in the Kerberos 4 protocol. Combined, these attacks can have a profound detrimental effect on a set of realms that trust each other. -----BEGIN PGP SIGNATURE----- Version: Hush 2.2 (Java) Note: This signature can be verified at https://www.hushtools.com/verify wl4EARECAB4FAj50Wj8XHGhhY2s0bGlmZUBodXNobWFpbC5jb20ACgkQgSjHzuae7+ph yACfU+yU8p6EJlQC3wUBkRWREB+HbqwAn2jFXGuKPDXwlqFtq6WnOMHYwjLY =BRLH -----END PGP SIGNATURE----- Concerned about your privacy? Follow this link to get FREE encrypted email: https://www.hushmail.com/?l=2 Big $$$ to be made with the HushMail Affiliate Program: https://www.hushmail.com/about.php?subloc=affiliate&l=427 _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
This archive was generated by hypermail 2b30 : Sat Mar 15 2003 - 23:39:07 PST