Comments on "Crack Me If You Can"

Matt Weir asked me for my opinion, or even a blog post, on the debate over the KoreLogic "Crack Me If You Can" competition at Defcon 2010. Matt said that there were discussions on how well the passwords in the competition represented a real-world corporate environment. I've been doing pentesting as part of my job for 12-13 years now, but I'm not going to say that makes any kind of expert in this area. So with that in mind, let me give you my opinions.

No... Wait.. More stuff I need to say first:

1. KoreLogic: COOOOOL competition! (I was on vacation, no way to participate...)
2. #Defcon (and #Blackhat) I hope that I will get the opportunity to participate, or even present, at some time in the future
3. Matt: You're a PhD. On passwords. Asking for my opinion; I'm honored.
4. Participants in the contest: I bow before you. I hope to meet and greet some day!
5. To all others at websites, forums, twitter and RL: 41a28e701f473aadcf78eb32db13ba78 :-D

Ok, so; lets get started. No specific order, just as it keeps coming into my mind;

1. Password policy?
I can't see any info on the written password policy of fictional company X. I guess they would have one, right? Getting access to the written password policy is a kickstart for a blind pentest (which i don't really like to do under normal circumstances). IF they had a written password policy, even a kid should be able to social-engineer almost anyone at company X into giving it up on telephone. So for next years competition (...), make up a written policy. Most users will never read it anyway, and again most of them will only be compliant with the requirements that are "hardcoded" into the systems. However; for us password crackers who are going to overclock both cpus and brains to crack these things; it may aid us a little in our efforts. 

2. Default passwords?
I have NEVER EVER seen any company that have implemented their written password policy 100% correctly into their systems - at least not across all systems. An example requirement; change all default passwords. I have NEVER come across anyone who have gotten rid of all default passwords in their systems across the company. I mean; CHANGEONINSTALL and DBSNMP is missing in your plaintexts! ;-) In fact you don't mention the use of default passwords in your writeup on how the passwords were created.

3. Historical password hashes?
I did a blog post named "Why history may be bad for you". Please read it (and give my your opinions on it as well, if you've got the time). I hope you'll get the picture - I for one would like to see an LMNT.LST file from Cain as input to the competition. (I've got some cool data in the works on this, so stay with me)

4. Correctness of LM/NTLM hashes?
I think I've tried most LM/NTLM hash dumping tools available today, anything from the classic pwdump to the newest versions of L0phtCrack. I've reported on strange issues with fgdump for one example (still unresolved i think...), I've seen some of them not dumping historical hashes further back than generation_11 even when the policy said to do 20+ generations, while @WeldPond told me that even the newest version of L0phtCrack only dumps the current LM/NTLM hashes. So for hash dumping on Windows, i currently use Cain, which does 64-bit systems and historical hash dumps (at least up to and including generation_24). Putting 2 LM hashes into the list of NTLM hashes is bound to be frustrating - or the other way around. I've experienced it a couple of times, being able to crack/recover the passwords when switching the hashes around from the fgdump output. (Running thousands of LM and NTLM hashes through 1TB+ of rainbowtables does take some time..)

5.  Output formats (after cracking)
I *HATE* the classic pwdump output format (as used by L0phtcrack earlier, as well as others): Once somebody starts using semi-colons in their passwords, importing the file into OpenOffice Calc suddenly got harder. So i asked Mao, the author of Cain, to use TAB separation in Cains output files instead. MUCH BETTER. (I'm below n00b on programming, so i prefer KISS). I remember asking Elcomsoft (Hi Andrey!) to make a change in EDPR, so that unrecovered LM hashes would not be displayed by *******, since it could very well be that the user were using 7 asterisks as the first or second part of his password. (Small chance I must admit, but if you're insane and you know that your company uses EDPR for auditing passwords, why not have some fun?). Putting in a few semi-colons in the correct positions, and using asterisks might cause a few additional quirks depending on the password crackers being used.

6. SPACE is cool.
No, not NASA-style space, but the character SPACE (HEX:20). It's *FUN*. The list of unique plaintexts from your competition contains 54932 passwords, of which 251 uses space, ten of those passwords have space as the last character. I told a friend to start using space in his passwords, especially at the end of them. Suddenly i needed password crackers that would also give me the HEX value of the passwords, in order to verify them properly on screen. Small trick, lots of fun! Of course, you know somebody is poking fun at you (the in-house password cracker), when you hear the distinct sound of SPACE being hit multiple times during logins.... Having said that, it is VERY rarely that I find actual people using space as the last character of their passwords, usually it will be auto-generated passwords used by service accounts. Speaking of which;

7. Service and/or USER accounts?
You don't have much/any information on whether the password hash values belong to PEOPLE, or is a mix of both people and service account passwords. Personally i recommend any password policy to require 15+ character passwords for any service account, in order to avoid any chance of LM hashes being generated. Besides; bruteforcing becomes rather difficult. ;-) It doesn't take much brain power to understand that people will mostly do simple passwords, and we will do password patterns (add +1 to the two or four digits at the end of your password...). Being able to differentiate between PEOPLE passwords (hashes) and SERVICE hashes will benefit any password cracker.

8. Reusing usernames and passwords?
Although cracking all the passwords is a challenge, it is rather useless. Why crack, when you've got root? Renaming root may be difficult, and identifying the real Administrator account in AD still is possible. In other words; renaming default account names will in many cases just extend your life with a few seconds. However, pulling out a list of members of the Domain Administrators group in AD, and then finding thir corresponding non-admin regular-day-work accounts and hashes as well is nice. I mean; you're not supposed to reuse your passwords across multiple systems, right? Forget it. Admins do. Especially them, but others as well in fact. so without checking your lists; how much reuse of usernames and passwords across your various systems in fictional company X have you put into the mix here?

9. User/Account information
For absolutely any pentesting engagement involving Active Directory, i will try to obtain the output of (1) accounts within specific groups, especially domain admins, and (2) either myself or trick somebody into running the old but still working Dumpsec tool. You'll get usernames, full name, comments (almost always containing passwords or clues for some accounts), password_last_set (time/date), last_logon (time/date), accound disabled/locked_out etc. Why crack passwords for accounts you can't use anyway? If you think - or KNOW - that the written and/or technically implemented password policy has been changed during the last year or so, but some accounts haven't had their passwords changed for ... say 5-6-7-8 years? It will most definately aid in configuring your tool-of-choice for cracking the passwords. The social engineering part here is of course not to be forgotten as well, but for a competition as this it can't really be done realistically.

----

Darn... That's a lot of text already for a blogpost. Argh. I could go on and on and on and on and on...

Matt; just by flashing the plaintext list over the screen I get 2 feelings; one of epilepsy, the other of the passwords created for the competition being just a bit too complex for belonging in a real-world environment. However this will *heavily* depend on the type and size of the organisation (low/hightech, #employees), the written AND the technically implemented policy, advice on wordlists as well as a range of other features, limitations and so on. It may be a tough thing to say, but after all the years I've been looking into passwords, I think the bigger organisation the easier it will be to gain entry through bad passwords. I mean; obtain a list of account names (or guess the account creation logic), try out Summer2010 for all acounts, and I'll bet you get access. Hey, it's a complex password; mix-alpha-numeric and length 10! :-D (You'll probably be able to predict some of the coming passwords for this user as well.... ;-))

I believe the competition was a cool thing to do. It can most certainly be repeated, and it can also be extended in many ways. However i think such a competition serves better as N3RD fun for the likes of us who enjoys passwords just a little bit more than Joe Average.

Hm. Past midnight, and my turn to get up early in the morning with my daughter. Well, I hope this serves as a few comments from me Matt. To KoreLogic and all the others I've mentioned (or not), keep up the good work and continue to contribute. Questions and comments are most welcome!