Hunting down DES in order to securely deploy Kerberos

發行項
10/19/2010

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:

If you don’t know how to enable this auditing in general, review:

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

Comments

Anonymous
October 20, 2010
Just for a reference: here's how you can find even more etypes and their respective numeric values: blogs.msdn.com/.../etypes.aspx And here's a copy of ntsecapi.h just in case for whatever reason you still don't have a copy of Windows SDK installed on your grandmother's laptop: web.mit.edu/.../NTSecAPI.h.vista
Anonymous
September 04, 2014
The comment has been removed

共用方式為