Paper: Feasibility of attacking Windows 2000 Kerberos Passwords <long>

[Frank O'Dwyer]

I am updating the paper to incorporate some of your comments and those of
others, should be up later today, I may update it further at the weekend.

Some detailed responses to your points I have included below:

""David Lawler Christiansen (NT)"" <DAVIDCHR at windows.microsoft.com> wrote in
message
news:4AEE3169443CDD4796CA8A00B02191CD05808A21 at win-msg-01.wingroup.windeploy.
ntdev.microsoft.com...
>
> Your paper is an interesting read-- thank you for forwarding it.  Some
> comments at first blush:
>
> 1. You have a number of quotations attributed to "typical comment from
> NT security mailing list".  Either don't quote them or positively
> identify the source.  The whole reason why people identify sources is to
> add validity and authenticity to the quote.  By not doing so, you might
> just as well have made it up.  If the quote is anonymous, IMHO you
> should identify it as such.

Those quotes are merely illustrative and if anyone doubts that they are
accurate, they can be verified using google, which is where I found them in
the first place.

> 2. Your Background comments tying NTLM[v2] to Kerberos5 and krb4 are
> misleading, either by design or due to error.

I don't think I was misleading at all, and don't much appreciate the
insinuation that I was misleading by design either. More below.

> The statement "it has
> long been known in the cryptographic community that it too does not
> solve dictionary or brute force attacks against a user's login password,
> even if pre-authentication is used." does not chain to the to-be-refuted
> statement "This makes offline password-guessing attacks very difficult."
> -- it's similar, but not a direct tie.  Your statement seems to be

My statement seems to be? In other words, I didn't actually say the
following, you just made it up.

> "Microsoft hasn't solved offline password-guessing", which may be true.
> However, the quote you've selected doesn't say we have.

No it just says it makes it "very difficult". Sounds like it strongly
implies a practical solution to me. Certainly misleading, and not as clear
as it would be to say this:

By default the KDC requires all accounts to use pre-authentication. "This
approach has many of the benefits needed to avoid password guessing attacks.
It is, however, still vulnerable to attackers who can listen to network
messages. This weakness is due to using the client's password to encrypt
verifiable plaintext [Loma 89]. An attacker can sniff the appropriate
requests and replies on the network, and then attack them offline." [DCE RFC
26, Joe Pato, referring to PADATA-ENC-TIMESTAMP]

Or are you just trying to fix my paper, and not your own?

I believe you are quibbling, but I have reworded it anyway.

> 3. "If pre-authentication is disabled for a given Windows account, then
> material for offline attack on that account can easily be obtained by a
> remote user."  In Microsoft meetings, I often catch people saying things
> like this, and my regular response is along the lines of "Thank you,
> Captain Obvious!"  :-)

Fair enough, and a side issue anyhow. Removed. Some might say that Captain
Obvious should be invited to more Micorosoft meetings though :)

> Yes, this is a potential vulnerability.

I see. *This* is a potential vulnerability. What about the vulnerability to
a potential "l0phtcrack4" that sniffs the LAN and rips W2K passwords. You
don't say much about that. Is that any kind of vulnerability do you think?
(Yes, it could rip the passwords of other krb5 implementations *as well*.)

> However, disabling preauth is
> not something that Administrators are expected to do unless they need to
> interoperate with a Non-MS Kerberos implementation that DOESN'T support
> preauth.  If they need that, then they're already vulnerable and we're
> not adding any new vulnerability to their existing threat matrix.  This
> is, AFAICT, the only reason that a non-MS Realm would enable this
> setting too.
>
> A simple analogy to this is that if you have locks, but don't lock your
> front door, then you have only yourself to blame if someone breaks into
> your house.  We built the locks.  We even locked the door by default.
> In this scenario, the Admin (either through incompetence/stupidity or
> the need to support a very old implementation of krb5) has deliberately
> removed the locks.

Agreed.

> 4. Suggestions under "What can be done":  You have a number of good
> ideas, most of which we already recommend to administrators, if I
> remember correctly.

Recommend? What happened to building in the locks and enabling them by
default? Sounded like a cool idea to me.

> You could add that using a smartcard (instead of
> passwords) has significant security gains over password authentication.

I could, and Microsoft could fix it's white paper and close the security
hole while I do that.

I already mentioned smartcards (tokens, public key based logon) by the way.
I have made this more explicit now.

> I'm not sure if it makes your point, though, since you seem to be most
> concerned with attacking encrypted-timestamp preauth.

This as a comment on a list of suggested fixes. I could "seem" to be more
concerned about something else if you like, but it won't fix the problem.

> 5. "Implement a strong password policy".  Expand on this: Win2k, like
> many OS's, supports a password filtration mechanism that can allow
> administrative validation of the password in an arbitrarily complex
> manner.  In addition to the conventional win2k safeguards you list, such
> as minimum/maximum password age, minimum password length, this can
> enforce that passwords do not contain dictionary-attackable words or
> phrases, and can require that minimal guidelines for password complexity
> actually be met.  A DC could require that passwords contain at least one
> upper, one lower-case character, a certain quantity of numbers and
> symbols.  In addition, it is possible to enforce that passwords not be
> cryptographically similar to previous passwords in the password history
> (this prevents people from choosing incremental, but otherwise
> policy-compliant, passwords).

Done.

> IIRC, other krb5 implementations have this capacity as well.
>
> 6. "sniffer detectors" are not very reliable.  Yeah, it's better than
> nothing, but not by much.
>
> 7. physical security is already a requirement to guarantee security for
> *any* OS.  Never hurts repeating, but your paper makes it sound like
> this is a new thing.
>
> 8. "Estimated Timings".  Do you have theoretical timings for any of the
> other cryptosystems that Win2K uses in Kerberos?  For example, is
> DES-CBC-CRC/MD5 (the etype we use for interoping with other
> implementations) more or less vulnerable than RC4-HMAC?  How would this
> compare to 3DES?  You might also go further to explain the methods you
> used to estimate the timings, and more explicitly suggest the linkage
> between required maximum password age and the estimated crack-time--
> "since brute-forcing [a-zA-Z0-9]^8 takes almost a year on a pentium
> farm, you might consider making the password age 100 days...".

No, I just looked at the default implementation that is used in W2K. I think
if W2K Kerberos login changes were picked at random worldwide, then it would
be more likely for the picker to be struck by lightning than to find the
exchange using anything other than RC4-HMAC. It's not that RC4-HMAC is
somehow weak, it's just that it's what's used.

> 9. I like the comment about increasing the iteration count for preauth
> computation.

It's not a great fix, mainly as it puts load on the KDC if there is a surge
of logins (e.g. in the morning). It only makes things N times harder as
well, whereas other options close down the timestamp avenue completely. But
yes, it is better than what's there now. I would prefer to see the existing
AS exchange run over SSL or similar, or a more secure preauth scheme.

> Incidentally, I think your paper would get wider attention if it
> attacked Kerberos5 as a whole, rather than focusing on the Windows
> implementation of it.  If your goal is to help the community by pointing
> out the flaws of a *very* popular authentication system, then the title
> (and hence, the distribution) should reflect that.  In this way, krb5
> administrators (in addition to Win2k ones) are likely to read it and
> actually implement the suggestions you note in the "What can be done"
> section.  Just my humble opinion, though.

There are already many papers that discuss krb5 as a whole, and anyone is
free to produce a different paper if they feel it's needed. Come to that,
you or anyone at Microsoft can write a more generic paper if you really feel
that strongly about it. Writing more papers and changing titles isn't going
to fix any code.

Me, I wrote a paper with Windows 2000 passwords in the title so that people
who do know that they use W2K passwords, but who do not know Kerberos from a
hole in the ground might realise that "yes, this means you". I have done my
best to point out that the problem is not unique to the MS implementation,
and have gone through the paper again to try and remove anything that might
be taken as an implication that it is. I am also happy to link to
clarifications and what have you that anyone else writes.

Cheers,
Frank.

> Thanks again!
> -Dave
>
> -----
> This message or posting is provided "AS IS" with no warranties, and
> confers no rights.
> Any opinions or policies stated within are my own and do not necessarily
> constitute those of my employer.
> Harvesting of this address for purposes of bulk email (including "spam")
> is prohibited unless by my expressed prior request.  I retaliate
> viciously against spammers and spam sites.
>
>
> > -----Original Message-----
> > From: Frank O'Dwyer [mailto:fod at brd.ie]
> > Sent: Wednesday, March 06, 2002 4:14 AM
> > To: kerberos at mit.edu
> > Subject: Paper: Feasibility of attacking Windows 2000
> > Kerberos Passwords
> >
> >
> > I have uploaded a paper on the feasibility of dictionary
> > attacking/brute forcing Windows 2000 Kerberos passwords (via
> > sniffing the encrypted timestamp pre-authentication data)
> > that may be of interest.
> >
> > I am aware that the vulnerability will not be news to anyone
> > here, and the solutions are also pretty obvious, but as far
> > as I know this has not received much public discussion in the
> > context of W2K. It is also pretty clear that the public
> > perception of W2K Kerberos strength against this sort of
> > attack is not accurate.
> >
> > See
> > http://www.brd.ie/papers/w2kkrb/feasibility_of>
> _w2k_kerberos_attack.htm
> >
> > Cheers,
> > Frank O'Dwyer
> >
> >
> > ________________________________________________
> > Kerberos mailing list           Kerberos at mit.edu
> > http://mailman.mit.edu/mailman/listinfo/kerberos
> >
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> http://mailman.mit.edu/mailman/listinfo/kerberos
>