+- hashcat Forum (https://hashcat.net/forum)
+-- Forum: Misc (https://hashcat.net/forum/forum-15.html)
+--- Forum: General Talk (https://hashcat.net/forum/forum-33.html)
+--- Thread: ssha help (/thread-7185.html)
ssha help - pato - 01-10-2018
Hi all
I need some help regarding choosing the right decoding option.
The hash looks like this:
{SSHA}_HAAAAEGXXXXXXXXXXXXXXXXXXXXh+b6BtQtOkonrbeI=
I have several users on this system, interestingly, the password hash for all users starts with _HAAAA, but then is different for the rest.
In the product documentation I found this nice little information:
The password is an LDAP-v3 level password (RFC2307). The encryption method is hashed. For more details on the Secure Hash Algorithm 1 (SHA1), see RFC3174.
In addition to hashing, the password encryption is “salted” with a base64 (64-bit) scheme. See RFC3112, section 3.2 for more details
From the IETF document https://www.ietf.org/rfc/rfc3112.txt I found this part:
Given a user "joe" who's password is "mary" and a salt of "salt",
the authInfo field would be the base64 encoding of "salt" and the
authValue field would be the base64 encoding of the SHA1 digest of
"marysalt".
So, based on what I read, I should be able to extract the salt with a reverse of the base64?
Would that even speed up the cracking process or doesn't it matter at all?
Which hashmode would I need to select? As there are many variants for ssha inside hashcat.
Thanks for help
pato
RE: ssha help - atom - 01-10-2018
Cracking SSHA ldap passwords is supported with hashcat. Just choose the correct hash-mode.
RE: ssha help - pato - 01-10-2018
You don't happen to know which variant this is for sure?
I assume it could be 111, but am not sure.
RE: ssha help - philsmd - 01-10-2018
Example hashes can be found here: https://hashcat.net/wiki/doku.php?id=example_hashes
... and yes only -m 111 = nsldaps, SSHA-1(Base64), Netscape LDAP SSHA looks similar (has the, what we call, same signature. in your case {SSHA}...)
The problem is, that since the algorithm for -m 111 is base64 (sha1 ($pass . $salt) . $salt) in theory only the last part should be the same in the final hash... assuming that the same salt was used for all users. In your case, the first part seems to be equal amongs users, this contradicts with the algorithm of -m 111 if I'm not totally wrong.
Maybe you can give more details on where and how these hashes were extracted? Is this an ldap system ? Where are these hashes stored?
In theory the hashes could also use a very different algorithm or the hashes were manipulated/obfuscated somehow. Maybe you can give more details about the extraction/setup.
RE: ssha help - pato - 01-10-2018
They are from a DNS/DHCP appliance where the backup contains an XML based database file. Honestly I don't know if it's LDAP, because the appliance is locked and I can only access it's webinterface.
By reading the RFC on which it's based:
Example:
Given a user "joe" who's password is "mary" and a salt of "salt",
the authInfo field would be the base64 encoding of "salt" and the
authValue field would be the base64 encoding of the SHA1 digest of
"marysalt".
It means the start of the string is the base64 $salt, then comes the ($password:$salt), in base64, no?
Or in other words "$salt($password:$salt)" while ($password:$salt) is in sha1 and the whole string "$salt($password:$salt)" in base64. Assuming authInfo comes before authValue.
RE: ssha help - pato - 01-10-2018
And addition. What I did try is this:
echo HAAAAEGXXXXXXXXXXXXXXXXXXXXh+b6BtQtOkonrbeI= | base64 -d | xxd -p -c 40 | sed 's/.\{40\}/&:/'
1c0000004d5546dbb12XXXXXXXXe94dcea77dacc:c0da91d0XXXXXXXXb7b81
So based on my assumptions, 1c0000004 is probably the salt, as this is the same string for all password when the base64 is reversed, converted to hex and added a : after 40 signs. Not sure if I made this correct though.