Wednesday, August 29, 2012
Labels:
JTR
,
password cracking
As an IT professional, I constantly research for troubleshooting information or to leverage the experience of others who've gone before me down dimly lit paths. Frustratingly, during this research I typically find bread crumbs along the trail until I find enough that I'm able to make proper sense of things. So, I'm going to leverage Google+ as a repository for the things I discover, and I'm making these posts public so that others can hopefully find the answers they seek in one search result.
With that explanation out of the way, I just wanted to share some stuff I learned about password-cracking tool John The Ripper (JTR) recently. In the fall of 2011, I joined my collegiate cyber challenge team in a regional competition.
One of the things that irritated me during the competition was that I couldn't get the password cracking process started for a root password we recovered off a linux system. Unfortunately, I didn't make any progress during the competition, but I made a note to revisit the issue and figure out why it wasn't working as expected, and here's what I found out so far:
1) The default download of JTR only uses DES decryption attempts. This is why the dang thing kept telling me "no password hashes loaded" during the competition. When a password is created in linux, if only the 'crypt' function is used with no switches - DES is used to encrypt the password.
2) If an encrypted password starts with a '$', that's a clear indication it was hashed using something stronger than DES. The password we recovered for the root account in the competition started with a '$':
root:$6$WTGPcLKM$mveC6wr7aZJWX9RmShBVbMMbygrx5QvqQqHp3LyWODOUaD61JFGKxhHE9J12oKXwr2eW0d22Crd./nv5J3cMP.:15068:0:99999:7:::
Since a hashing algorithm is used, and hashes are one-way, the windows version of JTR can't decrypt it. To recognize/'crack' it, you have to use hashing tables, aka rainbow tables. You're not technically cracking the password, you're just comparing your hash to a set of hashes that were generated from common passwords or randomly generated passwords of different character sets. When a match is found for your hash, they display the corresponding plain-text equivalent.
First, I had to determine what type of hash was used, and research revealed this useful info:
If salt is used in a password, a character string starting with the characters "$id$" followed by a string terminated by "$":
$id$salt$encrypted
then instead of using the DES machine, id identifies the encryption method used and this then determines how the rest of the password string is interpreted. The following values of id are supported:
ID | Method
-------------------------------------------------- -------
1 | MD5
2a | Blowfish (not in mainline glibc; added in some | Linux distributions)
5 | SHA-256 (since glibc 2.7)
6 | SHA-512 (since glibc 2.7)
So $5$salt$encrypted is an SHA-256 encoded password and $6$salt$encrypted is an SHA-512 encoded one.
Based on the password then, it appears it was hashed using SHA-512. Here's more:
"salt" stands for the up to 16 characters following "$id$" in the salt.
The encrypted part of the password string is the actual computed password. The size of this string is fixed:
MD5 | 22 characters
SHA-256 | 43 characters
SHA-512 | 86 characters
The characters in "salt" and "encrypted" are drawn from the set
[a–zA–Z0–9./]. In the SHA implementation the entire key is significant
(instead of only the first 8 bytes in MD5).
crypt('password', '\$6\$SALTSALT\$')"
The root account above has a salted password, which was hashed using SHA-512. Now we face an issue - after a couple more hours researching, the Windows version of JTR (1.7.0.1) does not include support for crypt(3) and SHA-512, meaning I would not be able to "crack" it. However, the Linux version of JTR (1.7.6 and up do). I haven't tested this in a Linux JTR build, but the importance of this post is more to point out that during a cyber challenge where time is of the essence, if you happen to come across a password in the format this one was, don't waste time trying to crack it!
Read More
Linux JTR is better
As an IT professional, I constantly research for troubleshooting information or to leverage the experience of others who've gone before me down dimly lit paths. Frustratingly, during this research I typically find bread crumbs along the trail until I find enough that I'm able to make proper sense of things. So, I'm going to leverage Google+ as a repository for the things I discover, and I'm making these posts public so that others can hopefully find the answers they seek in one search result.
With that explanation out of the way, I just wanted to share some stuff I learned about password-cracking tool John The Ripper (JTR) recently. In the fall of 2011, I joined my collegiate cyber challenge team in a regional competition.
One of the things that irritated me during the competition was that I couldn't get the password cracking process started for a root password we recovered off a linux system. Unfortunately, I didn't make any progress during the competition, but I made a note to revisit the issue and figure out why it wasn't working as expected, and here's what I found out so far:
1) The default download of JTR only uses DES decryption attempts. This is why the dang thing kept telling me "no password hashes loaded" during the competition. When a password is created in linux, if only the 'crypt' function is used with no switches - DES is used to encrypt the password.
2) If an encrypted password starts with a '$', that's a clear indication it was hashed using something stronger than DES. The password we recovered for the root account in the competition started with a '$':
root:$6$WTGPcLKM$mveC6wr7aZJWX9RmShBVbMMbygrx5QvqQqHp3LyWODOUaD61JFGKxhHE9J12oKXwr2eW0d22Crd./nv5J3cMP.:15068:0:99999:7:::
Since a hashing algorithm is used, and hashes are one-way, the windows version of JTR can't decrypt it. To recognize/'crack' it, you have to use hashing tables, aka rainbow tables. You're not technically cracking the password, you're just comparing your hash to a set of hashes that were generated from common passwords or randomly generated passwords of different character sets. When a match is found for your hash, they display the corresponding plain-text equivalent.
First, I had to determine what type of hash was used, and research revealed this useful info:
If salt is used in a password, a character string starting with the characters "$id$" followed by a string terminated by "$":
$id$salt$encrypted
then instead of using the DES machine, id identifies the encryption method used and this then determines how the rest of the password string is interpreted. The following values of id are supported:
ID | Method
-------------------------------------------------- -------
1 | MD5
2a | Blowfish (not in mainline glibc; added in some | Linux distributions)
5 | SHA-256 (since glibc 2.7)
6 | SHA-512 (since glibc 2.7)
So $5$salt$encrypted is an SHA-256 encoded password and $6$salt$encrypted is an SHA-512 encoded one.
Based on the password then, it appears it was hashed using SHA-512. Here's more:
"salt" stands for the up to 16 characters following "$id$" in the salt.
The encrypted part of the password string is the actual computed password. The size of this string is fixed:
MD5 | 22 characters
SHA-256 | 43 characters
SHA-512 | 86 characters
The characters in "salt" and "encrypted" are drawn from the set
[a–zA–Z0–9./]. In the SHA implementation the entire key is significant
(instead of only the first 8 bytes in MD5).
crypt('password', '\$6\$SALTSALT\$')"
The root account above has a salted password, which was hashed using SHA-512. Now we face an issue - after a couple more hours researching, the Windows version of JTR (1.7.0.1) does not include support for crypt(3) and SHA-512, meaning I would not be able to "crack" it. However, the Linux version of JTR (1.7.6 and up do). I haven't tested this in a Linux JTR build, but the importance of this post is more to point out that during a cyber challenge where time is of the essence, if you happen to come across a password in the format this one was, don't waste time trying to crack it!
Subscribe to:
Posts
(
Atom
)
