Hello folks, Ned here again. By now many businesses have begun deploying Windows Server 2008 R2 and Windows 7. Since Active Directory has become ubiquitous, Kerberos is now commonplace. What you may not know is that we made a significant change to default cryptographic support in Kerberos starting in Win7/R2 and if you are not careful, it may break some of your environment: by default, the DES encryption type is no longer enabled.
For those who have homogenous Windows networks with no third party operating systems or appliances, and who have not configured DES for any user accounts, you can stop reading.
Ok, one guy left. Everyone else pay attention.
Some Background on Kerberos Encryption Types
The phrase “encryption type” is simply another way of saying cryptography. Windows supports many cipher suites in order to protect Kerberos from being successfully attacked and decrypted. These suites use different key lengths and algorithms; naturally, the newer the cipher suite we support and use, the more secure the Kerberos.
|
Encryption |
Key length |
MS OS Supported |
|
AES256-CTS-HMAC-SHA1-96 |
256-bit |
Windows 7, Windows Server 2008 R2 |
|
AES128-CTS-HMAC-SHA1-96 |
128-bit |
Windows Vista, Windows Server 2008 and later |
|
RC4-HMAC |
128-bit |
Windows 2000 and later |
|
DES-CBC-MD5 |
56-bit |
Windows 2000 and later, off by default in Win7/R2 |
|
DES-CBC-CRC |
56-bit |
Windows 2000 and later, off by default in Win7/R2 |
In practical terms, a Windows computer starts a Kerberos conversation sending a list of supported encryption types (ETypes). The KDC responds to the list with the most secure encryption type they both support. For example, a Windows 7 computer sends an AS_REQ. The AS_REQ contains the supported encryption types of AES256, AES128, RC4, and DES (only because I enabled it through security policy ) – we can see this in a network capture:
The KDC responds that it requires pre-authentication and sends a list of its supported encryption types:
The client uses a password hash to encrypt a key. The client uses the encrypted key to protect the time stamp that it includes in the “real” AS_REQ. In this instance, the preferred encryption used is AES256, the highest level of encryption supported by Win7 and 2008 R2:
I use Netmon 3.4 for the above examples (I’ll explain its importance later). As you can see, it’s un-fun to parse Kerberos traffic with it. This is how it looks in Wireshark ; sometimes it’s easier to read for learning purposes:
The Deal with DES
DES (Data Encryption Standard) came about in the late 1970’s as a standardized encryption suite. Since then it’s been adopted by a lot of software; it’s probably one of the most supported ciphers in the world. It’s also quite insecure and no version of Windows has ever used it by default when talking to Windows KDCs; the minimum there has always been 128-bit RC4-HMAC. Starting in Windows 7, we decided that Windows, out of the box, would no longer support DES… at all. You’re in good shape as long as you don’t have any operating systems other than Windows.
The problem is people use other operating systems (and may not even know it; your appliance web proxy is running a 3 rd party operating system, bub). Those operating systems are not always configured to use Kerberos security at the highest cipher levels and often do not support negotiation or pre-authentication. Also, they may not support AES ciphers. And certain applications might require DES encryption due to short-sighted programming or default settings.
This leaves you in a pickle: do you roll the dice and deploy Windows Server 2008 R2 DC’s and Windows 7 clients, hoping that there are no issues? Or do you enable DES on all your new computers using group policy , knowing you are enabling a cipher that weakens Kerberos? I think there’s a third option… that’s better…
Finding Kerberos EType usage in your domain
We document some simple steps for finding DES usage in your domain in KB977321 using network captures in a test environment. But wouldn’t it be easier to determine Kerberos usage based on security auditing so that you could gather and analyze and query data ? You can. This only requires is that you have DC’s running at least Windows Server 2008.
1. If you already deployed Windows Server 2008 R2 and have enabled DES everywhere to error on the side of app compatibility, then configure security auditing against all DCs for success:
- Kerberos Authentication Service
- Kerberos Service Ticket Operations
These auditing actions are part of the Account Logon category. For more details on these review these two KBs:
- Description of security events in Windows Vista and in Windows Server 2008
- Description of security events in Windows 7 and in Windows Server 2008 R2
If you don’t know how to enable this auditing in general, review:
- Planning and Deploying Advanced Security Audit Policies
- How to use Group Policy to configure detailed security auditing settings for Windows Vista-bas...
And no, this doesn’t work with Windows Server 2003 DC’s. Who cares, DES can’t be touched there… :)
Depending on the size of your environment or quantity of auditing events, you may need to use some sort of security event log harvesting service like ACS . It will make querying your data easier. There are third parties that make these kinds of apps as well.
2. Drink mint juleps for a few days.
3. Examine your security audit event logs on your DC’s. Here is where it gets interesting. A few examples:
-------------------------
Log Name: Security
Source: Microsoft-Windows-Security-Auditing
Date: 10/13/2010 5:06:47 PM
Event ID: 4769
Task Category: Kerberos Service Ticket Operations
Level: Information
Keywords: Audit Success
User: N/A
Computer: 2008r2-01-f.contoso.com
Description:
A Kerberos service ticket was requested.
Account Information:
Account Name: krbned@CONTOSO.COM
Account Domain: CONTOSO.COM
Logon GUID: {eed17165-1ca0-613b-51ae-17005546c7f0}
Service Information:
Service Name: 2008R2-01-F$
Service ID: CONTOSO\2008R2-01-F$
Network Information:
Client Address: ::ffff:10.70.0.221
Client Port: 49203
Additional Information:
Ticket Options: 0x40810000
Ticket Encryption Type: 0x12
Failure Code: 0x0
Transited Services: -
-------------------------
Log Name: Security
Source: Microsoft-Windows-Security-Auditing
Date: 10/12/2010 10:32:29 AM
Event ID: 4768
Task Category: Kerberos Authentication Service
Level: Information
Keywords: Audit Success
User: N/A
Computer: 2008r2-01-f.contoso.com
Description:
A Kerberos authentication ticket (TGT) was requested.
Account Information:
Account Name: krbned
Supplied Realm Name: CONTOSO
User ID: CONTOSO\krbned
Service Information:
Service Name: krbtgt
Service ID: CONTOSO\krbtgt
Network Information:
Client Address: ::ffff:10.70.0.115
Client Port: 1088
Additional Information:
Ticket Options: 0x40810010
Result Code: 0x0
Ticket Encryption Type: 0x17
Pre-Authentication Type: 2
Certificate Information:
Certificate Issuer Name:
Certificate Serial Number:
Certificate Thumbprint:
------------------------
These “Ticket Encryption Type” values look mighty interesting. But what is a 0x17? Or a 0x12? Is there a complete list of what these all mean?
Use Netmon to decipher these values. First though, I’ll let you in on a little secret: Netmon 3 exists mainly as part of our efforts to document our protocols for the EU and the DOJ. That’s why when you look at the parsing in the frame details page it is designed more for completeness than readability. You get to reap the rewards of this, as it’s why the Netmon parsers are not monolithic – instead, they allow easy viewing and even live editing, all loaded from text.
1. Go back and look at that network capture screenshot I showed previously:
All of those Etypes have a number in parenthesis. But they aren’t hex numbers. And from looking at my event logs above for example, the etype 0x12 came from a Windows 7 computer; that has to be AES-256, which the above screenshot shows is a value of 18.
I just gave you a big hint. :)
2. Take a look at the parsers tab in Netmon, specifically for Protocols , then KerberosV5 :
3. Take a look at the KrbETypeTable entry – look familiar? Here’s where those numbers are coming from that get displayed in the parser:
Table KrbETypeTable( eType )
{
Switch( eType )
{
Case 1: FormatString("des-cbc-crc (%d)", eType);
Case 2: FormatString("des-cbc-md4 (%d)", eType);
Case 3: FormatString("des-cbc-md5 (%d)", eType);
Case 4: FormatString("[reserved] (%d)", eType);
Case 5: FormatString("des3-cbc-md5 (%d)", eType);
Case 6: FormatString("[reserved] (%d)", eType);
Case 7: FormatString("des3-cbc-sha1 (%d)", eType);
// 9 through f in both RFC 3961 and MCPP
Case 9: FormatString("dsaWithSHA1-CmsOID (%d)", eType);
Case 10: FormatString("md5WithRSAEncryption-CmsOID (%d)", eType);
Case 11: FormatString("sha1WithRSAEncryption-CmsOID (%d)", eType);
Case 12: FormatString("rc2CBC-EnvOID (%d)", eType);
Case 13: FormatString("rsaEncryption-EnvOID (%d)", eType);
Case 14: FormatString("rsaES-OAEP-ENV-OID (%d)", eType);
Case 15: FormatString("des-ede3-cbc-Env-OID (%d)", eType);
Case 16: FormatString("des3-cbc-sha1-kd (%d)", eType);
Case 17: FormatString("aes128-cts-hmac-sha1-96 (%d)", eType);
Case 18: FormatString("aes256-cts-hmac-sha1-96 (%d)", eType);
Case 0x17: FormatString("rc4-hmac (%d)", eType);
Case 0x18: FormatString("rc4-hmac-exp (%d)", eType);
Case 0x41: FormatString("subkey-keymaterial (%d)", eType);
And what do you think happens if I use calc to convert decimal 18 to hex? Indeed – you get 0x12 . Which is aes256-cts-hmac-sha1-96 , and that’s what your event log was trying to tell you. So all converted out, this means that the theoretical event log entries could be:
|
Hex |
Etype |
|
0x1 |
des-cbc-crc |
|
0x2 |
des-cbc-md4 |
|
0x3 |
des-cbc-md5 |
|
0x4 |
[reserved] |
|
0x5 |
des3-cbc-md5 |
|
0x6 |
[reserved] |
|
0x7 |
des3-cbc-sha1 |
|
0x9 |
dsaWithSHA1-CmsOID |
|
0xa |
md5WithRSAEncryption-CmsOID |
|
0xb |
sha1WithRSAEncryption-CmsOID |
|
0xc |
rc2CBC-EnvOID |
|
0xd |
rsaEncryption-EnvOID |
|
0xe |
rsaES-OAEP-ENV-OID |
|
0xf |
des-ede3-cbc-Env-OID |
|
0x10 |
des3-cbc-sha1-kd |
|
0x11 |
aes128-cts-hmac-sha1-96 |
|
0x12 |
aes256-cts-hmac-sha1-96 |
|
0x17 |
rc4-hmac |
|
0x18 |
rc4-hmac-exp |
|
0x41 |
subkey-keymaterial |
And if you want to catch DES usage, you should watch for events that included 0x1 and 0x3 , as those are the versions of DES that Windows implements. Tada…
Regardless of whether or not you care about Kerberos DES parsing, you can use these techniques to reverse engineer protocols based on the Netmon parser code or even fix parser errors. It’s a slick technique to keep in your back pocket. If you just wanted to cheat you could have looked these up in RFC 3961 . This is “teaching to fish” time :).
Ok, now what?
It’s all well and good to know that you have software using DES in your environment. The next step is to change that behavior. Here are your tasks:
- Make sure you have no DES-enabled user accounts in your domain.
- Use your event log audit trail to create an inventory of computers sending DES etypes. Examine those computers and devices (they are probably not running Windows).
- If the computers are running Windows, examine them for non-Microsoft software. One of those is the culprit. Netmon, Process Monitor, Process auditing, etc. can all be used to track down which process is requiring the insecure protocol. Contact the vendor about your options to alter the behavior.
- If the computers are not running Windows or they are appliances, examine their local Kerberos client configurations or contact their vendors. You will also need to look at the installed apps as the OS might not be to blame (but it usually is).
- If you get stuck with a vendor that refuses to stop using DES, contact their sales department and make a stink. Sales will usually be your advocate, as they want your money so they can buy more BMW M3’s. Using DES at this point is terminal laziness or the sign of a vendor that absolutely does not care at all about security – probably not someone with which you want to do business.
Final thoughts
This post wasn’t a treatise on Kerberos or even encryption types, naturally. If you want a lot more interesting reading an insomnia cure, I recommend:
- Kerberos for the busy admin (the classic Rob Greene blog post)
- How the Kerberos Version 5 Authentication Protocol Works (our Technical reference from Win2003/XP)
- Kerberos Network Authentication Service (V5) (RFC 4120)
- Encryption and Checksum Specifications for Kerberos 5 (RFC 3961)
- Advanced Encryption Standard (AES) Encryption for Kerberos 5 (RFC 3962)
- MS Kerberos Protocol Extensions Specification (our extra goo that goes beyond the RFCs)
- The history of DES (Wikipedia)
Until next time.
- Ned “that’s the same cipher I have on my luggage!” Pyle