SBN – Analysis of Password Cracking Techniques – Part 2

So I figure I probably should get around to looking at the passwords in this list, since password cracking techniques are the focus of this blog…

First though, a real quick definition. I needed to decide what to call the various parties involved in this whole shenanigans. For example, when I’m talking about the ‘hackers’, am I referring to the people collecting stolen credit card data who belonged to the board, or the people who hacked Likewise, if I use the term criminals, that could refer to both groups as well. Therefore, in my blog posts I’m going to use the following terms to refer to the two groups:
  • Carders/Users: The people who belonged to the board. Normally I would also use the term ‘victims’, but I don’t want to honor them with that title.
  • Hackers/Attackers: The people who broke into the forum and posted the data online.
Ok, now that we have that out of the way, the rest of this post is going to be broken up into four parts:
  1. Executive Summary
  2. Brief Description of the Password List
  3. General Observations
  4. Setting Up a Password Cracker to Target Salted Sha1 Hashes
More in-depth analysis will have to wait till later since I need more time to go through the data. Also, I’m moving up to the D.C. area in a week to look for a job/start interviewing, so large scale password cracking sessions are not really feasible for me to perform right now.
-BTW, if you have a job opening please feel free to contact me.
Finally, I apologize but this post is going to be a bit more haphazard then the above outline implies, simply because it’s hard to talk about one aspect of this dataset without discussing other aspects as well.
Executive Summary:, on online forum for the buying and selling of stolen bank and credit card data, was broken into sometime before May 5th by vigilante hackers. On May 18th, the hackers then posted data about the users to various file sharing sites, (pastebin, rapidshare), which included IP addresses, usernames, e-mail addresses, and all of the saved forum posts. More significant to this report, the attackers also posted the users’ password hashes along with the plaintext passwords that the attackers had managed to crack. These passwords and password hashes provide significant data for researchers. From this data, we now know that cyber-criminals often select weak passwords. Furthermore, by analyzing these passwords we can develop better password cracking techniques that target the specific type of users, (criminals), whom law enforcement is the most interested in. This is an improvement from some of the other disclosed password datasets which were gathered from the general public. In addition, by looking at the passwords the attackers managed to crack, along with the passwords they failed to crack, we can gain a better understanding of the capabilities and techniques employed by hacker groups in real life attacks. This hacker group in particular appears to be quite proficient in password cracking techniques, possessing both the tools to attack salted SHA1 password hashes, and the ability to crack close to 53% of the passwords in the dataset.
Brief Description of the Password List(s):

The first thing that stands out is there are actually two lists of passwords present in the attacker’s write-up, though all of the password hashes are mixed together.
List 1)
Contains 1737 salted Sha1 password hashes using the following format:

This is the list that the attackers talked about and the list they attempted to crack passwords from. Of all the salted Sha1 password hashes, the attackers cracked 920 of them, (around 53%), during the course of an approximately two week period.
List 2)

Contains 2036 “one hundred and twenty eight bit” password hashes of unknown origin. Due to their length, the base password hash is most likely MD4 or MD5. It is unknown if the attackers knew of the existence of these separate hashes since they did not mention the second hashing function in their writeup or crack any of the passwords from this list. I’ve run some quick tests and these hashes do not appear to be a single round of MD4 or MD5, but probably instead are salted in some manner, and/or use multiple rounds of MD4/5. If a salt that was not the username was used, then it probably will be infeasible to crack very many of the passwords due to the salt not being included in the writeup. A few of the passwords might still be vulnerable though since the salt may be short enough to be brute-forced along with the guesses.

So the next question is, why were there two separate types of password hashes? The most likely explanation is that at some point in the past, the site administrators switched over to a new forum software, or upgraded their security settings. The old users were left with the original password hash, and users who joined up afterwards were assigned the newer password hash. The exact same thing happened when was hacked, leaving users who hadn’t logged into the site recently, exposed with only a simple MD5 hash protecting their password vs. the tougher phpbb3 hash.
The interesting thing is that in this case, a user’s hash probably was not changed to the new format when they logged into the site. This can be seen by comparing the user’s hash type to the IP addresses I talked about earlier. Of the 960 username/IP address combinations, 47 of the users had their password stored as the unknown hash, and 726 had their passwords stored as a salted Sha1 hash. You might notice that these two numbers did not add up to 960. There were 187 usernames that appeared in the IP logs but did not appear in either list of password hashes. I need to look into this more, but many of them might represent incorrect login attempts. A second option is the attackers may not have released all of the user password hashes, instead choosing to keep several for themselves to aid in future hacking attacks. I should probably analyze the forum posts to confirm if the hash type correlates to when the users became active, and if any of the users with missing password hashes actually posted previously on the forum.
Why yes, this is my “brief” description…
General Observations:

Observation 1) The attackers are very proficient in password cracking techniques
Level of Confidence: High
Discussion: The fact that the attacker could even target the salted Sha1 password hashes speaks to their competence. Most major password crackers, (Cain&Able, John the Ripper, L0phtcrack, etc), do not natively support that salt/hash combination. While John the Ripper has extensive support for a generic MD5 hashing function, where it is very easy to modify it to support all sorts of weird hash/salt combinations, that functionality has not yet been ported over to support Sha1 as well. So either they developed their own password cracker/workaround, (which isn’t as hard as you might think, as I’ll discuss later), or they had access to a less well known password cracker that supported that hash.
Question: Does anyone know of any password cracking program that does support Sha(username.password)?
In addition, since the passwords were salted with a unique salt per hash, this negates many common attacks like rainbow tables. Also, I don’t know of any online password cracking site that supports this hash format, since they can’t use hash lookup tables either. This means the attackers had to crack all of the password hashes themselves instead of relying on community resources.
Next, the fact they cracked 53% of the password hashes in a two week period speaks highly of the attacker’s skills. To put this in perspective, in the attack, the attacker had submitted unsalted MD5 password hashes to an online cracker and only managed to crack 24% of the passwords. In that case, while the hacker might have been very skilled in webpage attacks, they were pretty much at the script kiddie level when it came to cracking the passwords. While 53% might not sound that much more impressive, there is the fact that in the case, the hashes were salted with a unique salt. The ‘unique’ part is important since it means an attacker has to hash each guess independently against each target hash they are trying to crack.
For example, imagine a typical cracking session taking one hour to complete. If an attacker was attempting to crack three thousand unsalted password hashes, then it would take them one hour to run all of their guesses against the entire list. On the other hand, if those password hashes used a unique salt, the same attack would then take three thousand hours, or roughly four months. That’s a big difference. Assuming the attackers spent two weeks attempting to crack all 1737 salted Sha1 password hashes, that would mean the guesses they could make in their attack would be equivalent to a 11 minute cracking session against unsalted Sha1 passwords. Even assuming they cracked 50% of the password almost immediately, their cracking session would still be only equivalent to around 20 minutes of attacking unsalted hashes. In conclusion: cracking 53% of close to two thousand salted password hashes in a two week period is fairly impressive.
Observation 2) The Attackers did not user John the Ripper’s Incremental mode to brute force guesses.
Level of Confidence: High
Discussion: When I ran JtR’s incremental mode, using the default charset ‘All’, against the list, I almost immediately cracked a new password. Over a longer running session, I managed to crack even more.
Observation 3) The Attackers brute forced digits
Level of Confidence: Low/Medium Very Low
Edit March 28th 2001: I’ve since managed to crack the password ‘37721010’. It appears that most of the longer digit based passwords that the attackers had cracked were publicly available in lists of previously cracked password. I’m leaving my original discussion post up for posterity.
Discussion: I have not yet been able to crack any all-digit passwords that the attackers did not crack. Likewise, the attackers cracked several passwords such as ‘19930720’, where unless the attacker has outside information, or had run across that password earlier, it is unlikely to be cracked by any form of attack besides brute force.
Observation 4) The Attackers did not brute force alpha passwords longer than five characters long
Level of Confidence: High
Discussion: I have since managed to crack several passwords that were four lowercase characters long followed by two digits. Likewise I managed to crack several passwords that were six characters long all lowercase.
Observation 5) The attackers may have used knowledge from previous attacks to aid their password cracking sessions
Level of Confidence: Medium
Discussion: Let’s be honest, this isn’t their first time at the rodeo. It’s doubtful that is the first blackhat site these attackers have compromised. As we’ve seen from the ZF0 attacks, just because a website supports a tech-savy audience, doesn’t mean it stores their passwords securely. And as we all know, people re-use passwords … a lot. It’s quite possible that the attackers used passwords cracked from previous sites to in turn crack some of the passwords in the set. For example, one of the cracked passwords was ‘Nadia2312’. An unsalted MD5 hash of that same password was cracked via the Hashkiller site’s project Opencrack, on February 1st, 2010. While it could be a coincidence, I’d also like to point out that Hashkiller is a German based website. Other plaintext passwords in the list such as ‘123456r12’, and ‘01724776692’ also show up as being cracked by HashKiller and InsidePro in 2009. Note, this may just imply that the attackers used custom input dictionaries from these sites, and did not actually submit the original password hashes to them.
Setting Up a Password Cracker to Target Salted Sha1 Hashes
As I mentioned previously: I’m sure there’s already a password cracking program out there that can target salted Sha1 hashes, but I don’t know of it. Not to be deterred, I quickly modified an old password cracking program I had written a while ago to support the hash, (note I could have modified John the Ripper instead, but I’ll get to that in a bit). The hardest part was I didn’t realize that when you added the username as the salt, you had to lowercase the entire thing. That’s a couple of hours of my life I’d like back…
So testing this on my Mac laptop I expected to be able to make around 1000 guesses a second against the entire set of 1737 password hashes. I based this guess on benchmarking unsalted Sha1 hashes using John the Ripper, which gave me around 7,000,000 guesses a second. This would give me a maximum of 4029 guesses a second against the salted hashes. Throw in the overhead required to apply the salt plus my general programing sloppiness, and 1000 guesses a second sounded like a good number. So you can imagine my surprise when i was only ended up making around 80 guesses a second. Something’s not right here…
Well it turned out, the problem was I had used the OpenSSL implementation of the Sha1 hashing algorithm which is really slow compared to the version in John the Ripper. Rather than trying to jury rig it into my old password cracker, I then decided to work with John the Ripper instead, which is what I should have done in the first place.
Since I’m a bit lazy goal oriented, I didn’t bother to modify John the Ripper’s source code though. I was able to get away with this since the hashing algorithm only uses one round of Sha1. Let’s look at the hashing algorithm again:


The simplest way to do this would be to create a rule in JtR that would insert the username first. Such a rule would look like:


Which would insert Alice in front of all of your password guesses. Since we have close to two thousand usernames we are talking about though, that could get annoying having to create a rule for each one. This calls for the use of one of my favorite programs, Awk.
Awk, (and its sister Sed), is one of the best programs out there for quickly parsing and modifying files. It’s also very useful for creating word mangling rules on the fly for use in a password cracking session in conjunction with JtR’s stdin option. In that way, I sometimes use it much like MiddleChild, and in retrospect, I could easily have written MiddleChild in awk instead. For example I can create guesses using John the Ripper, pipe them into an awk script, and then pipe them back into John the Ripper where the guess will actually be hashed and compared against the target hashes. The above JtR rule could then be replaced with:

./john -wordlist=passwords.lst -session=cracking1 -rules -stdout | awk ‘{print “alice” $0}’ | ./john -stdin -format=raw-sha1

The advantage of this approach is that ‘alice’ will be automatically inserted in front of all the guesses/rules that the first instance of John the Ripper is generating. But wait, don’t we still have close to two thousand usernames we have to do this for? That would be one nasty command line. Luckily an Awk script can be run from a file with the -f option. And how do we create that file with all 1737 usernames? Well with Awk of course! The original format that the hashes were saved to in the writeup was:


Simply cat that file into Awk using the following command will create your Awk script for you.

cat carders_hashes.txt | awk -F : ‘{print”{print \”” tolower($1) “\”$0}”}’ > awk_add_usernames.txt

The -F tells it to use the ‘:’ as a seperator and the tolower() option lowercases the usernames. To run this whole thing just type:

./john -wordlist=passwords.lst -session=cracking1 -rules -stdout | awk -f awk_add_usernames.txt | ./john -stdin -format=raw-sha1

Using this setup, now I’m getting around 2,300 guesses a second which is much more respectable. There certainly is room for improvement though. First of all, John compares each hashed guess against all of the target hashes, instead of only the hash which the salt belongs too. Also, you have to clean up the cracked hashes file afterwards to remove the username from the plaintext password. But did I mention it works? As Miles said in the Lost finale, “I don’t believe in a lot of things, but I do believe in duct tape!”
Well, that about does it for now. Next up, analysis of the cracked passwords.

*** This is a Security Bloggers Network syndicated blog from Reusable Security authored by Matt Weir. Read the original post at: