John the Ripper Pt.4

Intro

In this article – the last in our John the Ripper series – we would like to focus on how we can use John to crack SSH keys, as well as mention some basics of Custom Rules.

 

SSH

What is SSH? When do we use it (or should)? How does it work, and what are some encryption techniques/technologies that SSH has to offer?

Let’s answer all of these questions briefly (it is a very big topic), before delving further into how john can leverage some of its functionalities to crack the SSH private key password of the id_rsa files.

SSH stands for Secure Shell, and is a remote administration protocol, which gives us the ability to access, control, or modify our remote infrastructure (usually servers) over the Internet. You might want to remote to your clients server to troubleshoot something, or to deploy some code.

Historically, SSH was created as a replacement for the much more insecure protocol called Telnet, which, even though with the same purpose, doesn’t offer encryption. You can see why that might make some of us feel quite awkward. SSH encrypts all of our communication to and from the remote server, by the virtue of encryption. With SSH we can authenticate a remote user, for example.

To use SSH, we can simply pull up the terminal (for MacOS/Linux) and type:

ssh <username>@<ip_address> -p(port_number)

Where the username is the name of the user we wish to connect as, and the IP address being that of our server we are connecting to. For Windows we can use a SSH client, the most known one being PuTTY.

For example, if we were to connect as a user called john to our remote server at 184.121.23.43 at the default port (for SSH its port 22), we would give a command like this:

ssh john@184.121.23.43 -p22

Regardless of our platform, once we’ve issued our command, we will get a prompt asking for a password for the user we specified, in order to authenticate us. If the credentials are correct, we will be shown a command-line, that of our server we just got into.

SSH and John the Ripper

As we’ve already mentioned, we can use john to crack private key passwords of our id_rsa files. If our target has configured key-based authentication – which just means they are using their private key – id_rsa – as their key to authenticate against the server and to log in using SSH. Since this will generally require a password, we can once again use John to help us crack that password, so that we can authenticate over the SSH (by the usage of the said key).

Another tool (as zip2john, and rar2john previously – sound familiar?) john leverages, is a tool called ssh2john. The logic remains the same – ssh2john converts the id_rsa key to a hash that John can work with. The syntax is virtually the same as before:

ssh2john [id_rsa_file] > [output_file]

ssh2john – command to call our converter tool

id_rsa_file – path to our file that we want to convert to a hash

output_file – here, we will store our output e.g. the hash that we’ve created

One small thing of note, before we look at our example. If your terminal tells you that ssh2john can’t be found (command not found – meaning ssh2john is not installed - like in the image below)

Please note that you can still use ssh2john.py, which is basically the same thing, wrapped inside a Python script. Usually, ssh2john.py is located in /opt/john/ssh2john.py or, in case you’re using Kali, you can find it in /usr/share/john/ssh2john.py. Just remember to invoke your Python scripts by adding python/python3 to your command line first. (as shown in the image below)

This also brings us to our example.

In order to do the cracking, we’ve first created a new private/public key-pair using ssh-keygen (image below)

(Spoiler alert! We’ve used the passphrase banana)

All that’s left now is to do some john magic.

First, we run our Python version of the ssh2john conversion tool – as shown below (which is the same image as above)

Simply, we’ve asked Python to run the script called ssh2john, which can be found in the /usr/share/john/ssh2john.py path… again, if you’re not on Kali, this would be /opt/john/ssh2john.py, and then we’ve given the path to our newly created (banana-protected) private key – /root/.ssh/id_rsa – which we’ve redirected to an output file on our Desktop, called KeyHash.txt.

Now we are ready, and should have all we need in order for John to crack our private key password for us.

We invoke John, using our trusty rockyou.txt wordlist, and let it do its thing:

 

 

 

 

 

Lo and behold, 29 seconds after, John has returned to us with the correct output - banana, cracking our password successfully!

 

Custom Rules

Similarly to the single crack mode that we’ve covered in part 2 of our series (word mangling, or variations of a word, where we change the letters to capital letters, numbers, etc.) we can also define our own sets of rules in similar fashion. John will then use our newly created rules to create passwords. This can be quite useful if we know (or suspect) the password structure of whatever it is that we’re attacking.

With this we can integrate capital letters, numbers, symbols... same as for the single crack mode. Also, this can prove to be rather useful for us, since organizations sometimes enforce password policies in order for them to be a bit less susceptible to dictionary attacks.

This is exactly what an attacker might leverage to their advantage! As we all know people tend to make similar passwords, or even reuse them, and adding numbers and capital letters, or symbols can make it so they meet the password policy’s requirement (complexity). Still, Babyblue1! is not an example of a secure password by any means!

So, if an attacker knew about the password structure, used a bit of Social Engineering on the target they’ve picked (some employee of the company perhaps), they could then easily connect the dots and compromise the system – gain a foothold into your now compromised organization.

Password rules are usually located in the /etc/john path, in a file called john.conf. Another path could be /opt/john.

To create our rule, the first line is used to create a name for the rule, which we can later invoke with John. It looks something like this: 

[List.rules:Babyblue]

Then, we need to use a regex style pattern in order to define our rule further:

A0 – prepends the word with characters we defined

c – capitalization of the character (position based!)

Az – appends the word with any characters we defined

u – convert to uppercase

Now we just need to decide where and what we want to be changed. To define what’s going to be prepended or appended, we put that in square brackets [] - in the order of usage!

We end up with something similar to this:

cAz”[0-9] [!@%$]”

After that, all that’s left is to add our rule to our usual command, by adding this flag: --rule=Babyblue.

We would end with a command like this:

john --wordlist=/usr/share/wordlists/rockyou.txt --rule=Babyblue target_file_path

Of course, there are many resources out there, and we would suggest first checking out these two, if all this talk about custom rules has piqued your interest.

 

Conclusion

Some finishing thoughts before we close out this series about John the Ripper. As we’ve seen from some of our examples and stuff that what was mentioned in the series, John offers a lot of flexibility and versatility, but, as always, in order to leverage this great tool to its maximum potential, there’s a lot of ground to be covered – this does not mean you need a PhD in Cryptography, of course, just a lot of trial and error!

We wish you happy (& safe) password cracking!