SSH Private Key Passphrase
In this section we will focus on cracking SSH private key passphrases.
Even though SSH private keys should be kept confidential,
there are many scenarios in which these files could be compromised.
For example, if we gain access to a web application via a vulnerability
like Directory Traversal, we could read files on the system.
We could use this to retrieve a user’s SSH private key.
However, when we try to use it to connect to the system,
we would be prompted for a passphrase.
To gain access, we’ll need to crack the passphrase.
Let’s demonstrate this scenario and how to use the cracking methodology
we discussed to crack the passphrase of a private key.
When we used a dictionary attack on the BRUTE HTTP login form,
we gained access to a webbased file manager that hosted an SSH private key.
Let’s browse another web service
and log in with a username of user and a password of 121212.
This web service is similar to the previous TinyFileManager example
except that the main directory now contains the two additional files
id_rsa and note.txt.
Let’s download both of them to our Kali machine and save them
to our passwordattacks directory.
First, we’ll review the contents of note.txt.
The output shows that this note contains dave’s password list in plaintext.
Wow!
This is a potential gold mine of information.
In a real-world situation,
we would need to perform significantly more information gathering
(including learning the actual username associated with each password),
but for purposes of demonstration we’ll run with this!
Let’s try to use the private key id_rsa for the newly-identified user dave
in an SSH connection.
For this, we must modify the permissions of the downloaded private key.
The SSH port used in this example is 2222.
We will try each of Dave’s passwords as the passphrase for the SSH private key.
Note that the ssh program will not echo the passphrase.
None of the passwords from the text file worked for this passphrase.
However, in a real penetration test we would keep these passwords on hand
for various other vectors including spray attacks,
or attacks against a dave user on other systems.
However, we still need a passphrase to use dave’s private key.
According to the note.txt file,
a new password policy was enabled in January 2022.
There’s a high probability that dave has a passphrase that satisfies
the new password policy.
Following the cracking methodology,
our next step is to transform the private key into a hash format
for our cracking tools.
We’ll use the ssh2john transformation script from the JtR suite
and save the resulting hash to ssh.hash.
Within this output, “$6$” signifies SHA-512.
As before, we’ll remove the filename before the first colon.
Then, we’ll determine the correct Hashcat mode.
The output indicates that “$6$” is mode 22921.
Now, let’s proceed in our methodology and create a rule file and prepare a wordlist
to crack the hash.
We’ll again review note.txt to determine which rules we should create
and which passwords we’ll include in the wordlist.
Based on this, we can begin to create our rule file.
We must include three numbers,
at least one capital letter, and at least one special character.
We notice that dave used three numbers in one of his passwords.
Furthermore, the “Window” password starts with a capitalized letter.
Let’s use a rule function to make the first letter upper case.
There is no special character included in any of the listed passwords.
For our first cracking attempt,
we’ll just use the most common special characters “!”, “@”, and “#”,
Based on the analysis, we’ll create our rules.
We’ll use c for the capitalization of the first letter,
and dollar sign 1, 3, and 7 for the numerical values.
To address the special characters,
we’ll create rules to append the different special characters.
Next, we’ll create a wordlist file containing the passwords from note.txt,
and save the output.
Now we can use Hashcat to perform the cracking by specifying the rules file,
the wordlist, and the mode.
Unfortunately, we receive an error indicating that our hash caused
a “Token length exception”.
When we research this with a search engine,
several discussions suggest that modern private keys and their
corresponding passphrases are created with the aes-256-ctr cipher,
which Hashcat’s mode 22921 does not support.
This reinforces the benefit of using multiple tools
since John the Ripper can handle this cipher.
To be able to use the previously created rules in JtR,
we need to add a name for the rules and append them to the configuration file.
For this demonstration,
we’ll name the rule sshRules with a “List.Rules” rule naming syntax.
We’ll use sudo and sh -c to append the contents of our rule file
into the john configuration file.
Now that we’ve successfully added our sshRules to the JtR configuration file,
we can use john to crack the passphrase in the final step of our methodology.
We’ll define our wordlist,
select the previously created rule,
and provide the hash of the private key as the final argument.
We successfully cracked the private key passphrase! Excellent!
As expected, the password satisfied the password policy requirements
and also matched dave’s personal preferences and habits.
This is no surprise, since users rarely change their password patterns.
Now, let’s use the passphrase to connect to the target system via SSH.
We successfully connected to the target system by providing the correct passphrase
to the private key.