Microsoft recently released an out of band patch for Kerberos. Taking a look at the Microsoft security bulletin, it seems like there is some kind of issue with Kerberos signatures related to tickets.
Further information is available in the Microsoft SRD Blog post:
So it looks like there is an issue with PAC signatures. But what specifically? If we take a look at the kdsvc.dll patch for Server 2008, there are 3 changed functions:
As expected, two of the three involve PAC (Privilege Attribute Certificate). VerifyPacSignature looks promising. Let’s see what changed there.
More or less, a comparison like above ( cmp <something>, 0xFFFFFF76 ) was added in two places. The result of this comparison will either lead to further processing or to returning a Kerberos specific error as seen below.
The value 0xFFFFFF76 can be traced upward in the patched function to a nearby call to _CDLocateChecksum.
This function is imported from cryptdll.dll, so opening that in IDA we can follow the second argument to CDLocateChecksum and see that the source of this value seems to come from the _CheckSumFns array.
Tracing XREFS to this array, CDRegisterCheckSum appears to be the only other place it is used and is most likely where it gets set.
Taking a look at CDRegisterCheckSum, it seems to take an argument and register it into the _CheckSumFns array.
XREFS to this function are illustrative of actual population of the array –
Moving back to LoadCheckSums(), we find the source of this constant nicely formatted with Windows symbols.
Each of these arguments to CDRegisterChecksum is a structure defined like so
DWORD identifier
DWORD checkSumSize
DWORD dunno
<several function pointers>
If we take this data and look at the Microsoft specification for PAC [MS-PAC], we can see that it is somewhat inconsistent. Under section 2.8, we can find details about the PAC signature data:
It is apparent from above, that although the spec says you are only allowed to use those three, we have quite a few more available to us as a client including CRC32. Therefore, getting back to the patch, it appears now that VerifyPacSignature is ensuring that the SignatureType is 0xFFFFFF76 (HMAC_MD5) before continuing processing.
Further information is available in the Microsoft SRD Blog post:
So it looks like there is an issue with PAC signatures. But what specifically? If we take a look at the kdsvc.dll patch for Server 2008, there are 3 changed functions:
As expected, two of the three involve PAC (Privilege Attribute Certificate). VerifyPacSignature looks promising. Let’s see what changed there.
More or less, a comparison like above ( cmp <something>, 0xFFFFFF76 ) was added in two places. The result of this comparison will either lead to further processing or to returning a Kerberos specific error as seen below.
The value 0xFFFFFF76 can be traced upward in the patched function to a nearby call to _CDLocateChecksum.
This function is imported from cryptdll.dll, so opening that in IDA we can follow the second argument to CDLocateChecksum and see that the source of this value seems to come from the _CheckSumFns array.
Tracing XREFS to this array, CDRegisterCheckSum appears to be the only other place it is used and is most likely where it gets set.
Taking a look at CDRegisterCheckSum, it seems to take an argument and register it into the _CheckSumFns array.
XREFS to this function are illustrative of actual population of the array –
Moving back to LoadCheckSums(), we find the source of this constant nicely formatted with Windows symbols.
Each of these arguments to CDRegisterChecksum is a structure defined like so
DWORD identifier
DWORD checkSumSize
DWORD dunno
<several function pointers>
If we take this data and look at the Microsoft specification for PAC [MS-PAC], we can see that it is somewhat inconsistent. Under section 2.8, we can find details about the PAC signature data:
It is apparent from above, that although the spec says you are only allowed to use those three, we have quite a few more available to us as a client including CRC32. Therefore, getting back to the patch, it appears now that VerifyPacSignature is ensuring that the SignatureType is 0xFFFFFF76 (HMAC_MD5) before continuing processing.
Scott Lang, Sr. Director, Product Marketing at BeyondTrust
Scott Lang has nearly 20 years of experience in technology product marketing, currently guiding the product marketing strategy for BeyondTrust’s privileged account management solutions and vulnerability management solutions. Prior to joining BeyondTrust, Scott was director of security solution marketing at Dell, formerly Quest Software, where he was responsible for global security campaigns, product marketing for identity and access management and Windows server management.
