Date: Tue, 3 Aug 2010 01:13:08 +0400 From: Solar Designer <solar@...nwall.com> To: john-users@...ts.openwall.com Subject: Re: KoreLogic Contest.. first set of stats/rules On Mon, Aug 02, 2010 at 12:14:11PM +0600, Murat D. Kadirov wrote: > Teams were able to crack 0 ORACLE password hashes. 1000 were left uncracked > > How is this possible? Uncertain hash type. Uncertain usernames (which are used as salts). Not a single very weak password - every one in this 1000 would take a long while to crack. Also, this was not worth the effort anyway: the points were being awarded regardless of hash type and password complexity, so it made sense to focus on clear targets, faster hashes, and simpler passwords. It was a likely guess that those hashes were Oracle 10. (Other guesses were old MySQL, varieties of SAP, and partial or reversed hashes of other types.) It was one of the guesses that the usernames provided were in fact valid, but they looked like they were not - all 1000 were just "user" (written in lowercase), which looked like a placeholder and was not typical for Oracle. (We tried several other usernames as well.) I've actually tried submitting one of the hashes to this online FPGA-based Oracle password hash cracker: http://ops.conus.info:669/ I kept the username at "USER" (uppercase because of the algorithm). I submitted on the first day, the cracker processed it on the second day of the contest. It failed to crack the hash (the status is "UNSOLVED"). Indeed, it only does an exhaustive search up to length 8, but these passwords were all length 10 and 11... Perhaps teams would crack some of them if they knew for sure the hashes were Oracle 10 and the usernames were valid. The matching usernames (same on all 1000) would have helped... but there was a bug in recent jumbo patches, which I've just identified. The bug, while being in a "completely unrelated" part of the program, caused matching salts not to be detected for this hash type. Specifically, it was a coding error and a wrong assumption (so two bugs in total) in the implementation of this option: --salt-list=SALT[,SALT,..] load just the specified salt(s) The coding error resulted in the corresponding checks being run even if the option was not specified. The wrong assumption was in calling a format's salt() without a preceding call to valid() - that is, salt() was sometimes called on strings that were not valid(), but per conventions used in JtR everything in a "format" definition besides valid() may assume that it is only called on what was previously validated with valid(). And oracle_fmt.c's salt() did. None of this was fatal, but it did slow things down by up to 1000 times on the contest hashes. (There was also a third error in the implementation of the above option, which did not affect anything this time: the code assumed that "binary salts" could be treated as NUL-terminated strings, but this does not have to be the case. Overall, this option is plain wrong and will only happen to work right in some very special cases. Maybe I shouldn't have mass-merged that contributed patch into jumbo... although jumbo is just that - a pile of almost everything that people contributed.) Now this is a useful outcome of the contest! I wonder if the KoreLogic folks knowingly did not report the misbehavior before the contest. ;-) Overall, this might have been fun and a curious experiment on the teams, but it might have served to "prove" that Oracle is "unbreakable", even though the scenario had little to do with reality. Usually, an attacker knows if they deal with Oracle hashes. Usually, the usernames are known reliably. Usually, most passwords are a lot weaker (as it can be seen on that FPGA-based Oracle cracker page - many passwords are getting successfully cracked, often in seconds). Usually, the usernames are not all the same (although there are matching ones across different systems). Another curious detail is that I guess this had more of an impact on small teams (well, on those who nevertheless tried to attack all hash types) than it did on larger ones. The time wasted on this probably did not grow linearly with team size. Our team was small, so these Oracle hashes did reduce the number of other hashes we cracked significantly - e.g., 1-2 hours of my time over the 48 hours period (minus time needed to sleep, eat, take care of clients' urgent requests, etc.) was significant (I know specific things I'd manage to fit in that time, which would have helped crack more of other hashes). 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.