RE: Can Kerberos be cracked??

From: Bruce Marshall (brucem@lucent.com)
Date: 10/25/01


From: Bruce Marshall <brucem@lucent.com>
To: cxnolke@regence.com
Subject: RE: Can Kerberos be cracked??
Date: Thu, 25 Oct 2001 14:00:56 -0500
Message-ID: <002401c15d87$613a8dc0$417c7787@ins.com>

Chris,

I'm sure you'll get a lot of messages on this subject, but Kerberos doesn't
require a native mode domain.

A Windows 2000 (or now XP) machine in a Windows 2000 domain will speak
Kerberos to any other Windows 2000 machine in that domain, and typically the
whole forest if the default, automatic trusts are in place. Switching from
mixed mode to native mode has no real impact on the use of Kerberos.

The only time you should see a Windows 2000 machine speaking NTLM or LM is
when it isn't in a Active Directory domain or it is talking to legacy (NT,
W98) computers.

----
Bruce K. Marshall - brucem@lucent.com - 913-338-5090 x114
Lucent Technologies Worldwide Services - Overland Park, KS

> -----Original Message----- > From: cxnolke@regence.com [mailto:cxnolke@regence.com] > Sent: Wednesday, October 24, 2001 6:06 PM > To: Perkins, Sharon MSER:EX > Cc: focus-ms@securityfocus.com > Subject: RE: Can Kerberos be cracked?? > > > > http://www.microsoft.com/technet/treeview/default.asp?url=/Tec hNet/prodtechnol/windows2000serv/deploy/kerberos.asp > > was where I had found it. (note the exclusion of the /confeat > part of the > path shown in the previous email below) > Its an alright article, but doesnt go into the differences between LM, > NTLM, NTLMv2, and Kerberos enough to understand the difficulty or > impossiblity of doing the l0pht style pwdump/hash brute force > attack when > Kerberos is used vs. when NTLM/v.2 is. Be aware how > infrequently clients > use Kerberos in the real world. Native 2000 is required on client and > KDC/DC or NTLM is going to be used. > > MSFT did an awesome thing by using Kerberos, and supporting > is with all the > KerbV5 utilities for interfacing with MIT unix Kerberos. Its > just a shame > that so few admins have the skills to move the network to > native Kerberos > use. Most dont realize that NTLM is whats being used. And NTLM isnt > nearly as stout as Kerberos, nor as happy with AD. > > I really did enjoy Laura's essay though. When you try and > take something > as difficult to put into simple terms as the Authentication > Service portion > of Kerberos, you see alot about the personality attempting it > :) Now if > you tried transitive trust models, we would have had even more fun ;-) > > Chris Nolke > ---------------------------------------- > cxnolke@regence.com > Security Geek > The Regence Group > > > > > > "Perkins, Sharon > > MSER:EX" To: > focus-ms@securityfocus.com > <Sharon.Perkins@gems3. cc: > > gov.bc.ca> Subject: > RE: Can Kerberos be cracked?? > > > 10/24/2001 12:08 PM > > > > > > > > > > You might find the following whitepaper clarifies what you've been > discussing > > http://www.microsoft.com/technet/treeview/default.asp?url=/tec hnet/prodtechn > > ol/windows2000serv/deploy/confeat/kerberos.asp > > -----Original Message----- > From: Bruce Marshall [mailto:brucem@lucent.com] > Sent: Wednesday, October 24, 2001 10:28 AM > To: 'Bugger Bugtraq'; focus-ms@securityfocus.com > Subject: RE: Can Kerberos be cracked?? > > > Bugger, > > In order to get the hash you would need to launch a brute force attack > against the encrypted timestamp. If you were able to decrypt > the timestamp > that key should be the user's hashed password. > > As for your assumption about the hash being as good as the > password, this > is > true to some extend. Obviously you can't enter that hash > into the Windows > logon screen, but you could hack together your own client > that could use > the > hash to authenticate. > > If you wanted the password itself you would need to conduct a > brute-force > or > dictionary cracking session to find a match for the hash. > > > ---- > Bruce K. Marshall - brucem@lucent.com - 913-338-5090 x114 > Lucent Technologies Worldwide Services - Overland Park, KS > > > > -----Original Message----- > > From: Bugger Bugtraq [mailto:somebug@hotmail.com] > > Sent: Tuesday, October 23, 2001 8:48 PM > > To: larobins@bellatlantic.net; fp56@dial.pipex.com; > > focus-ms@securityfocus.com > > Subject: Re: Can Kerberos be cracked?? > > > > > > Assuming the steps on user verification u've stated is > > correct (I'm not > > exactly into the details either)....firstly, wouldn't the > > hash (used to > > encrypt the timestamp) still be susceptible to brute-force > > using dictionary > > attacks (or even trying all possible combinations) especially > > since the > > hashing algorithm is known. (maybe even consider maintaining > > a database of > > pre-worked password-hash combinations) > > > > Secondly, even without the actual password known, wouldn't > > juz the hash (let > > say we have managed to get it as what u've stated below) be > > sufficient to > > spoof the authentication (since that hash information is all > > that is needed > > to encrypt the timestamp anyway)??? > > > > Did I get what u are saying rite????? > > > > > > >From: "Laura A. Robinson" <larobins@bellatlantic.net> > > >Reply-To: "Laura A. Robinson" <larobins@bellatlantic.net> > > >To: "Phil Pinder" <fp56@dial.pipex.com>, > <focus-ms@securityfocus.com> > > >Subject: Re: Can Kerberos be cracked?? > > >Date: Mon, 22 Oct 2001 20:35:59 -0400 > > > > > >Okay, first, looking at my response, it wasn't as clear as I > > would have > > >liked, so let me clarify it. > > > > > >When Jim Bob Billy Joe logs in and types in his password, > > that password is > > >run through a hash (hashing algorithm) to produce a string > > of bytes. The > > >hash itself is non-reversible, which means that it cannot be > > used to derive > > >the password. [*see note at bottom] The resultant set of > > bytes from the > > >hashing of the password is, in this case, the key that is > > then used to > > >encrypt the timestamp. When the KDC receives the > > preauthentication request, > > >it retrieves the user's key (which is the result of the > > hash) and uses that > > >to decrypt the timestamp. > > > > > >Where I feel I wasn't clear in my response was when I said that the > > >"resultant hash" generates the encryption key, when what I > > should have said > > >was that the "hashing algorithm" generates the encryption > > key and that the > > >encryption key is then used to encrypt the timestamp. > > Apologies for my > > >distinct lack of clarity; it was a rushed response. :-) > > > > > >Now, on to your question below- when a user's password is > created or > > >changed, the new password is hashed and the resultant value > > transmitted as > > >the user's new "long-term" (stored in AD and encrypted) key. On the > > >occasions when that key needs to be transmitted across the > > wire, it is > > >transmitted using SSL over LDAP, thus protecting the key > > while it is in > > >transit. > > > > > >Now, as for how the authenticating server verifies the password- it > > >doesn't. > > >It verifies the key. The server doesn't actually know what > the user's > > >password is, and doesn't care. What the server does know is > > what the hash > > >result (key) is. When the server receives the > > preauthentication request, it > > >retrieves the user's key from AD and decrypts the timestamp > > with that. If > > >it > > >can successfully decrypt the timestamp with the user's key and the > > >timestamp > > >has not expired, then the server knows that the correct key > > (hash result) > > >was used to encrypt the timestamp. > > > > > >So, even if you *could* snag the correct packet off the wire > > and decrypt > > >the > > >timestamp (we're talking significant time here), all that > > would actually > > >tell you is what the byte string was that was used to encrypt the > > >timestamp- > > >it wouldn't tell you the user's password. > > > > > >*note at bottom: > > > > > >by referring to the hash algorithm as non-reversible, think > > of it like this > > >(none of this math is valid in any way or meant to represent > > the actual > > >hashing algorithm; I'm just trying to conceptualize how a > > one-way hash > > >works > > >for those who might be unclear) > > > > > >I am your computer. (Obviously, I'm not, but bear with me. ;-) ) > > > > > >You change your password to "jimbobbillyjoe". > > > > > >I take the word "jimbobbillyjoe" and say to myself, "Okay, > > I'm going to > > >derive the key by counting the number of letters in the > > password (14), then > > >adding five to that number (19). If the result is more than > > one digit in > > >length, I'm going to multiply by five to get another number. > > If it is less > > >than two digits, I am going to multiply it by forty-two. > > (Since result is > > >19, it is multiplied by 5, resulting in 95.) Then I'm going > > to go through > > >the alphabet as many times as it takes to gather the number > > of digits in > > >the > > >result number. (Therefore, I would go through the alphabet > > to produce the > > >following: > > >abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghi > > jklmnopqrstuvwx > > >yzabcdefghijklmnopqrstuvw ) Then I'm going to take all of > > those letters and > > >dump the vowels. > > >(bcdfghjklmnpqrstvwxyzbcdfghjklmnpqrstvwxyzbcdfghjklmnpqrstvw > > xyzbcdfghjklmnp > > >qrstvw). Then I'll assign numeric values to each letter in > > the alphabet, > > >write out all the resulting digits, and that is what I will > > then use as > > >your > > >new long-term key." > > > > > >The point here is, you have no way of knowing exactly how > > the resultant > > >value actually came to be, only what the resultant value > > (key) is, and you > > >can't "undo" what I did to produce it. That key is what is used to > > >(reversibly) encrypt the timestamp in your preauthentication > > data, and the > > >key is the only thing that the KDC has associated with you- > > *not* your > > >password itself. > > > > > >I hope this makes sense; I'm high on Nyquil due to having a > > case of the > > >flu. > > > > > >Oh, and if you just want the quick and dirty answer to your > > question (now > > >that I've looked at it again and realized you asked a very simple > > >question): > > > > > >The encryption key itself is sent to the authenticating > > server when it is > > >created (*not* when it is used to encrypt a timestamp), and > > it is protected > > >by transmitting it via SSL over LDAP. > > > > > >Hope this helps, > > > > > >Laura Robinson > > > > > >----- Original Message ----- > > >From: "Phil Pinder" <fp56@dial.pipex.com> > > >To: "Laura A. Robinson" <larobins@bellatlantic.net>; > > ><focus-ms@securityfocus.com> > > >Sent: Friday, October 19, 2001 6:17 PM > > >Subject: RE: Can Kerberos be cracked?? > > > > > > > > > > Thanks for the info Laura > > > > > > > > That raises the question: how does the Authentication > > server verify the > > > > password - by generating the same encryption key? (in > > which case couldnt > > >it > > > > still be reverse engineered?) or is the encryption key > itself sent > > >encrypted > > > > to the Authentication Server (encrypted with what key?)? > > (I cant find an > > > > explanation at this level of detail without it resorting to > > >cryptographic > > > > algebra) > > > > > > > > Many thanks > > > > > > > > Phil > > > > > > > > > > > > _________________________________________________________________ > > Get your FREE download of MSN Explorer at > > http://explorer.msn.com/intl.asp > > > > > ============================================================== > ============= > IMPORTANT NOTICE: This communication, including any > attachment, contains > information that may be confidential or privileged, and is > intended solely > for the entity or individual to whom it is addressed. If you > are not the > intended recipient, you should delete this message and are > hereby notified > that any disclosure, copying, or distribution of this message > is strictly > prohibited. Nothing in this email, including any attachment, > is intended > to be a legally binding signature.



Relevant Pages

  • RE: Can Kerberos be cracked??
    ... Subject: Can Kerberos be cracked?? ... If you were able to decrypt the timestamp ... As for your assumption about the hash being as good as the password, ... > encrypt the timestamp) still be susceptible to brute-force> using dictionary ...
    (Focus-Microsoft)
  • RE: Can Kerberos be cracked??
    ... Subject: Can Kerberos be cracked?? ... If you were able to decrypt the timestamp ... As for your assumption about the hash being as good as the password, ... > encrypt the timestamp) still be susceptible to brute-force> using dictionary ...
    (Focus-Microsoft)
  • RE: Can Kerberos be cracked??
    ... The only clients with Kerberos are 2k+ clients. ... > In order to get the hash you would need to launch a brute force attack> against the encrypted timestamp. ... >> encrypt the timestamp) still be susceptible to brute-force ...
    (Focus-Microsoft)
  • Re: Can Kerberos be cracked??
    ... Subject: Can Kerberos be cracked?? ... A "salt" is a "random" value that is appended to the ... possible for you to dictionary-crack my password unless you know the ... >> In order to get the hash you would need to launch a brute force attack ...
    (Focus-Microsoft)
  • RE: Can Kerberos be cracked??
    ... If you were able to decrypt the timestamp ... As for your assumption about the hash being as good as the password, ... > encrypt the timestamp) still be susceptible to brute-force> using dictionary ... The server doesn't actually know what the user's>>password is, ...
    (Focus-Microsoft)