Nytro Posted September 30, 2022 Report Posted September 30, 2022 Issue 2310: Windows: Kerberos RC4 MD4 Encryption Downgrade EoP Reported by forshaw@google.com on Thu, Jun 2, 2022, 9:58 PM GMT+3 Project Member Description #1 by forshaw@google.com (Jun 2, 2022) Windows: Kerberos RC4 MD4 Encryption Downgrade EoP Platform: Windows 10+ Class: Elevation of Privilege Security Boundary: User Summary: The KDC allows an interposing attacker to downgrade to RC4 MD4 encryption in compromising the user's TGT session key resulting in EoP. NOTE: I tried to look if this was something which has been reported before. The fact that Kerberos can have its encryption downgraded is a well known issue, but the primary use case seems to be to get crackable data by weakening the encryption. However, I couldn't find a description of this specific attack. Also while I'm sure Kerberos armoring will prevent the attack as is, unless FAST is required I am led to understand that an attacker can downgrade to non-FAST if they're in a privileged position on the network. Description: When Kerberos makes an initial request to the KDC to authenticate a user it sends an AS-REQ structure. One of the options in the AS-REQ is a list of encryption algorithms that the client supports. The KDC will accept the strongest available from the list for things like session keys. The problem with the list is it's unprotected (without FAST) and so an attacker who interposes the connection can modify it before it goes to the KDC. This allows the attacker to downgrade the encryption used to a weaker algorithm such as RC4-HMAC which is more amenable to cracking the password due to the weak password to key generation. However, even with downgrading to RC4-HMAC it's not an immediate exploit, the key would have to be cracked offline which for complex passwords can take a long time. For example, a computer account usually has a 120 character randomly generated password which would be effectively impossible to crack. Through inspection it seems that you can request any Kerberos encryption algorithm supported by CRYPTDLL which implements all the Kerberos encryption engines. The one of most interest is RC4-MD4 (encryption type -128) as it has some serious security weaknesses. 1. Only 8 of the 16 key bytes are used by the encryption algorithm. 2. The key is not blinded or otherwise hashed unlike RC4-HMAC which means the key stream is always the same for the same key. 3. The encryption ignores the key usage value so different parts of the protocol also use the same RC4 key stream. 4. The encryption has no cryptographic checksum applied so the cipher text can be modified if the plain text is known. 5. Session keys, when generated, only have 40bits of randomness, the remaining 11 bytes of the key as populated with the value 0xAB. If you can downgrade the client and KDC to use RC4-MD4 then it's catastrophic for the Kerberos authentication process. An attacker could get the KDC to use an RC4-MD4 session key for the initial TGT which only has 40 bits of entropy and be reasonably confident of brute forcing that before the associated ticket expires. They could then issue TGS requests for arbitrary service tickets for that user. However, brute force seems overly complex. Instead if the initial AS-REQ without the pre-authentication is downgraded then it induces the client into using RC4-MD4 with its RC4-HMAC key for the encrypted timestamp. The KDC authenticates the timestamp and returns an AS-REP with the result also encrypted to the user's RC4-HMAC key but with the RC4-MD4 algorithm. Almost the entirety of the encrypted timestamps' plain text data is known or can be guessed, which means we can determine the keystream for the user's encryption key. We can then apply that keystream to decrypt some encrypted data in the AS-REP. By luck the TGT session key is at the start of the encrypted data. We don't have enough of the keystream from the timestamp to decrypt the entire key but we only need the first 5 bytes due to the weak session key generation. We end up with an overlap between the last byte of the key and the first byte of the microseconds for the timestamp which could be anything. As long as we then observe at least one TGS-REQ from the user (which they will almost certainly do) we can use that to brute force offline the single remaining byte of the key. With the TGT session key the attacker could impersonate the user entirely. How you interpose the Kerberos connection is myriad. Obviously local network based attacks are possible such as a "Coffee Shop" attack or DNS spoofing. It's possible this could also resurrect attacks such as MS15-011 on group policy as getting the TGT of the computer account would allow for the session keys for service tickets to be decrypted and by extension the sub-session keys from the AP-REQ to hijack the SMB connection. Fixing wise, nothing should be using the RC4-MD4 encryption algorithm, it's not even clear why it's still there in CRYPTDLL. One way to mitigate the attack as described is to disable RC4 across the board, both on the KDC and the clients. If this is only disabled on clients then it might be possible to get the initial pre-authentication to use AES but only change the session key which might allow it to continue to function but I've not verified that. Even if you do that you might need to bruteforce the session key, but that's doable. Using PKINIT would break the initial hijacking of the AS-REQ's encrypted timestamp, but it might still be possible to downgrade the TGT's session key. At that point the only attack might be to brute force the key. However it is also possible that the encrypted data in the initial TGS-REQ could be attacked instead as the encrypted authorization data is encrypted with the same key as the authenticator. FAST would also break the attack as described but I'm not sure if that's sufficient if you're in a privileged network position and FAST is not required. Proof of Concept: I’ve provided a PoC as a C# project. It works locally using KDC pinning to hijack a SSPI Kerberos authentication process to steal the TGT. This in itself is a potentially useful local privilege escalation but of course the real attack would be remote. You need to get and build a copy of my NtApiDotNet library to build the project (https://github.com/googleprojectzero/sandbox-attacksurface-analysis-tools). 1) Compile the C# project, put a copy of NtApiDotNet.dll in the project's directory before building. 2) Run the POC on a domain joined machine where FAST hasn't been configured and RC4 is still enabled. 3) The POC should complete successfully. Expected Result: The downgraded encryption is rejected on the KDC and/or the client. Observed Result: The KDC and client honor the encryption downgrade and the POC can request a new TGT indicated by printing the final key. This bug is subject to a 90-day disclosure deadline. If a fix for this issue is made available to users before the end of the 90-day deadline, this bug report will become public 30 days after the fix was made available. Otherwise, this bug report will become public at the deadline. The scheduled deadline is 2022-08-31. [Deleted] poc_rc4.zip Sursa: https://bugs.chromium.org/p/project-zero/issues/detail?id=2310 Quote
