Subject: ["Frank O'Dwyer" <[email-masked]>: Re: Kerberos login sniffer and cracker for Windows 2000/XP]

From: Jeffrey Altman <[email-masked]>
Date: Sun, 1 Dec 2002 9:53:14 EST

The Kerberos Login Sniffer is directly aimed at Windows logins which
do use pre-auth.  This is the tool that we have feared would be
released prior to our coming to a solution before Microsoft absolutely
had to release something.  

If we still do not want Microsoft to begin using TLS to protect TGT
requests we need to come to an agreement quickly.  Probably within
days.  Otherwise, Microsoft might feel pressured to solve this within
a few weeks as I am sure that given this tool has now hit NTBUGTRAQ it
will be all over slashdot and e-week.

                ---------------

Approved-By: [email-masked]
Importance: Normal
Date:         Sun, 1 Dec 2002 11:23:20 -0000
Reply-To: Windows NTBugtraq Mailing List <[email-masked]>
Sender: Windows NTBugtraq Mailing List <[email-masked]>
From: "Frank O'Dwyer" <[email-masked]>
Subject: Re: Kerberos login sniffer and cracker for Windows 2000/XP
To: [email-masked]

> I've coded a simple Kerberos login sniffer and cracker for Windows 2000/XP
> that you might find useful. You can find it for download at:
>
> http://ntsecurity.nu/toolbox/kerbcrack/
>
> Regards /Arne

This should shed some light on the 'full disclosure' debate.

The vulnerability used by this thing, and the associated fixes, are well
known and documented in the literature for over a decade. I and others have
been banging on about it for years. Several papers, including one of my own,
have been written in an attempt to hammer home the message that tools like
this one were possible and simply a matter of time.

And yet somehow 1000s of admins have STILL got the message that Kerberos is
'unsniffable'. There doesn't seem to have been any urgency from vendors to
correct this impression, never mind the vulnerability itself. Instead
solutions to the problem are currently quietly and slowly wending their way
through the IETF process.

What will happen now? Will there be a sudden scramble to implement fixes now
that this tool has been announced? This guy hasn't put a nice GUI on the
tool. Yet. Will we have to wait for that?

After all the 'full disclosure' to and fro, is this sort of nonsense STILL
what it takes to get information into the hands of users, and obvious
security issues treated with urgency?

Cheers,
Frank O'Dwyer
[email-masked]

oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Delivery co-sponsored by TruSecure Corporation
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo
Demonstrate your knowledge and understanding of core IT Security, become
TICSA certified.

Are you responsible for IT security in job function, but not necessarily
in title? Do you want to prove your IT security knowledge and increase
opportunities? Interested? Visit;

http://www.trusecure.com/solutions/certifications/ticsa/

for more information.
oooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo

 Jeffrey Altman * Volunteer Developer      Kermit 95 2.1 GUI available now!!!
 The Kermit Project @ Columbia University  SSH, Secure Telnet, Secure FTP, HTTP
 http://www.kermit-project.org/            Secured with MIT Kerberos, SRP, and 
 [email-masked]               OpenSSL.

---

From: "Jacques A. Vidrine" <[email-masked]>
Date: Sun, 1 Dec 2002 11:08:05 -0600

> will be all over slashdot and e-week.

Okay, how about smb's suggestion to use anonymous Diffie-Hellman?
As I posted on the MIT list, I found this to be very doable.
The approach I took was to use DH in preauthentication, and then to use
the resultant secret in two ways:

   1) With an MAC (keyed by the user's password) to pre-authenticate
      to the KDC.

   2) To combine with the user's key to derive a key to be used to
      encrypt the TGT.

Cheers,
-- 
Jacques A. Vidrine <[email-masked]>          http://www.celabo.org/
NTT/Verio SME          .     FreeBSD UNIX     .       Heimdal Kerberos
[email-masked]     .  [email-masked]  .          [email-masked]

---

From: Sam Hartman <[email-masked]>
Date: Sun, 01 Dec 2002 15:59:08 -0500

So, I thought we had something approaching rough consensus that we
definitely wanted DCE style support for encrypting things in a key
combined with the host key for keyed hosts.

We still had open discussions on unkeyed hosts, looking at a variety
of proposals.  Anonymous DH has come up as a suggestion several times
and no one has actually objected to it or claimed it was insufficient
so far.  Can we agree on anonymous DH and get on with life?

---

From: Matt Crawford <[email-masked]>
Date: Mon, 02 Dec 2002 08:13:22 -0600

> > days.

How about the suggestion to use DCE RFC 26.0?

---

From: "Jacques A. Vidrine" <[email-masked]>
Date: Mon, 2 Dec 2002 09:22:10 -0600

> How about the suggestion to use DCE RFC 26.0?

DCE RFC 26.0 _requires_ that the client be pre-configured with a
secret.  Because of this, it can protect you from an active attacker
(MITM).  But, the secret must be supplied to the client in advance by
a Kerberos administrator.  I don't like that at all.

Anonymous Diffie-Hellman does not require that the client know
anything in advance.  It can only protect you from a passive attacker.

The DH approach can be extended to provide protection from an active
attacker as follows (there are a myriad of other possibilities as
well, of course):  The KDC publishes its ElGamal public key.  If the
client has access to this key, it can use it to encrypt its DH public
key.  If it does not, it proceeds with anonymous DH.

Of course, if the KDC publishes any kind of public key in the first
place, you could skip DH and just use e.g. ElGamal for unilateral
pre-authentication.

Cheers,

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 2 Dec 2002 07:57:20 -0800

Back in February I pushed hard for this.  It's easy to define and will
work for all cases where a client has a host key (usually used for
initial authentication of users to the client).

This method does not cover key-less clients, unfortunately - for that
we'll need to add public crypto (so KDCs can sign responses which all
clients can validate) or EKE, or SRP or some derivative.  The latter
don't require that the client have access to realms' public keys and so
are the best general solution.

The specific technical details of how to do what you call DCE-style
pre-auth are simple to hash out.  We could even do it without defining
any new ASN.1 types (e.g., if an AS-REQ contains a pa-enc-timestamp and
a pa-tgs-req then expect the timestamp to be encrypted with the client
principal's long term key then re-encrypted with the session key of the
ticket in the ap-req embedded in the pa-tgs-req).

Cheers,

Nico

---

From: Sam Hartman <[email-masked]>
Date: Mon, 02 Dec 2002 14:47:57 -0500

ONe thing to consider.  We could probably drop a round trip if we
limit ourselves to the case where we're doing an AS request against
the local KDC.  Instead of including an ap-req, include an option that
gives the principal name to use.

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 2 Dec 2002 11:55:06 -0800

> gives the principal name to use.

Indeed.

Nico
--