[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20080207131214.GA20845@openwall.com>
Date: Thu, 7 Feb 2008 16:12:14 +0300
From: Solar Designer <solar@...nwall.com>
To: john-users@...ts.openwall.com
Subject: Re: Cracking SunOne Directory Imap hashes?
On Thu, Feb 07, 2008 at 08:17:49PM +0800, auto245250@...hmail.com wrote:
> I was wondering whether anyone had any idea how to crack the following
> hashes retrieved from a SunOne Directory LDAP .db3 file or whether
> john has support for the following?
>
> Samples of the hashes attached.
>
> sunPortalNetmailIMAPPassword: BAIC5wM2MY4Sdcy/GhhBcP9OtqltfeafPku0
> sunPortalNetmailIMAPPassword: BAIC5wM2MY4Sdcxfd1ElZL7lr9WEOOJCBAIF
JtR supports some LDAP server hashes, such as Unix crypt(3) hashes when
used with LDAP, as well as {SHA} and {SSHA} hashes (these require
unofficial patches), but the samples you've provided look unfamiliar to
me, and Google is of little help.
Assuming that the above are base64 encodings, I get the following
sequences of bytes after decoding:
04 02 02
e7 03 36 31 8e 12 75 cc
bf 1a 18 41 70 ff 4e b6 a9 6d 7d e6 9f 3e 4b b4
for the first string, and:
04 02 02
e7 03 36 31 8e 12 75 cc
5f 77 51 25 64 be e5 af d5 84 38 e2 42 04 02 05
for the second one.
I've introduced line breaks to illustrate my guess: 3 bytes of flags
(hash or encryption type ID), 8 bytes of salt or key, and finally 16
bytes of hash (MD4 or MD5?) or encrypted data.
With Google, I found another sample:
http://www.uwo.ca/its/projects/JES/ldap/schema/ims/user.ldif
This one has:
userPassword={crypt}N2lLskrERiKW6
and:
sunPortalNetmailIMAPPassword=AQICE3lOIPXYpAp08RLd0cfBeu+VL/d5c3xn
There's a chance that the password is the same, in which case
successfully cracking the Unix password hash might make it much easier
to try different algorithms against the unknown hash or encryption
scheme. Anyway, this new sample decodes to:
01 02 02
13 79 4e 20 f5 d8 a4 0a
74 f1 12 dd d1 c7 c1 7a ef 95 2f f7 79 73 7c 67
As you can see, everything is different, but the first 3 bytes also look
like they are flags that identify how the rest should be interpreted.
Maybe there's no 8+16 bytes split this time.
Of course, another way to figure this out would be by reverse-engineering
the LDAP server program binary (or is the source code publicly available?)
Maybe someone else can provide more info and/or continue the research
from this point on.
--
Alexander Peslyak <solar at openwall.com>
GPG key ID: 5B341F15 fp: B3FB 63F4 D7A3 BCCC 6F6E FC55 A2FC 027C 5B34 1F15
http://www.openwall.com - bringing security into open computing environments
--
To unsubscribe, e-mail john-users-unsubscribe@...ts.openwall.com and reply
to the automated confirmation request that will be sent to you.
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.
