[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20100802211308.GA30565@openwall.com>
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.
