RE: Can Kerberos be cracked??

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

From: Bruce Marshall <brucem@lucent.com>
To: "'Bugger Bugtraq'" <somebug@hotmail.com>, focus-ms@securityfocus.com
Subject: RE: Can Kerberos be cracked??
Date: Wed, 24 Oct 2001 12:27:42 -0500
Message-ID: <001001c15cb1$310e1da0$417c7787@ins.com>

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

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??
    ... > against the encrypted timestamp. ... > As for your assumption about the hash being as good as the password, ... >> encrypt the timestamp) still be susceptible to brute-force ... The server doesn't actually know what the user's ...
    (Focus-Microsoft)
  • Re: Problems with public key decryption with RSA
    ... with securing the "Private key" at the clients. ... Encrypt key / IV with public RSA key of server. ... Sign hash and sign data elements with HMAC-SHA1 using symmetric key. ...
    (microsoft.public.platformsdk.security)
  • Re: Problems with public key decryption with RSA
    ... with securing the "Private key" at the clients. ... Encrypt key / IV with public RSA key of server. ... Sign hash and sign data elements with HMAC-SHA1 using symmetric key. ...
    (microsoft.public.dotnet.security)
  • Re: Can Kerberos be cracked??
    ... encrypt the timestamp) still be susceptible to brute-force using dictionary ... Secondly, even without the actual password known, wouldn't juz the hash (let ... The server doesn't actually know what the user's ...
    (Focus-Microsoft)