Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [day] [month] [year] [list]
Date: Thu, 22 Nov 2012 23:18:00 +0100
From: buawig <>
Subject: Reducing the effort to crack strong (and weak) kerberos etypes

Hash: SHA512


thanks to Dhiru Kholia john supports* offline bruteforce attacks against
modern Windows Kerberos environments now (actually not limited to
Windows). More generally speaking Dhiru implemented john support for
Kerberos encryption type 18: aes256-cts-hmac-sha1-96 specified in RFC3962

*) not released in any john or -jumbo version yet but you can find the C
file for that format here:

The current cracking speed for etype 18 is ~300-400 c/s (per core).

Assuming admins did their homework and disabled all non-AES based
etypes, the attacker has to deal with etype 18 or 17 (downgrade attacks
to "cheaper" ciphers are not feasible).

The computational effort to determine if a given password is actually
the correct one heavily depends on the PBKDF2 parameters iteration count
(and salt).

Network attack vectors to reduce the cracking effort:

a) make pre-computation of the string-to-key step (PBKDF2) possible by
manipulating the salt that is sent from the KDC to the client (this
attack is not limited to etype 18 but can theoretically be used with
others too)

The manipulation will cause login failures for the MitM victim but
obtaining a single PA_ENC_TIMESTAMP that used a known static salt is
enough to use precomputed AES keys (so we cause only one failed login

b) (try to)  reduce the number of PBKDF2 iteration (default: 4096)
	this has the potential to reduce the 'cost' of PBKDF2 when doing the

I've not seen this parameter (00 00 10 00, decimal: 4096) flying over
the wire yet but RFC3962 suggests it does (if it is a none-default value):
"The number of iterations is specified by the string-to-key parameters
   supplied. [...]
For environments where slower hardware is the norm, implementations
   of protocols such as Kerberos may wish to limit the number of
   iterations to prevent a spoofed response supplied by an attacker from
   consuming lots of client-side CPU time;"

What would be the theoretical speed-up (time-memory tradeoff) of using
precomputed AES keys (a) from a given password list if the PBKDF2 salt
were static and is accepted by the client?
(In that case I'd give john a list of AES keys to try instead of a list
of passwords.)

Could the current john support be adopted to output the AES keys that
were generated with a specific wordlist file and a known salt?
Maybe it would make more sense to separate that in a tool that does
just that (gen-krb-aes-keys?) and accepts 3 parameters:
salt string,
iteration count,
dictionary file
(optional: etype 17 or 18)



Powered by blists - more mailing lists

Your e-mail address:

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.