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.