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.
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!
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.
We wish you happy (& safe) password cracking!
Our Path to Product-Led Growth
Michael Assraf June 21, 2022CISAnalysis - June 20, 2022
Kent Weigle June 20, 2022Vicarius and Advent One Partner to Expand APAC Operations
Evan Kling June 20, 2022Crowdsourcing: Utilizing Humanity’s Greatest Asset
Kent Weigle June 16, 2022The Good News and Bad News About 0-Day Attacks
Vicarius June 14, 2022