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.