title: Cracking passwords with John the Ripper course: intro_pentest section: Exploitation
It’s hard to imagine discussing a topic like the basics of hacking without discussing passwords and password cracking. No matter what we do or how far we advance, it appears that passwords remain the most popular way to protect data and allow access to systems. With this in mind, let’s take a brief detour to cover the basics of password cracking.
There are several reasons why a penetration tester would be interested in cracking passwords. First and foremost, this is a great technique for elevating and escalating privileges. Consider the following example: assume that you were able to compromise a target system but after logging in you discover that you have no rights on that system. No matter what you do, you’re unable to read and write to the target’s files and folders, and even worse, you are unable to install any new software. This is often the case when you get access to a low privileged account belonging to the "user" or "guest" group.
If the account you accessed has no or few rights, you’ll be unable to perform many of the required steps to further compromise the system.
Another reason for cracking passwords and escalating privileges is that many of the tools we run as penetration testers require administrative-level access to install and execute properly. It ain’t uncommon for penetration testers to find themselves in a situation where they were able to crack the local administrator password (the local admin account on a machine) and have this password to turn out to be exactly same password that the Network Administrator was using for the domain administrator account.
Never, never, never use the same password for your local machine administrator as you do for your domain administrator account.
If we can access the password hashes on a target machine, the chances are good that with enough time, John the Ripper (JtR), a password-cracking tool, can discover the plaintext version of a password. Password hashes are … and can be accesses remotely or locally. Regardless of how we access the hash file, the steps and tools required to crack the passwords remain the same. In its most basic form, password cracking consists of two parts:
Most systems don’t store your password as the plaintext value you enter, but rather they store an encrypted version of the password. This encrypted version is called a hash. For example, assume you pick a password “qwerty" ” (which is obviously a bad idea). When you log into your PC, you type your password “qwerty" to access the system. However, behind the scenes your computer is calculating and checking an encrypted version of the password you entered. This encrypted version or hash of your password appears to be a random string of characters and numbers.
"qwerty" encoded in MD5: d8578edf8458ce06fbc5bb76a58c5ca4
Different systems use different hashing algorithms to create their password hashes. Most systems store their hashes in a single location. This hash file usually contains the encrypted passwords for several users and system accounts. Unfortunately, gaining access to the password hashes is only half the battle because simply viewing or even memorizing a password hash (if such a thing were possible) ain’t enough to determine the plaintext. This is because technically it ain’t supposed to be possible to work backward from a hash to plaintext. By its definition, a hash, once encrypted, is never meant to be unencrypted.
Consider the following example: Assume that we’ve located a password hash, and we want to discover the plaintext value. It’s important to understand that in most cases we need the plaintext password, not the hashed password. Entering the hashed value into the system won’t get us access because this would simply cause the system to hash the hash (which is obviously incorrect). To discover the plaintext version of a password, we need to circle through a series of steps.
First, we select a hashing algorithm, next we pick a plaintext word, third we encrypt the plaintext word with the hashing algorithm and finally, we compare the output or hash of the chosen word with the hash from our target. If the hashes match we know the plaintext password because no two different plaintext words should produce the exact same hash.
Although this may seem like a clumsy, awkward or slow process for a human, computers specialize in tasks like this. Given the computing power available today, completing the four-step process outline above is trivial for a modern machine. The speed at which John the Ripper can generate password hashes will vary depending on the algorithm being used to create the hashes and the hardware that is running John the Ripper. It’s safe to say that even an average computer is capable of generating millions of Windows (LM) password guesses every second. John the Ripper includes a nifty feature that allows you to benchmark your computer’s performance. This benchmark will be measured in cracks per second (c/s). You can run this by opening a terminal window and issuing:
john --test
This will provide you with a list of performance metrics and let you know how efficient your system is at generating guesses based on your hardware and the algorithm being used to hash the passwords.
Before we can crack passwords, we first have to locate the password hash file.
As mentioned earlier, most systems store the encrypted password hashes in a
single location. In Windows-based systems, the hashes are stored in a special
file called the SAM (Security Account Manager) file. On NT-based Windows systems
including Windows 2000 and above, the SAM file is located in the
C:\Windows\System32\Config
directory. Now that we know the location of the SAM
file, we need to extract the password hashes from the file. Because the SAM file
holds some very important information, Microsoft has wisely added some
additional security features to help protect the file.
First the SAM file is locked when the operating system boots up. This means that while the OS is running we don’t have the ability to open or copy the SAM file. In addition to the lock, the entire SAM file is encrypted and not viewable.
Fortunately, there’s a way to bypass both of these restrictions. On a remote machine, we can use the Meterpreter and SAM Juicer to access the hashes on a live target. If we’ve physical access to the system, we can also boot to an alternative operating system like BlackArch. By booting our target to an alternate operating system, we’re able to bypass the Windows SAM lock. This is possible because the Windows OS never starts, the lock never engages, and we’re free to access the SAM file. Unfortunately, the SAM file is still encrypted, so we need to use a tool to access the hashes. Fortunately, the required tool is built into BlackArch.
After booting the target system to an alternate operating system, the first thing you need to do is to mount the local hard drive. Be sure to mount the drive containing the Windows folder. We can accomplish this by opening a terminal and typing:
mount /dev/sda1 /mnt/sda1
It’s important that you mount the correct drive as not all systems will have a
"/dev/sda1
". If you’re unsure about which drive to mount, you can run the
"fdisk -l
" command. The fdisk tool will list each of the drives available on
your target system and should help you determine which drive you need to mound.
You may also need to create a mount point in the “/mnt” directory. To do so, you
can simply use the mkdir
command.
mkdir /mnt/sda1
Once you have successfully mounted the local drive in BlackArch, you’ll be able
to browse the Windows “C:\
" drive. You should be able to navigate to the SAM
file. You can do so by typing the following command into a terminal window:
cd /mnt/sda1/Windows/system32/config
If everything has gone as planned, you should be in the directory containing the
SAM file. To view the contents of the current folder issue the "ls
" command
in the terminal window, you should see the SAM file.
In step 1 we issue the “fdisk -l
" command to view the available drive on the
local disk. In step 2, fdisk responds back by stating that there is a drive at
"/dev/sda1
". In step 3 we use this information to mount the drive into our "/mnt/sda1
"
folder so that we can access the local hard drive. Now that our drive is mounted
and available, in step 4, we move into the directory containing the SAM file by
using the "cd
" (change directory) command. In step 5 we verify that we are in
the proper directory by issuing the "ls
" command to list the contents of the
current folder. Finally, step 6 shows the SAM file.
Now that we’ve located the SAM file, we can use a tool called Samdump2 to extract the hashes. At this point, we have the ability to view and copy the SAM file, in effect overcoming the first security feature, but at this point the SAM file is still encrypted. To view an unencrypted copy of the SAM file, we need to run Samdump2. Samdump2 utilizes a file on the local machine called “system” to decrypt the SAM file. Fortunately, the “system” file is located in the same directory as the SAM file.
To run Samdump2, we issue the "samdump2
" command followed by the name and
location of the “system
" file, located by the name and location of the SAM
file we want to view. Recall that earlier we had issued the "cd
" command to
navigate to the "Windows/system32/config
" folder. At this point, we can
extract the contents of the SAM file by running the following command in a
terminal:
samdump2 system SAM > /tmp/hashes.txt
This will invoke the Samdump2 program and appending the “ > hashes.txt” will save the results to a file called “hashes.txt” in BlackArch’s /tmp directory.
Now that we have the password hashes saved, we need to transfer them off the live BlackArch disk. This can be done by simply e-mailing the hashes.txt file to yourself or inserting a thumb drive and creating a local copy of the hashes. Either way, make sure you save the hashes.txt file because you are working off a “live” CD and your changes ain’t persistent. This means that when you reboot all the files you created in the BlackArch disk will be gone.
Now that you have a copy of the password hashes, you can begin the process of cracking the passwords. To accomplish this task, we’ll use a tool called John the Ripper. Like each of the other tools we have examined, John The Ripper is available for free. You can download it by going to http://www.openwall.com/john. Before we begin utilizing John the Ripper, it’s important that you understand how Microsoft creates password hashes.
Originally Microsoft utilized a hashing algorithm called Lan Manager (or LM for short). LM hashes suffered from several key weaknesses that made password cracking a trivial task. First, when LM hashes are created, the entire password is converted to uppercase. Converting all the characters used in a password to uppercase is a fundamental flaw that greatly reduces the strength of any password. This is because technically if we hash the word “Password” and “password”, although they are only different by a single case of a single letter, these two words will produce a different hash output. However, because LM hashes convert every character to upper case, we greatly reduce the number of guesses we need to make. Instead of requiring an attacker to guess “Password”, “password”, “PASsword” and so on, with every possible combination of upper and lower case letter, the attacker only needs to make the single guess of “PASSWORD”.
To further compound this issue, every Lan Manager password is 14 characters in length. If a password is less than 14 characters, the missing letters are filled with null values. If a password is greater than 14 character, the password is truncated at 14 characters.
The final nail in the coffin of Lan Manager passwords (as if it needed another) is the fact that all sorted passwords, which are now 14 characters in length, actually get split in half and stored as two individual 7-character passwords. The length of a password is one source of strength; unfortunately, because of the LM design, the max password that needs to be cracked is 7 characters. John will actually attempt to crack each of the 7-character halves of the password individually and typically makes very short work out of it.
Take a moment to consider these flaws. When taken together, they represent quite a blow to the security of any system. Suppose our favourite Network Admin, Ben Owned is utilizing LM hashes on his Windows machine. He is aware of the dangers of weak passwords, so he creates the following password, which he believes is secure: SuperSecretPassword!@#$.
Unfortunately for Ben, he’s operating under a false sense of security. His complex password will actually undergo a series of changes that make it much less secure. First, the password is converted to all uppercase: SUPERSECRETPASSWORD!@#$. Next, the password is truncated to be exactly 14 characters, with any remaining letters simply discarded. The new password is: SUPERSECRETPAS. Finally, the password is broken into equal halves of 7 characters, each: SUPERSE and CRETPAS.
When a hacker or penetration tester gets ahold of Ben’s password, the attacker has to crack two simple, all-uppercase, 7-character passwords. That is a drastically simpler task than the original password of SuperSecretPassword!@#$.
Fortunately, Microsoft addressed these issues and now uses a much more secure algorithm called NTLM to create its password hashes. However, as a penetration tester you’ll still find systems which are utilizing and storing LM hashes. Modern versions of Windows don’t use nor store LM hashes by default; however, there are options to enable LM on these systems. This “feature” is implemented to support backward compatibility with legacy systems. As a side note, you should always upgrade or discontinue the use of any legacy software that requires you to use LM hashes. Old systems often put your entire network at risk
John the Ripper is capable of cracking passwords by using a password dictionary or by brute forcing letter combinations. As we discussed earlier, password dictionaries are lists of words and letter combinations. One advantage of using a password dictionary is that it’s very efficient. The main disadvantage of this technique is that if the exact password ain’t in the dictionary, John the Ripper will be unsuccessful. Another method for cracking passwords is to brute force letter combinations. Brute forcing letter combinations means that the password cracker will generate passwords in a sequential order until it has exhausted every possible combination. For example, the password cracker will begin by guessing the password as a single letter “a”. If that guess is unsuccessful, it’ll try with “aa”. If that guess is unsuccessful, it’ll move to “aaa” and so on. This process is typically much slower than a dictionary guessing attack, but the advantage is that given enough time, the password will eventually be found. If we try every letter in every possible combination, there is simply nowhere for a password to hide. However, it’s important to point out that brute forcing passwords of significant length and cipher would take many lifetimes to crack.
John the Ripper is built into BlackArch. To run it, we can simply enter the following command into a terminal:
john
You can issue the following command:
john /tmp/hashes.txt
In the command above “john” is used to invoke the password cracking John the Ripper program. The next command “/tmp/hashes.txt” is used to specify the location of the hashes that we extracted using Samdump2. If you saved your hashes.txt to a different location, you’ll need to change this path.
If your target machine is using NTLM hashes, you’ll need to add the
"--format=NT
" switch. In this case, the command would look like the
following:
john /tmp/hashes.txt --format=NT
After issuing the appropriate command to instruct John the Ripper to run, the program will attempt to crack the passwords contained in the hashes.txt file. When John is successful in finding a password, it’ll display it to the screen.
Below you’ll find a brief recap of the steps used to crack Windows passwords. It’s important that you practice and fully understand how to fully complete each of the steps below. If you’re given physical access to a machine, you should be able to complete steps 1-4 in less than five minutes. The time it takes to complete step 5, the actual cracking of the passwords, will vary on your resources and the quality or strength of the passwords you are cracking. You should also become comfortable enough with each of the steps that you can perform them without the aid of notes or a cheat sheet:
The process of cracking Linux and OSX password is much the same as the method
described above with a few slight modifications. Linux systems don’t use a SAM
file to store the password hashes. Rather the encrypted password hashes are
contained in a file called the “shadow” file which is located at: "/etc/shadow
"
However, before you can use the "/etc/shadow
" file with John the Ripper, it
must be joined with the "/etc/passwd
" file. In many respects this is similar
to how we had to use the “system” file with the SAM file to extract Windows
password hashes. John the Ripper includes a function to combine shadow and
password files so you can continue cracking the password. To accomplish this
task, you need to use the "unshadow
" command, which is built by default into
BlackArch. To accomplish this, issue the following command in a terminal:
unshadow /etc/passwd /etc/shadow > /tmp/linux_hashes.txt
This command will join the “/etc/passwd” with the “/etc/shadow” file and store the results in a file called “linux_hashes.txt” in the “/tmp” directory.
Now that we’ve extracted the hashes, we’re almost ready to begin cracking the Linux passwords. However, before we can start, we need to use a version of John the Ripper that supports cracking different types of password hashes. If you are using a wrong or unpatched version of John the Ripper, the program will return a message saying “No password hashes loaded”. Most modern Linux systems store their passwords using the SHA hashing algorithm. With this in mind, we have to choices: we can either patch the version of John the Ripper or download a prepatched version. If you are unfamiliar with the patching process and manually compiling Linux source code, it may be easier to find a prepatched version that supports SHA hashes. Once we’ve the correct version of John the Ripper running, we can complete this task by issuing the following command:
john /tmp/linux_hashes.txt
John the Ripper contains many more options and switches that can be used to greatly improve your cracking time and chances to success. You should see our Password Cracking course.