[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20120805014738.GA12835@openwall.com>
Date: Sun, 5 Aug 2012 05:47:38 +0400
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Solar's writeup for Crack Me If You Can 2012
Hi,
This is my personal writeup for my participation on team john-users.
Aleksey is working on a team writeup.
Preparations
I was hoping to prepare much better, but in the end aside from the two
4-hour trial pseudo-contests I only found time to produce a contest
edition of JtR based on one previously prepared by magnum (thanks!) and
to slightly enhance my dirty hack master/slave Perl scripts that I
initially wrote the night before 2011's contest and did not touch since
then. The contest edition of JtR was not terribly different from the
publicly available bleeding-jumbo - in fact, that's what it was based
on, and we'll likely be rolling some of the changes in there now.
Hardware
Virtual cluster 1 (Russia): changing node count, up to 156 logical CPUs
by contest end. Started with just four 8-core machines, peaked at 168
logical CPUs for approx. 1 hour during the contest, then some servers
had to be removed as the password cracking was adversely affecting their
primary function because of details of the virtualization setup on those
specific machines. Some machines were dedicated to the contest (some
were CD/DVD/USB-booted, without hard drives). Some others were servers
doing other work as well (so the password cracking was a lowest priority
task on them). Overall, this probably included about 100 physical CPU
cores at about 2.5 GHz.
Virtual cluster 2 (US): similar to the above, setup about 12 hours into
the contest. 58 logical CPUs / 50 cores in its incarnation by contest
end. Of those, 12 were single-core EC2 instances provided by agap1 (who
happened to have those instances running anyway; we did not specifically
pay for any EC2 instances for this contest). One of the machines on
this cluster (8 cores / 16 logical) was also provided to Simon (so this
virtual cluster would slow down accordingly when Simon ran jobs there).
One 8-core machine with Solaris, used starting about 12 hours into the
contest for SunMD5 cracking only, with clean John the Ripper 1.7.9 (due
to its "generic crypt(3)" support). This one was a server under light
load (leaving maybe 7 cores for the password cracking on average).
Two quad-core machines (Q8400 and Core i7-2600K, stock clocks) used for
assorted small jobs. The latter one of these was only put to use for
the second day of the contest (24 hours total use or so).
I also made some use of our dev box with FX-8120, GTX 570, HD 7970 -
together with Frank - although mostly the box was for Frank's use, so I
mostly tried to make sure Frank used it optimally.
Software
John the Ripper, custom Perl and shell scripts.
Of other software (not password cracking specific), OpenSSH played a
particularly important role (port forwarding, forced commands in
authorized_keys, etc.)
Almost all machines ran Linux (mostly Owl, some CentOS, some Ubuntu),
almost all of them were x86-64, at least one was 32-bit x86. Two
8-cores ran FreeBSD on x86-64, and there was the 8-core Solaris machine
I already mentioned.
The virtual clusters
These were managed with the master/slave Perl scripts mentioned above,
and they relied on a feature of the contest edition of JtR ("one shot"
invocations).
The bigger cluster was primarily used for sha512crypt, distributing one
word per logical CPU per invocation (to be tested against all salts).
Some other hash types and other cracking modes were run on it briefly.
The smaller cluster was primarily used for bcrypt, in a similar fashion.
This one was half-wasted since the slave JtR builds had BF_X2 enabled
(which is the default), yet only one candidate password was being tested
at a time (for all salts). Unfortunately, a bug that was arguably
unreasonable to find/fix during the contest (and that was not found
before) prevented groups of multiple candidate passwords from being
tested per invocation in wordlist mode without rules (such as with a
pre-created wordlist with just the right candidate passwords to test,
following a certain pattern), and other cracking modes were just not
right given this contest's password patterns. (The bug was specific to
the special invocation mode of the contest edition.)
The same bug prevented the two clusters from being used efficiently
against md5crypt/apr1 and mscash2 hashes (since we normally use SIMD
code for those, and thus it expects having multiple candidate passwords
at a time). Instead, these other hashes were mostly attacked by other
team members, including on GPUs (although we had few GPUs in the team).
Password patterns
There were many. I recall, in part due to Simon's writeup, that I found
the kikugalanetNNNNNN one - and tested it against most hash types.
"kikugala" appeared at the top of our cracked passwords list (that is,
it was the most common cracked password), which got me curious. Turns
out that DES-crypt's truncation at 8 has helped here, making "kikugala"
alone appear so common.
I also attempted some passphrase searches using lists of common English
words along with my mix.pl script.
Comments on the contest
I could whine that the passwords distribution was unrealistic, etc. -
but I think that the teams got used to it by now. We did. :-) And it
appears that we started to like it. We can practice cracking typical
passwords using all those leaked password hash lists. In these
contests, however, we practice cracking what passwords/phrases could be.
For example, what they could be if passphrases were more common, etc.
This actually makes some sense, with potential for the future in mind.
As to scoring, I think the relative placement of the different hash
types was right, but the gap between md5crypt/apr1 and mscash2 was too
small. I think md5crypt/apr1 value could be reduced to 200, making this
gap 3x. There's a 20x difference in speed between them, so a 3x
difference in value would seem sane.
Some would argue that mscash2's value should have been higher, but I
disagree. mscash2 was in fact substantially easier to attack with GPUs
than the slower hashes.
If anything, maybe sha512crypt's value should be reduced somewhat for
further contests (although I think it was just right for this contest),
once teams have better publicly released GPU code for it. Ditto for
SunMD5: just a few days after the contest, JimF has produced working
SIMD code for SunMD5 (about 4.4x faster on CPU than what we had to use
during the contest).
The increased cost setting for bcrypt made the contest more realistic
since that's the setting actually used by many systems. That's good.
SunMD5 was a good challenge for the teams' ability to adapt, including
with code enhancements. I find it weird that no other team did.
Besides, those hashes could be attacked with readily available JtR
releases if run on Solaris - and this was documented. So all it would
take is installing Solaris in a VM (or even downloading a precreated VM
image from Oracle) and putting JtR on it - not requiring any programming
then (if a person on some team prefers to avoid programming and they
don't have anyone else to do the programming). Again, I am surprised
this was not done to a greater extent.
Maybe the too-high score for md5crypt/apr1 made attacking these hashes
so attractive that putting effort into SunMD5 instead did not appear to
be worthwhile to other teams.
Summary, and thanks
I'd like to thank KoreLogic for organizing this contest and running it
so professionally. Thank you!
I would also like to thank other john-users team members, and especially
Alexander Cherepanov and Aleksey Cherepanov who have helped administer
our contest server, submit our cracks to KoreLogic, etc. - thereby
letting me have more fun with actual password cracking than I was able
to in the 2011 and 2010 contests.
I enjoyed this contest. I especially enjoyed our team spirit this year
and the hard yet fair fight with team hashcat up till the end - thanks!
Alexander
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.
