John the Ripper Pt. 2

May 02, 2022

Intro

Authentication hashes are stored and kept by operating systems. Really, they are just hashed values of passwords. It might be possible to brute force these, but oftentimes you would need some sort of privileged permissions in order to obtain them, so it is somewhat of a more difficult task.

 

Windows Authentication Hashes

In the case of modern Windows based operating systems, we have something called NThash as the hashing format. Devices running Windows store passwords of their users (or services) in this format. You’ve also probably heard of the term NTLM. The LM part refers to the older version of the Windows password hashing format. Thus, NT + LM → NTLM.

Historically, the NT was used with Windows NT to indicate that the system was not built on the MS-DOS, it also meant “New Technology” (at least in the beginning).

Generally, we would go on about these in a different way. We could maybe get those NTLM hashes by dumping the SAM db on our Windows machine from the Active Directory db – called NTDS.dit, or by using a tool such as Mimikatz. We can also get away with just doing the “pass the hash” attack instead of cracking the said hashes, but if there’s a bad password policy in place, cracking of those hashes is a bit more feasible.

Example:

Let’s do a quick example, now that we’re a bit more familiar with the NTLM hashes!

We want to figure out the value of the following hash:

FB8C8EFD6C16B0221E3F12543FAADF2F

First, we ask John what formats does it know, so we specify:

john –list=formats


Since John is familiar with both of the hash types we need, we go for it (using what we learned about John previously).

We tell John which format we want, and give it a wordlist – as we did before.

john --format=NT --wordlist=/usr/share/wordlists/rockyou.txt hashNT.txt

**hashNT.txt is just a file where we’ve added our NT hash**

In the blink of an eye, john returns the output, e.g. the cracked hash – baboon


We can check this for ourselves easily, for example here.

Of course, this was extremely fast mostly due to the fact that we’ve got an easy word here, but the principle remains the same.


Linux /etc/shadow hashes

Similar to the NTLM hashes for Windows-based operating systems, we have the /etc/shadow file in Linux-based operating systems where password hashes are stored; there are also other interesting items within the /etc/shadow file, such as usernames, password expiration dates, or the date of the last password change.

Note that only the root user can view these hashes, so you would need to have a way of escalating your privileges to root before trying to crack hashes in the shadow file.

Since john can be quite picky with file formats, in order for it to understand the data that we’re giving it  we have to combine the /etc/shadow files with /etc/passwd file. Luckily, John has an in-built tool that’s called unshadow.

The syntax for unshadow looks like this:

unshadow <path_to_password> <path_to_shadow>

Since in both passwd and shadow files one line corresponds to one user/user account in the system, we can either use unshadow on the whole shadow file (but then we need the whole passwd file) or we can find the corresponding lines from each of them.

Example:

Let’s see how this works in practice.

  1. We cat the passwd file for the root user and add that to a root_passwd.txt file
  2. We cat the shadow file and look for the line that says root, adding it to root_shadow.txt file
  3. We say unshadow root_passwd.txt root_shadow.txt > unshadowed.txt



(the greater than sign tells john to use the two .txt’s and join them into a new one, called unshadowed.txt, something which we can operate on)

Our end result is the unshadowed.txt file, which looks like this:


Now, all that’s left for us to do is what we’ve been doing so far, and feed this to John – the way we learned.


We try first without specifying the format, since we’ve already made everything john-ready with our unshadowed.txt, but as we can see from the image above, john doesn’t like this so it can’t help us.

We know from the hash that its crypt (3) so we give john the format value of crypt, and try again:


As we can see the password for the root user is olive. On the right-hand side we can see some attempts that John has made before guessing correctly. One row below our result we can also see that it took 32 seconds – not bad!

Please note that the crypt (3) is a generic format and it is considered to be special, as its main purpose is to support any type of hash a system would support - even if its an unknown to john. In real systems, you should expect to see much more secure hashing algorithms used, like SHA256, SHA512, or SHA3.

(We used a burner VM for our testing purposes, so we didn’t care that much about security. Also, please note that the crypt (3) is a generice)

 

Single Crack Mode

Lastly, let’s talk about another functionality that John has to offer, called single crack mode. The gist of the single crack mode is that john uses only the information that it has gotten through the username, and tries figuring the passwords out heuristically – by making variations in the letters/numbers that are in the username.

For example if the username is peter, some possibilities could include:

  • peter1, peter2, peter3, peter4… etc.
  • pEter, PEter, PETEr, PeTEr… etc.
  • peter!, peter$, peter&, peter%… etc.

This is also known as word mangling. John is really just creating its own dictionary based on the data that has been given, and then it applies some rules to it. In this way, it exploits poor passwords that could be based on usernames, services, etc.

Some basic syntax when using single crack mode would look like this:

john --single --format=<format> <path_to_file>

with the --single telling John that we want to use single crack mode.

Before we show our example, please note that for John to understand our input, we need to add a prefix to our hash – our username.

We have our example hash, a SHA256 hash to be precise:

1b3a10657a23bdd02d5262f375d5255a045b6ccfca4082ecaf7b0c1efea3dfad

And we know it belongs to the user hacker, so we say:

hacker:1b3a10657a23bdd02d5262f375d5255a045b6ccfca4082ecaf7b0c1efea3dfad

We tell John:

john --single --format=raw-sha256 singlecrackmode.txt

 

(Where singlecrackmode.txt is just a one-liner containing hacker:1b3a10657a23bdd02d5262f375d5255a045b6ccfca4082ecaf7b0c1efea3dfad)



Almost immediately, john has figured out that our user with the username hacker, has h4cker for their password.


 

Conclusion

In this article we’ve covered some more options John has to offer – cracking authentication hashes for both Windows and Linux-based operating systems, as well as the single crack mode. Nevertheless, we still have interesting stuff to cover...

Just remember to crack responsibly & ethically, either on your systems or on systems that you’ve been given explicit permission for, otherwise you might end up in real trouble. Happy cracking!

Tags

  • #cybersecurity

  • #hacking

  • #passwords

  • #pentesting

  • #thicalhacking

  • #johntheripper

  • #vicarius_blog

users/photos/cl09w23tf2efa0mpf8sov0k5q.jpg

Written by

acephale 4w

Recent Posts

  • 1

    How to test application with ZAP - Part Two

    Jenny R September 28, 2022
  • 2

    How to test application with ZAP - Part One

    Jenny R September 28, 2022
  • 3

    The World's Worst Hackers Have Flags

    Paul Lighter September 27, 2022
  • 4

    Intro to Windows (Win32) API

    acephale 4w September 26, 2022
  • 5

    State of the Union's Infrastructure Security According to CISA

    Kent Weigle September 23, 2022
last_chanse_02.png

Start Closing Security Gaps

  • Risk reduction from Day 1
  • Fast set-up and deployment
  • Unified platform
  • Full-featured 30-day trial