RE: Password Cracking Challenge...

• Previous message: optikool_at_psyfreakz.org: "Re: Some help With BOF Exploits Writing. - EAX ?!"
• Maybe in reply to: Ronish Mehta: "Password Cracking Challenge..."
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

To: vuln-dev@securityfocus.com
Date: Thu, 31 Jul 2003 11:37:51 -0700

> From: Ronish Mehta [mailto:sf_mail_sbm@yahoo.com]
> Sent: Thursday, July 31, 2003 1:20 AM
>
> Application does not allow to put smaller passwords
>
> Password0 - D5FBB0C7C20D9CE79D3B837BD6FB3505
> Password3 - D5FBB0C7C20D9CE7B872B3A0BD587B8D

These appear to confirm various speculations that the app uses a 64-bit
block algorithm of some sort, but aside from that they don't help much.
(Note that they also indicate that the algorithm doesn't use salt, which
suggests that the author wasn't very knowledgable about security matters,
which is in your favor.)

Your original note contained one password of 7 characters ("QUALITY") and
one of 8 ("Cr@ckM3!"). How short a password will the application allow? If
I were serious about analyzing this algorithm (which I'm not; it doesn't
appear to be trivial, and anything harder is definitely not in my job
description), I'd probably generate several hashes using the shortest
password the application would accept; first a pair where only the first
character varied, then a pair where only the second character varied, and so
forth. I'd also try things like varying the case of one character to make
sure the algorithm doesn't fold case.

But that's just to get started. Analyzing an unknown algorithm from
plaintext / ciphertext pairs is a lot of work. In some cases the analyst
gets lucky: the algorithm is weak and a bit of poking around combined with a
guess or two reveals enough that the rest can be figured out without too
much work. But often even the specifics of weak algorithms are hard to
deduce from this kind of black-box inspection. It can be done - doing it is
a major industry, in fact - but in general it's not easy.

> I posted
> this because i need to make a password audit for weak
> passwords, I have full access to the database this is
> how i get access to the hashes!

So you're trying to mount an offline dictionary attack. (Whatever its
motives, authorized or not, from the system's viewpoint it's an attack.)
The fact that the algorithm apparently isn't salted is useful; it reduces
your dictionary storage requirement (there's only one possible hash for
every password).

> We do not have access to the source code, so i can;t
> figure out the algorithm

Since you have the binary, it'd almost certainly be easier to
reverse-engineer it from that, than deduce it by looking at plaintext and
hash pairs (even with the advantage of chosen plaintexts). Debug the app
when it's creating hashes. Figure out where that happens. Disassemble the
relevant code. Analyze it.

In fact, once you've disassembled the relevant code, you can probably
reimplement it in a quick hash generator without understanding exactly what
it does. So long as it takes plaintext and grinds out the correct hash,
you're good to go. Filter your dictionary of weak passwords through it and
you've got a dictionary of weak password hashes.

-- 
Michael Wojcik
Principal Software Systems Developer, Micro Focus

• Previous message: optikool_at_psyfreakz.org: "Re: Some help With BOF Exploits Writing. - EAX ?!"
• Maybe in reply to: Ronish Mehta: "Password Cracking Challenge..."
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]