Thursday, November 16, 2023

We Patched CVE-2023-28244 Before It Was Cool

How Our Patch For CVE-2022-33647 Fixed CVE-2023-28244 Five Months In Advance

By Blaz Satler of 0patch Team

The Initial Vulnerability - CVE-2022-33647

In September 2022, Microsoft released patches for CVE-2022-33647, a Kerberos vulnerability that allows a MITM (Man-In-The-Middle) attacker to hijack a user's Kerberos ticket and achieve domain privilege escalation. James Forshaw of Google Project Zero was attributed with the discovery of this issue, and shortly after the issue was fixed also published a writeup on the official Project Zero bug tracking page. James also forked a branch of GhostPacks Rubeus tool and added a sample POC (Proof-of-Concept) code that demonstrated this issue in action and allowed users to check if their KDC (Key Distribution Center) was affected.

Testing revealed that this issue affected all Kerberos versions that have not configured any restrictions for the use of old cryptographic algorithms, specifically RC4-MD4. This algorithm is particularly dangerous as it contains multiple known vulnerabilities, such as using only the first 8 key bytes for encryption and only 40 bits of randomness in session keys. Such security deficiencies could make you wonder why the algorithm is even allowed to be used in Kerberos. Nevertheless, Kerberos allowed its use by default and also didn't seem to mind being downgraded from a stronger protocol to RC4-MD4 mid-session, which was why the POC worked.


Microsoft's Patch

We analyzed Microsoft's patches for CVE-2022-33647 and the exploit's execution flow. All signs seemed to point to a patch in kdcsvc.dll, specifically in the KerbInitPreferredCryptList function. This function executes when the KDC service starts which is with the start of lsass.exe. Its job is to initialize the PrefferedCryptList (yes, we know, it's a typo in the code too) variable and two other lists with cryptographic algorithms that the KDC will prefer. Microsoft patched this by not including RC4-MD4 and RC4_HMAC_OLD to these lists. At the time this fix seemed sufficient with the only apparent flaw being that it would only come into effect after the system that applied the patch had been restarted. 


Our Micropatch

Our own patch, in contrast, needed to be able to protect the system from the moment that the user decided to apply it, so we needed to find a better way of blocking these protocols. During the analysis, we stumbled upon the KerbGetEncTypeBitmask function which supplies bit masks of all supported encryption algorithms to other parts of the code. It has the ability to refuse unknown encryption types, so we decided to take a closer look. Upon further investigation, we found that it was invoked on every request to the KDC, so it made for a perfect candidate for patching this exploit in real time (without a reboot). Our patch was injected at the start of this function and checked if the passed cryptographic algorithm was one of the two that Microsoft had blocked; if it was, we simply executed the "return 0" command which returns KDC_ERR_ETYPE_NOTSUPP ("type not supported"). This had the effect of completely blocking any use of RC4_MD4 and RC4_HMAC_OLD, and our patches were released in October 2022.

The New Vulnerability - CVE-2023-28244

6 months later, Microsoft released a fix for another similar vulnerability CVE-2023-28244, acknowledging John Askew with Terrapin Labs as the discoverer. Subsequently John also published a POC on GitHub which seemed eerily similar to James' POC for CVE-2022-33647. Our tests revealed that this new exploit attacked the same RC4-MD4 encryption algorithm but with a slight modification to the AS-REQ packet. This new exploit included a timestamp encrypted with the user's password inside the AS-REQ, which changed the execution flow in kdcsvc.dll.

This modification caused the exploit to bypass Microsoft's patch that had caught its predecessor. Microsoft's patch only changed how a few crypt lists were initialized, but left some relevant global variables like KdcGlobalSupportedEnctypes unchanged. Although there were other checks in place for unsupported encryption types that were executed later, none of them used the patched PrefferedCryptList variable that was stripped of RC4-MD4 and RC4_HMAC_OLD. This again resulted in RC4-MD4 being used for encrypting the session and tickets.



A Pretty Decent Patch

The micropatch we had released for CVE-2022-33647, on the other hand, proved to be remarkably robust, effectively neutralizing the new, modified exploit. It was particularly gratifying to find that Microsoft's fix for the new vulnerability targeted the same function as our original patch (KerbGetEncTypeBitmask), and closely resembled our own patch for this vulnerability: it removed the validation for RC4-MD4 and RC4_HMAC_OLD encryption algorithms within the KerbGetEncTypeBitmask function, returning a '0' as the function's result when these algorithms were passed to it. This behavior is logically equivalent to our patch.

Effectively, our patch for CVE-2022-33647 fixed CVE-2023-28244 entire 157 days before it was patched by Microsoft

Looking for a way to keep using Windows Server 2012 securely, and don't want to purchase expensive Extended Security Updates? Want to protect your legacy Windows 7, Server 2008 R2 machines and Microsoft Office installations with actual security patches that don't even need a computer restart and can get applied or un-applied in seconds? Not objecting to having occasional vulnerabilities fixed before those running still-supported Windows versions? 0patch has your back!

Learn more about 0patch on our web site, in our Help Center, or contact us at for a free trial or demo.


No comments:

Post a Comment