most systems do not 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 actually calculating and checking an encrypted version of the password you entered. this encrypted version or hash of your password appears to be a ran- dom string of characters and numbers.
different systems use different hashing algorithms to create their password hashes. most systems store their password hashes in a single location. this hash file usually contains the encrypted passwords for several users and sys- tem 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) is not enough to determine the plaintext. this is because technically it is not 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.
ALERT!
Password Hint #1: Never, never, never use the same password for your local machine administrator as you do for your domain administrator account.
consider the following example. Assume that we have located a password hash and we want to discover the plaintext value. it is important to understand that in most cases we need the plaintext password, not the hashed password. entering the hashed value into the system will not get us access because this would simply cause the system to hash the hash (which is obviously incor- rect). in order 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 plain- text 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 outlined 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 is 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 bench- mark your computer’s performance. this benchmark will be measured in cracks per second (c/s). You can run this by navigating to the following direc- tory /pentest/passwords/jtr and running the following command:
./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 actually locked when the operating system boots up. this means that while the os is running we do not 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 is 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 have physical access to the system, we can also boot to an alternate
operating system like Backtrack. By booting our target to an alternate operating system, we are able to bypass the windows sAm lock. this is possible because the windows os never starts, the lock never engages, and we are 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 Backtrack.
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 is important that you mount the correct drive as not all systems will have a /dev/sda1. if you are 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 mount. 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
if you are unsure about how to use the mount command or locate the proper drive, please review the linux man pages for the mount command or practice your newly acquired google skills from step 1.
once you have successfully mounted the local drive in Backtrack, you will be able to browse the windows “c:\” drive. You should now 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” com- mand in the terminal window, you should see the sAm file. figure 4.8 shows a screenshot displaying each of the steps required to locate the sAm file (assum- ing you have a /mnt/sda1 directory already created).
in step 1 we issue the “fdisk –l” command to view the available drives 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 con- tents of the current folder. finally, step 6 shows the sAm file.
now that we have 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. in order 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, followed 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” command will save the results to a file called “hashes.txt” in Backtrack’s /tmp directory. figure 4.9 shows a screenshot of the samdump2 command and dis- plays the contents of the hashes.txt file.
now that we have the password hashes saved, we need to transfer them off the live Backtrack 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 are not persistent. this means when you reboot the target machine all the files you created in the Backtrack disk will be gone for good!
now that you have a copy of the password hashes, you can begin the process of cracking the passwords. to accomplish this task, we will 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/ fIGURE 4.8
john. Before we begin utilizing John the ripper, it is important that you under- stand 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 pass- word. this is because technically if we hash the word “Password” and “pass- word,” even though 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 letters, 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 in with null values. if a password is greater than 14 characters, 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 stored 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 its 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 favorite 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!@#$.
fIGURE 4.9
Unfortunately for Ben, he is 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 remain- ing 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 drasti- cally 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 will still find systems which are utilizing and storing lm hashes. modern versions of windows do not use or 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 dic- tionary or by brute forcing letter combinations. As we discussed earlier, pass- word dictionaries are lists of words and letter combinations. one advantage of using a password dictionary is that it is very efficient. the main disadvantage of this technique is that if the exact password is not 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 unsuccess- ful, it will try “aa.” if that guess is unsuccessful, it will 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 is important to point out that brute forcing pass- words of significant length and cipher would take many lifetimes to crack. John the ripper is built into Backtrack. to run it, we can simply enter the fol- lowing command into a terminal:
john
invoking this command will actually run a script that will move us to the /pen- test/passwords/jtr directory. once inside the /pentest/passwords/jrt directory, we can issue the following command:
in the command above “./john” is used to invoke the password cracking John the ripper program. do not omit the “./” before the john command. this forces linux to run the program in the current directory. 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 file to a different location, you will need to change this path.
if your target machine is using ntlm hashes, you will need to add the “-f:nt” switch. in this case, the command would look like the following:
./john /tmp/hashes.txt –f: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 will display it to the screen. figure 4.10 shows the commands used to move into the John directory, running John the ripper, and the output of usernames and passwords that were cracked. Below you will find a brief recap of the steps used to crack windows passwords. it is important that you practice and fully understand how to complete each of the steps below. if you are 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 com- plete step 5, the actual cracking of the passwords, will vary depending 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:
1. shut down the target machine.