help identify algo from kerio connect

[misha]

trying to decrypt mail user passwords generated by kerio connect.
I'm new to this stuff and dont know how to identify which algo is used.

I've created 3 users with same password(123456) and hashed outputs I get are salted:

D3S:3795d2bfad3b1a2abb53f8d6efdafc9ef0cdb947f0ff2757
D3S:3ad3d43e853c12453c39d1f2cdfaf835f0cdb947f0ff2757
D3S:3aec30b049f5ceddc7bdbbd8895dcaecf0cdb947f0ff2757

[DanielG]

If they store the passwords locally they seem to use "the strongly secure SHA format" 



https://manuals.gfi.com/en/kerio/connect...ritypolicy

They don't specify how they mangle/salt/alter the hash. They can do this in an infinte amount of ways, so it will be difficult to guess how they do it based only on 3 users with the same password.

They also seems to offer database wide encryption: https://manuals.gfi.com/en/kerio/connect...Encrypting

It is unclear how they make this encryption. But your string start with D3S, this might refer to Triple DES or just DES.

I tried to download the application and look if decompilation is an option (if it was a .net or Java application), but I get the error "Error 28103" when installing. But I think you need more information than 3 accounts with the same passwords.

[undeath]

Looks weird. Maybe it's coincidence that they all start with "3" but I'm not sure. Also the last part is fixed. Actual data is 32 characters, fixed part is 16 characters. That doesn't match any normal SHA checksum length. Either it's truncated SHA (whatever version) or it's not SHA at all.

[royce]

I just ran mdxfind for any supported hash, using '123456' as the only input - up to 2M rounds, with extended truncation search - against those hashes both with and without the static component. In theory, this would cover many different types and subtypes of hash. No hits.

I'd be curious in what kinds of hashes are generated if that "Store password" box is checked or unchecked.

According to http://www.kerio.com/content/control-rel...tory-older :

Version 8.4.0 October 14, 2014
* Passwords are now always stored in MS-CHAP v2 compatible format for Local users

Given the apparent normal integration of Kerio w/LDAP, I thought it could be LDAP SHA:

$ echo "123456" | test.pl passthrough 101
{SHA}fEqNCco3Yq9h5ZUglD3CZJT4lBs=
$ echo "123456" | test.pl passthrough 111
{SSHA}3sFdypnBr3JA0ujT1xeTpffgSEA0NDY3MzU0Mg==
$ echo fEqNCco3Yq9h5ZUglD3CZJT4lBs= | base64 -d | xxd -p
7c4a8d09ca3762af61e59520943dc26494f8941b
$ echo 3sFdypnBr3JA0ujT1xeTpffgSEA0NDY3MzU0Mg==  | base64 -d | xxd -p
dec15dca99c1af7240d2e8d3d71793a5f7e048403434363733353432

... but then again, since it changes each time, it must be salted, so that's probably not it.

At this point, unless we're missing something, I think we've established that it's probably not a hash type supported by hashcat.

[hops]

These D3S values are certainly encrypted, obfuscated or both. Why?


The authentication mechanisms APOP, CRAM-MD5 and DIGEST-MD5 all have something in common: The server has to know the password.
Still not convinced? As soon as you use the "strongly secure SHA format" (more on this later) the flag isPasswordReversible is set to false.



This means by default that is true and therefore the password is reversible.
I do not know the details but here are some interesting observations.
1. When I set the same password (123456) I get the same static suffix:

Code:

D3S:32fc936ccfab2e3fc7bdbbd8895dcaecf0cdb947f0ff2757
D3S:c36e4be2280fa230aa5d4a9de5aef11af0cdb947f0ff2757

2. It changes when using another password but across multiple accounts it stays the same. For example with password set to 1234567

Code:

D3S:10b2f2db66669ef03c39d1f2cdfaf835824e3e787e1f3307
D3S:7214614a6b3fc1932fd98c8404118268824e3e787e1f3307

3. The output size depends on the password length. Password: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA (32x A)

Code:

D3S:8742ddf7db1906c5d54ec948c500e587adfa4447eff8dc42adfa4447eff8dc42adfa4447eff8dc4298558bad76110b35
D3S:2962f547d408925a8948beccd54c660aadfa4447eff8dc42adfa4447eff8dc42adfa4447eff8dc4298558bad76110b35

Notice that the pattern adfa4447eff8dc repeats three times. This points in the direction of a block cipher with a block size of 8 bytes. So like DanielG mentioned DES or 3DES is highly likely.


Now coming back to the SHA hashes.
They have the "SHA:" prefix e.g.

Code:

SHA:9deb9254021335cf21e6aa91b568657b8e3b30ee92acab5aa44f0ac3

The algorithm used is PKBDF2-HMAC-SHA1 with 10000 iterations. And that is already supported by hashcat.
The first 16 hex chars are the salt and the rest the hash. Here are some lines of python to format the hashes for hashcat.

Code:

#!/usr/bin/env python2

import sys

for line in sys.stdin:
  line = line.rstrip()
  salt = line[:16].decode('hex').encode('base64').strip()
  hash = line[16:].decode('hex').encode('base64').strip()
  print "sha1:10000:%s:%s" % (salt, hash)

See it in action

Code:

$ echo 9deb9254021335cf21e6aa91b568657b8e3b30ee92acab5aa44f0ac3 | ./format.py
sha1:10000:neuSVAITNc8=:IeaqkbVoZXuOOzDukqyrWqRPCsM=
$ echo 123456 | ./hashcat --quiet -m 12000 sha1:10000:neuSVAITNc8=:IeaqkbVoZXuOOzDukqyrWqRPCsM=
sha1:10000:neuSVAITNc8=:IeaqkbVoZXuOOzDukqyrWqRPCsM=:123456

Now the interesting part is for every user there's a password history saved in users.cfg which is using this algorithm.
And when you create a new user the first entry in the password history is also the current password.

[undeath]

what's a little confusing is the random data at the beginning of the hash/encrypted data. Since the last bytes (probably encrypted or hashed ciphertext) are static this does not seem to be an encryption password/IV/salt.

Also interesting to note is that misha's and hops' static part for a known password are identical. This suggests the software is using a hardcoded encryption key.

[royce]

See also:
https://github.com/magnumripper/JohnTheR...Connect.md

[DanielG]

Awesome debugging powers to get that info! Seems to be 3DES indeed with key "61d0e54954733b8080808080808080808080808080808080".

Decoding D3S:8742ddf7db1906c5d54ec948c500e587adfa4447eff8dc42adfa4447eff8dc42adfa4447eff8dc4298558bad76110b35 (3. Password: 32x A) reveals 4173a95780AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA, maybe the beginning ("4173a95780") is some sort of user ID?

[hops]

That is indeed some awesome reverse engineering!

There's something interesting going on with the Key. 3DES has three keys and performs DES on the plaintext with encryption, decryption and encryption. Each operation using one of the keys.
To be exact it is enc(key3, dec(key2, enc(key1, pt))). Since key2 and key3 are the same (80808080808080) it cancels itself out.
Or in other words: we are left with DES and the key1 (61d0e54954733b80).

[DanielG]

Oh wow, why would they make that choice, using just DES and key "61d0e54954733b80" decodes it indeed.