[<prev] [next>] [day] [month] [year] [list]
Message-ID: <50AEA498.30306@gmail.com>
Date: Thu, 22 Nov 2012 23:18:00 +0100
From: buawig <buawig@...il.com>
To: john-users@...ts.openwall.com
Subject: Reducing the effort to crack strong (and weak) kerberos etypes
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
Hi,
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:
http://www.openwall.com/lists/john-users/2012/11/18/5
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
attempt).
b) (try to) reduce the number of PBKDF2 iteration (default: 4096)
this has the potential to reduce the 'cost' of PBKDF2 when doing the
precomputation.
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)
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJQrqSYAAoJEJeRHQyF0ukMKUUQAKeSfUSOAAJLz+Nq4Ao88wCs
5wj5iihPX/khB6u6gIXinrOPmKmKTbrKF2WgOlulJJMn3u3NgVY5Zr4Qk0W8RfI0
QH79OuHtFg6da7YruJYezdytpqYPXdJAiOaiXFhusZJh0mKWtIy+oP41DlzzQ+xj
+hk+H4Cqne8kLBGRpPx8qA87uO+MWLRs/+Rav6oJoIevMst0nsrs5AgSp9Ego5sA
Lzqer1mtWskDKxgLtwyhcWphmnb40TDG5lu2VRiogOre2m4E3ehck5P7R7KJwLDw
Vm2+Tb9NfeneIlAUDCA6TOpbS7fwodfaI4N20M5O4Ik/wDqaup8ZBTTOLWHkiuxp
tMXrZ0NxOeXvAnpFu6c/rh8ZrLWywdlbeDcNAjbmyqdzfYS75R+7v3DbBm5yhG4Z
7N67G1rBa6LijeZARKi/hth6DQxthTn10rpcSBkxJZqXaS7rxJ1SZ2/Z+V0+8Onm
eE2mqMs8SRpFJSo6Af4JQnRz6sS31bAMCJNXemaPrWg277tjwvI/HgEVSbO/NmRk
aOuaphArdokStHweU6LXCvBJjjD7tyXFhU3Y0aYHhKP+iaG5/d8HNX64GBlLDOa+
epZCO6dV25NvDzzvqmckWkxNihZzm1pKaB+asn7/XjvgdbFwCfVaTNUpKIyWRiC0
NaGGT3EU9E6+vOBescx7
=VUw7
-----END PGP SIGNATURE-----
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
