SSH Keys
Because private keys are obvious targets,
there are often additional protections in place.
Typically, a user’s SSH key will have permissions set to 600.
It’s possible that during a penetration test, we could find a private key
with weak permissions.
Even if we do not have root access to the machine, it’s worth checking the target
system in the unlikely event that a key has been left unprotected.
Let’s look for potentially unprotected keys with a simple find command
on our linuxvictim VM.
In Linux, private keys are named id_rsa by default.
The following command won’t find files that are named differently,
but it’s a good starting point.
If we don’t have permission to view the file,
we’ll receive a “Permission denied” error message.
There are no keys with insecure permissions on this system,
which should come as a surprise.
Since we are discussing lateral movement, In the next step we will assume that we
have gained root access to the machine and will operate with those privileges.
It’s not uncommon for users to copy their keys to a different location than the
default .ssh folder or to have copies of keys with different names.
Because of this, we’ll inspect the /home directory once again
and browse other user’s files with our elevated privileges.
If we examine the /home/linuxvictim directory,
we note that a private key with an unconventional name,
svuser.key, is stored there.
Once we have located a private key, we will need to analyze it.
As we mentioned before, an SSH key can be protected with a passphrase.
There are a few ways to find out if our key is protected with a passphrase.
We could simply use the key with an SSH client in an attempt to generate
a passphrase prompt, but this could trigger a log or an alert.
A safer and more discreet alternative is to simply view the file itself.
In this case, the file contains “Proc-Type” and “DEK-Info” headers.
The “Proc-Type” header states that the key is encrypted.
The “DEK-Info” header states that the encryption type is “AES-128-CBC”.
This tells us that the key is protected with a passphrase.
Even though we have the key, we’re not sure where it can be used.
Inspecting the /etc/passwd file,
we observe that there is no svuser account,
so it’s not likely that the key is for this machine.
One approach is to read the user’s known_hosts file
to find machines that have been connected to recently.
We could try to connect to one of these machines with the svuser key.
Unfortunately, in our case, the system has the HashKnownHosts setting enabled,
in ssh_config,
so entries in the known_hosts file are hashed.
Inspecting the file itself provides no further useful information.
Another approach is to check the user’s .bash_history file.
The .bash_history file shows the terminal commands that the user has typed in
over time.
In this case, we find that they connected to the controller server
using the svuser account and the key we found.
We’ll use the host command to determine the IP address of the controller machine.
Since the key is passphrase-protected, it will be more difficult to steal and use.
However, in this case, the passphrase check is done on the client side.
This means we can try and crack the passphrase offline..
To do this, we'll first copy the key file over to our Kali VM.
We can attempt to crack the passphrase in a few different ways.
We could use Hashcat, which can use the GPU to speed up processing,
but in this case, we’ll use John the Ripper.
To use JTR, we need to convert our stolen passphrase-encrypted
private key to a format that the tool will recognize.
In this case, we’ll use the SSH2John utility that comes with JTR.
To convert the key file, we'll provide the key file name as an argument,
and redirect the output to a new file.
Now that our key is ready, we’ll choose a wordlist.
There are many approaches to choosing appropriate wordlists, but for sake of
simplicity, we’ll start with the commonly-used rockyou wordlist.
We can now run JTR on the file with the --wordlist option,
to attempt to crack the passphrase.
After a bit of time, JTR reports that it successfully discovered the passphrase,
which is “spongebob”.
Now that we know the passphrase, let’s attempt to connect to the controller VM
from the SSH session we have on the linuxvictim server.
This approach will attempt to avoid alerts that might be triggered
by a direct connection from our Kali VM.
After specifying our private key,
we can enter “spongebob” when prompted for our passphrase.
This time, we are successfully connected to the target.