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

[David Lawler Christiansen (NT)]

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.  

2. Your Background comments tying NTLM[v2] to Kerberos5 and krb4 are
misleading, either by design or due to error.  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
"Microsoft hasn't solved offline password-guessing", which may be true.
However, the quote you've selected doesn't say we have.

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!"  :-)

Yes, this is a potential vulnerability.  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.

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.  You could add that using a smartcard (instead of
passwords) has significant security gains over password authentication.
I'm not sure if it makes your point, though, since you seem to be most
concerned with attacking encrypted-timestamp preauth.

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).

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...".

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

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.

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
>