John the Ripper | Anti-Hacker Tool Kit, Third Edition

< Day Day Up >

John the Ripper (http://www.openwall.com/John/) is probably the fastest, most versatile, and definitely one of the most popular password crackers available. It supports six different password hashing schemes that cover various flavors of Unix and the Windows LANMan hashes also known as NTLM (used by NT, 2000, and XP). It can use specialized wordlists or password rules based on character type and placement. It runs on at least 13 different operating systems and supports several processors, including special speed improvements for Pentium and RISC chips.

Implementation

First, we need to obtain and compile John. The latest version is John-1.6.35, but you will need to download both John-1.6.35.tar.gz and John-1.6.tar.gz (or the .zip equivalent for Windows). The 1.6.35 version does not contain all of the documentation and support files from the original 1.6 version. After untarring John-1.6.35 in your directory of choice, you will need to go to the /src subdirectory.

[root@hedwig]# tar zxvf John-1.6.35.tar.gz [root@hedwig]# tar zxvf John-1.6.tar.gz [root@hedwig]# cd John-1.6.35 [root@hedwig John-1.6.35]# cd src

The next command is simple: make OS name. For example, to build John in a Cygwin environment, you would type make win32-cygwin-x86-mmx. For you BSD folks, make freebsd-x86-mmx-elf should do nicely. Simply typing make with no arguments will display a list of all supported operating system and processor combinations.

[root@hedwig src]# make win32-cygwin-x86-mmx

John will then configure and build itself on your platform. When it has finished, the binaries and configuration files will be placed in the John-1.6.35/run directory. The development download does not include some necessary support files. You will need to extract these from the John-1.6.tar.gz file and place them in the /run subdirectory:

[root@hedwig]# cd John-1.6.35/run [root@hedwig run]# cp ../../John-1.6/run/all.chr . [root@hedwig run]# cp ../../John-1.6/run/alpha.chr . [root@hedwig run]# cp ../../John-1.6/run/digits.chr . [root@hedwig run]# cp ../../John-1.6/run/LANMan.chr . [root@hedwig run]# cp ../../John-1.6/run/password.lst .

If all has gone well, you should be able to test John. For the rest of the commands, we will assume that you are in the John-1.6.35/run directory. First, verify that John works by generating a baseline cracking speed for your system:

[root@hedwig run]# ./John –test Benchmarking: Traditional DES [32/32 BS]... DONE Many salts:     160307 c/s real, 161600 c/s virtual Only one salt:  144627 c/s real, 146978 c/s virtual     Benchmarking: BSDI DES (x725) [32/32 BS]... DONE Many salts:     5100 c/s real, 5280 c/s virtual Only one salt:  5241 c/s real, 5262 c/s virtual     Benchmarking: FreeBSD MD5 [32/32 X2]... DONE Raw:    3222 c/s real, 3248 c/s virtual     Benchmarking: OpenBSD Blowfish (x32) [32/32]... DONE Raw:    234 c/s real, 239 c/s virtual     Benchmarking: Kerberos AFS DES [24/32 4K]... DONE Short:  70348 c/s real, 72226 c/s virtual Long:   192409 c/s real, 200426 c/s virtual     Benchmarking: NT LM DES [32/32 BS]... DONE Raw:    1807744 c/s real, 1875253 c/s virtual

Two benchmarks deserve attention: FreeBSD MD5 and NT LM DES. The cracks per second (c/s) difference between these two is a factor of more than 500 (executed on a Mac OSX system). This means that a complete brute-force attack will take more than 500 times longer against password hashes on a FreeBSD system than against a Windows NT system! OpenBSD Blowfish takes even longer to brute force. This is how an encryption algorithm can be more resistant to brute-force attacks than another type of algorithm. Instead of saying that one algorithm is more secure than the other, it would be fairer to say that Blowfish is more resistant to a brute-force attack.

Cracking Passwords

Now let’s crack a password. John will accept three different password file formats. In reality, John can crack any password encrypted in one of the formats listed by the -test option. All you have to do is place it into one of the formats the application will accept. If you are using a Unix passwd file or output from the pwdump tool, which is mentioned later in this chapter, you should not have to modify the file format. Here are five different examples of password file formats that John knows how to interpret (the password hashes are in boldface):

root:rf5V5.Ce31sOE:0:0::
root:KbmTXiy.OxC.s:11668:0:99999:7:-1:-1:1075919134
root:$1$M9/GbWfv$sktn.4pPetd8zAwvhiB6.1:11668:0:99999:7:-1:-1:1075919134
root:$2a$06$v3LIuqqw0pX2M4iUnCVZcuyCTLX14lyGNngtGSH4/dCqPHK8RyAie:0:0::::::
Administrator:500:66bf9d4b5a703a9baad3b435b51404ee:17545362d6954f996c37 129225df11f4c:::

Following are the systems from which the previous five password hashes were obtained. Notice that even though there is a significant difference in the operating system, the file formats are similar. Also, realize that you can crack Solaris passwords using the Windows version of John—all you need is the actual password hash; the operating system is irrelevant.

Solaris DES from /etc/passwd
Mandrake Linux DES from /etc/shadow
FreeBSD MD5 from /etc/shadow
OpenBSD Blowfish from /etc/master.password
Windows 2000 LAN Manager from \WINNT\repair\SAM

Passwords can be cracked from applications other than Unix and Windows systems. To crack one of these passwords, simply copy the hash (in bold in each example) into the second field of a Unix password file format:

Cisco devices
Original entry: enable secret 5 $1$M9/GbWfv$sktn.4pPetd8zAwvhiB6.1
John entry: cisco:$1$M9/GbWfv$sktn.4pPetd8zAwvhiB6.1::::
Apache .htaccess files that use DES-formatted password hashes. Apache also supports passwords hashed with the SHA-1 and MD5 algorithms, but these are not compatible with John.
Original .htaccess entry: dragon:yJMVYngEA6t9c
John entry: dragon:yJMVYngEA6t9c::::
Other DES-based passwords from applications such as WWWBoard.
Original passwd.txt file: WebAdmin:aepTOqxOi4i8U
John entry: WebAdmin:aepTOqxOi4i8U:0:3:www.victim.com::

To crack a password file using John’s default options, you supply the filename as an argument. We’ll use three different password files for the examples in this chapter: passwd.unix contains passwords hashed by the DES algorithm, passwd.md5 contains passwords hashed by the MD5 algorithm, and passwd.LANMan contains Windows NT–style passwords:

[root@hedwig run]# ./John passwd.unix Loaded 189 passwords with 182 different salts (Traditional DES [64/64 BS MMX])

John automatically selects the correct encryption algorithm for the hashes and begins cracking. Press any key to display the current cracking statistics—CTRL-C will stop John. If a password is cracked, John will print it on the screen and save the cracked hash for future use. To view all the cracked passwords for a specific file use the –show option:

[root@hedwig run]# ./John -show passwd.unix 2buddha:smooth1:0:3:wwwboard:/:/sbin/sh ecs:asdfg1:11262:0:40:5::11853: informix:abc123:10864:0:40:5::12689: kr:grant5:11569:0:35:5::11853: mjs:rocky22:11569:0:35:5::11853: np:ny0b0y:11572:0:35:5::11853:

All the cracked passwords are saved in the John.pot file, which is a text file that will grow as the number of passwords you collect grows.

Poor passwords, regardless of their encryption scheme, can be cracked in a few minutes to a day. Stronger passwords may take weeks or months to break; however, we can use some tricks to try and guess these stronger passwords more quickly. We can use complicated dictionary files (files with foreign words, first names, sports teams, science-fiction characters), use specific password combinations (always at least two numbers and a punctuation mark), or distribute the processing across multiple computers.

John’s default dictionary is the password.lst file. This file contains common passwords that should show up most often among users. You can find several alternative dictionary files on the Internet using a simple Google search. One of the best (at 15MB) is bigdict.zip. Supply the –wordfile option to instruct John to use an alternative dictionary:

[root@hedwig run]# ./John -wordfile:password.lst passwd.unix Loaded 188 passwords with 182 different salts (Traditional DES [64/64 BS MMX]) guesses: 0  time: 0:00:00:01 100%  c/s: 333074  trying: tacobell – zhongguo

We can even perform some permutations on the words in the dictionary using the –rules option:

[root@hedwig run]# ./John -wordfile:password.lst -rules passwd.unix Loaded 188 passwords with 182 different salts (Traditional DES [64/64 BS MMX]) guesses: 0  time: 0:00:00:58 100%  c/s: 327702  trying: Wonderin – Zenithin

To understand what the –rules option did, let’s take a look at the John.conf file (or the John.ini file for the 1.6 nondevelopment version). Here is a portion of the John.conf file that applies permutations to our wordlist (comments begin with the # symbol):

[List.Rules:Wordlist] # Try words as they are : # Lowercase every pure alphanumeric word -c >3!?XlQ # Capitalize every pure alphanumeric word -c >2(?a!?XcQ # Lowercase and pluralize pure alphabetic words <*>2!?Alp # Lowercase pure alphabetic words and append '1' <*>2!?Al$1

Although it looks like we’d need a Rosetta Stone to decipher these rules, they are not really that difficult to understand. The basic syntax for many of these rules is derived from the crack utility written by Alec Muffet (remember libcrack?). Imagine that the system’s password policy requires every password to begin with a number. Obviously, we don’t need to bother trying to guess “letmein” since it doesn’t match the policy, but “7letmein” might be valid. Here’s a rule to prepend digits to a word:

# Prepend digits (adds 10 more passes through the wordlist) ^[0123456789]

We can break this rule down into three parts. The ^ symbol indicates that the operation should occur at the beginning of the word. In other words, it should prepend the subsequent character. The square brackets [ and ] contain a set of characters, rather than using just the next character after the ^. The digits 0123456789 are the specific characters to prepend. So, if our rule operates on “letmein,” it will make a total of 10 guesses from “0letmein” through “9letmein.”

The placeholder rules that signify where to place a new character are as follows:

Symbol	Description	Example
^	Prepend the character	^[01] 0letmein 1letmein
$	Append the character	$[!.] letmein! letmein.
i[n]	Insert a character at the n position	i[4][XZ] letXmein letZmein

Symbol

Description

Example

Prepend the character

^[01]

0letmein

1letmein

Append the character

$[!.]

letmein!

letmein.

i[n]

Insert a character at the n position

i[4][XZ]

letXmein

letZmein

We can specify any range of characters to insert. The entire wordlist will be rerun for each additional character. For example, a wordlist of 1000 words will actually become an effective wordlist of 10,000 words if the 10 digits 0–9 are prepended to each word. Here are some other useful characters to add to basic words:

[0123456789] Digits
[!@#$%^&*()] SHIFT-digits
[,.?!] Punctuation

We can use conversion rules to change the case or type (lower, upper, e to 3) of characters or remove certain types of characters:

?v Vowel class (a, e, i, o, u)
s?v. Substitute vowels with dot (.)
@@?v Remove all vowels
@@a Remove all as
sa4 Substitute all as with 4
se3 Substitute all es with 3
l* Where * is a letter to be lowercase
u* Where * is a letter to be uppercase

Rules are an excellent method of improving the hit rate of password guesses, especially rules that append characters or l33t rules that swap characters and digits. Rules were more useful when computer processor speeds were not much faster than a monkey with an abacus. Nowadays, when a few hundred dollars buys chips in the 1 GHz range, you don’t lose much by skipping a complex rule phase and going straight to brute force.

Nor will complex rules and extensive dictionaries crack every password. This brings us to the brute-force attack. In other words, we’ll try every combination of characters for a specific word length. John will switch to brute-force mode by default if no options are passed on the command line. To force John to use a specific brute-force method, use the –incremental option:

[root@hedwig run]# ./John -incremental:LANMan passwd.LANMan Loaded 1152 passwords with no different salts (NT LM DES [64/64 BS MMX])

The default John.conf file has four different incremental options:

All Lowercase, uppercase, digits, punctuation, SHIFT+
Alpha Lowercase
Digits 0 through 9
LANMan Similar to All with lowercase removed

Each incremental option has five fields in the John.conf file. For example, the LANMan entry contains the following fields:

[Incremental:LANMan] Description of the option
File = ./LANMan.chr File to use as a character list
MinLen = 0 Minimum length guess to generate
MaxLen = 7 Maximum length guess to generate
CharCount = 69 Number of characters in list

Whereas the All entry contains these fields:

[Incremental:All] Description of the option
File = ./all.chr File to use as a character list
MinLen = 0 Minimum length guess to generate
MaxLen = 8 Maximum length guess to generate
CharCount = 95 Number of characters in list

The MinLen and MaxLen fields are the most important fields because we will modify them to target our attack. MaxLen for LANMan hashes will never be more than seven characters. Raise the CharCount to the MaxLen power to get an idea of how many combinations make up a complete brute-force attack. For example, the total number of LANMan combinations is about 7.6 trillion. The total number of combinations for All is about 6700 trillion! Note that it is counterproductive to use incremental:All mode against LANMan hashes as it will unnecessarily check lowercase and uppercase characters.

If we have a password list from a Unix system in which we know that all the passwords are exactly eight characters, we should modify the incremental option. In this case, it would be a waste of time to have John bother to guess words that contain seven or less characters:

[Incremental:All] File = ./all.chr MinLen = 8 MaxLen = 8 CharCount = 95

Then run John:

[root@hedwig run]# ./John –incremental:All passwd.unix

Only guesses with exactly eight characters will be generated. We can use the –stdout option to verify this. This will print each guess to the screen:

[root@hedwig run]# ./John –incremental:All –stdout

This can be useful if we want to redirect the output to a file to create a massive wordlist for later use with John or another tool that could use a wordlist file, such as Nessus or THC-Hydra.

[root@hedwig run]# ./John -makechars:guessed Loaded 3820 plaintexts Generating charsets... 1 2 3 4 5 6 7 8 DONE Generating cracking order... DONE Successfully written charset file: guessed (82 characters)

Restore Files and Distributed Cracking

You should understand a few final points about John to be able to manage large sets of passwords at various stages of completion. John periodically saves its state by writing to a restore file. The period is set in the John.conf file:

# Crash recovery file saving delay in seconds Save = 600

The default name for the restore file is restore, but this can be changed with the –session option.

[root@hedwig run]# ./John -incremental:LANMan -session:pdc \ > passwd.LANMan Loaded 1152 passwords with no different salts (NT LM DES [64/64 BS MMX])

The contents of the restore file will be similar to this:

REC2 5 -incremental:LANMan -session:pdc passwd.LANMan -format:lm 6 0 47508000 00000000 0 -1 488 0 8 3 2 6 5 2 0 0 0

Lines nine and ten in this file (shown in boldface) contain the hexadecimal value of the total number of guesses completed. The number of possible combinations is well over any number that a 32-bit value can represent, so John uses two 32-bit fields to create a 64-bit number. Knowledge of these values and how to manipulate them is useful for performing distributed cracking. Let’s take our restore file and use it to launch two concurrent brute-force cracks on two separate computers. The restore file for the first computer would contain this:

REC2 4 -incremental:LANMan passwd.LANMan -format:lm 4 0 00000000 00000000 0 -1 333 0 8 15 16 0 0 0 0 0 0

The restore file for the second computer would contain this:

REC2 4 -incremental:LANMan passwd.LANMan -format:lm 4 0 00000000 0000036f 0 -1 333 0 8 15 16 0 0 0 0 0 0

Thus, the first system will start the brute-force combination at count zero. The second computer will start further along the LANMan pool at a “crypt” value of 0000036f 00000000. Now the work has been split between both computers and you don’t have to worry about redundant combinations. A good technique for finding the right "crypt" values is to let a system run for a specific period.

For example, imagine you have a modest collection of 10 computers. On each of these systems, John runs about 400,000 c/s. It would take one of these systems about 30 weeks to go through all seven character combinations of a common LANMan hash (69^7 combinations). Run John on one of the systems for one week. At the end of the week, record the “crypt” value. Take this value and use it as the starting value in the restore file on the second system, and then multiply the value by two and use that as the starting value for the next system. Now, 10 systems will complete a brute-force attack in only three weeks. Here is the napkin arithmetic that determines the “crypt” multiplier, X, that would be necessary to write 10 session files—one for each system. The first system would start guessing from the zero mark, the next system would start guessing at the zero plus X mark, and so on:

Total time in weeks:

Tw = (69^7 / cracks per second) / (seconds per week)
w = (69^7 / 400,000) / (604800) = 30.8 weeks

“crypt” multiplier:

X = Tw / (10 systems)
X = 30.8 / 10 = 3
“Crypt” value after one week (hexadecimal, extracted from restore file):
00030000 00000000

Here are the distributed “crypt” values (in hexadecimal notation). These are the values that are necessary to place in the session file on each system:

System 1 = 0
System 2 = “crypt” * X = 00090000 00000000
System 3 = “crypt” * X * 2 = 00120000 00000000
System N = “crypt” * X * (N - 1) = restore value
System 10 = “crypt” * X * 9 = 00510000 00000000

This method is far from elegant, but it’s effective when used with several homogenous computers. Another method for distributing the work uses the –external option. Basically, this option allows you to write custom password-guessing routines and methods. The external routines are stored in the John.conf file under the List.External directives. Simply supply the –external option with the desired directive:

[root@hedwig run]# ./John –external:Parallel passwd.LANMan

Note

If you’re going to use this method, be sure to change the node=1 line to node=2 on the second computer’s John.conf file. Also, the implementation of this node method is not effective for more than two nodes because the if (number++ % total) will create redundant words across some systems.

Is It Running on My System?

The biggest indicator of John the Ripper running on your system will be constant CPU activity. You can watch process lists (ps command on Unix or through the process viewer for Windows) as well, but you will not likely see John listed. If you’re trying to rename the executable binary to something else, like “inetd “ (note the extra space after the d), it will not work without changing a few lines of the source code.

Case Study: Attacking Password Policies

The rules that you can specify in the John.conf file go a long way toward customizing a dictionary. We've already mentioned a simple rule to add a number in front of each guess:

# Prepend digits (adds 10 more passes through the wordlist) ^[0123456789]

But what about other scenarios? What if we notice a trend in the root password scheme for a particular network's Unix systems? For example, what if we wanted to create a word list that used every combination of upper- and lowercase letters for the word bank? A corresponding rule in John.conf would look like this:

# Permutation of "ban" (total of 8 passes) i[0][bB]i[1][aA]i[2][nN]

You'll notice that we've only put the first three letters in the rule. This is because John needs a wordlist to operate on. The wordlist, called password.lst, contains the final two letters:

k K

Now, if you run John with the new rule against the shortened password.lst file, you will see the following:

$ ./John.exe -wordfile:password.lst -rules –stdout bank bank bank bank bank bank bank bank Bank BanK BaNk BaNK Bank BAnK BANk BANK words: 16  time: 0:00:00:00 100%  w/s: 47.05  current: BANK

Here's another rule that would attack a password policy that requires a special character in the third position and a number in the final position:

# Strict policy (adds 160 more passes through the word list) i[2][`~!@#$%^&*()-_=+]$[0123456789]

Here's an abbreviated example of the output when operating on the word password:

$ ./John.exe -wordfile:password.lst -rules –stdout pa`ssword0 pa`ssword1 pa`ssword2 ... pa~ssword7 pa~ssword8 pa~ssword9 pa!ssword0 pa!ssword1 pa!ssword2 ...

As you can see, it is possible to create rules that quickly bear down on a network's password construction rules.

< Day Day Up >