Home » Security Bloggers Network » Technical Analysis of CVE-2022-33679 and CVE-2022-33647 Kerberos Vulnerabilities

Technical Analysis of CVE-2022-33679 and CVE-2022-33647 Kerberos Vulnerabilities

by Dor Segal on October 31, 2022

Written by Yoav Iellin and Dor Segal, Researchers at Silverfort

Microsoft’s September 2022 Patch Tuesday included two high-risk elevation of privilege vulnerabilities in Kerberos, that were discovered by Google Project Zero. The two vulnerabilities take advantage of the ability to force Kerberos do downgrade its encoding from the default AES encryption to the historic MD4-RC4. Once the encryption is downgraded the two vulnerabilities come into play and enable an attacker to abuse weaknesses in the MD4-RC4 encryption.

The first one, CVE-2022-33979, allows an attacker to obtain an authenticated session on behalf of the victim which can lead to arbitrary code execution. The second one, CVE-2022-33647, allows an attacker that has already succeeded in performing a Man-in-the-Middle attack to issue any Kerberos service tickets on behalf of the target user, thus gaining the same privileges as the user.

It’s important to note that while both vulnerabilities target weaknesses in the legacy MD4-RC4 encryption, each one abuses a different weakness, resulting with different prerequisites and attack scenarios.

This article includes a detailed technical analysis and explanation on both CVE-2022-33979 and CVE-2022-33647.

Sponsorships Available

CVE-2022-33679 – Vulnerability Analysis

The vulnerability CVE-2022-33679, for which a proof of concept was recently released, resides in how Kerberos encrypts its session key and is made possible by Kerberos’ use if the historic RC4-MD4 encryption type. The attack consists of two parts A) requesting new TGT ticket using the RC4-MD4 etype followed by B) a byte by byte breaking of the keystream.

Exploitation process:

Obtain the TGT ticket by send AS-REQ packet to the KDC server. the request must ask for the RC4-MD4 encryption type. In order for the attack to succeed, the two following requirements must be met:
1. Explicitly downgrade Kerberos the encryption from its default AES ot the weaker RC4-MD4. This makes the attack possible because its key is only 8 bytes with no IV or salt.
2. The user’s object “Do not require Kerberos preauthentication” flag enabled. This enables to obtain a TGT with an encrypted session key without the need to know the user’s password. Pre authentication is a mechanism where the client encrypts the current timestamp with the entered password and sends it to the KDC where it validates the password’s integrity before generating a session key and a TGT. Because of the “Do not require Kerberos preauthentication” flag the KDC can be targeted directly and does not require any special attacking technique such as Man In The Middle.
After the attacker successfully obtains an encrypted ticket, the AS-REP packet consists of an encrypted TGT session key which is 40bit long. Using the historic RC4-MD4 encryption type, the attacker can leverage its knowledge of the fixed start of the encrypted packet to extract 45 bytes of the key stream.
Now the attacker can use this keystream to re-encrypt and request a TGT ticket from the KDC with a custom-made pre-authentication that will be used to verify wether the key stream is correct and break the rest of the following 40bit TGT session key byte by byte. This is done by abusing two weaknesses in the ASN.1 protocol used for Kerberos encoding, to leverage the attacker’s limited control of the pre authentication field size:
1. The KDC parser ignores NUL terminated strings at the end of the object. This enables us to add a NUL character at the end of the KerberosTime object. This will work for a single byte guessing, but we still need to guess additional four ones.
2. The KDC parser does not validate encoded lengths’ length. ASN.1 string lengths is represented by 1-4 bytes and the KDC ASN.1 parser doesn’t enforce the shortest way. Therefore, we can represent our timestamp string length with a size of 1-4 bytes as we wish. It means we can enlarge even further the length of the plain text and push the NUL byte to the next position and guess the next byte of the keystream.
Lastly, the attacker can re-encrypt the timestamp and validate each guess by sending an AS-REQ with encrypted pre authentication and will receive an error if the encrypted preauth date is incorrect. In case the pre authentication succeeded, the attacker is able to discover another byte from the keystream as there are up to 256 guess options for each byte. Repeating this process allows obtaining all of the required key stream bytes to decrypt the session key stored in the original ticket.

The obtained session key gives the attacker the ability to request a ticket to any SPN on behalf of the targeted user.

*Flow of breaking the first byte of the AS-REQ session key using CVE-2022-22679. Should be followed by remaining bytes*

*Continued attack flow, breaking last byte and obtaining new TGT using the broken session key*

*Credit: POC by James Forshaw and Rubeus by GhostPack*

CVE-2022-33647 Technical Analysis

Fortunately for the attacker, CVE-2022-33647 vulnerability works with pre authentication, unlike CVE-2022-33679. This is important because pre-auth is enabled by default for every created object in Active Directory. The major requirement for this attack is a Man-In-The-Middle between the client and the domain controller (This attack type is common and there are many ways to achieve it like DNS spoofing, ARP Poisoning etc.). The MITM is used to force the client to downgrade the encryption to MD4-RC4.

Exploitation flow

When the first AS request is sent from the client, the KDC responds with ‘pre-auth is required’ message. However, the attacker can alter the response of the KDC because at this stage of the authentication there is no verification. We will modify the supported encryption by the KDC to RC4-MD4 as shown in the figure. As a result, (if RC4 is enabled), the client will send an AS_REQ with pre-auth using the MD4-RC4 algorithm.

From this point, the attacker has two options:

Brute force the 5 byte session key which might not be as efficient and might take a long time.
The other option is leveraging the knowledge of the plaintext data- the pre-authentication.In Kebreros, the MITM adversary can have an accurate estimation of the plaintext pre-authentication timestamp created by the client in the AS request. The encryption mechanism lacks an initialization vector or nonce and it ignores the key usage value. As a result, the same keystream is used in different parts of the authentication exchange. So, most of the key stream uses the same RC4 keystream. The pre-auth contains an encrypted timestamp, so using our knowledge of the current time, the attacker can discover part of the keystream. If the attacker is lucky, the same keystream will be used to decrypt 4 bytes of the TGT Session key in the AS response. The last byte is overlapping with the timestamp’s least byte, which represents microseconds, which are unknown to the attacker. The last byte will be broken in a brute force attack against an achieved TGS request of the victim, as outlined below.

ASN.1 Serialization Zoom In

ASN.1 DER encoding is a tag, length, value encoding system for each element. The preauthentication timestamp is encoded using this method. The structure of the encoded timestamp consists of a sequence with two elements. The first, a GeneralizedTime object (KerberosTime)in a Zulu format. The second element is an integer which represents the Microseconds.

Each element has its own tag and length following the value. For this reason, we can identify 10 constant bytes which represent all the tags and lengths.

30 -> Sequence tag
1A – (int) 26 (length of entire structure)
A0 – 1st element tag
11 – element length
18 – Generalize time tag
0F – (int) value length (15)
A1 – 2nd element tag
05 – (int) element length
02 – INTEGER type tag
03 – (int) value length

The total amount of constant bytes is 10, we will add another 15 bytes length for guessing the timestamp. The last three bytes are the microseconds element which is not efficient to guess. Finally, additional 24 bytes of zeros before the encrypted part will give out a keystream of 49 bytes. The TGT session key is located between byte 46 to 50 of the AS response. The last missing keystream byte can be brute forced against an intercepted service ticket of the victim.

Patch

Thes vulenerabilies were closed by Microsoft in September security update. The update disabled the RC4-MD4 (-128) encryption type alongside with RC4-HMAC-OLD (-133) encryption type. Once patched, future AS-REQ/TGS-REQ using one of these two encryption types will receive “Unsupported encryption type” error.

https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-33679