Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
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.