SSH Hijacking Using SSH-Agent and SSH Agent Forwarding
Now that we’ve covered SSH hijacking with ControlMaster,.
let’s move on to another technique
This method of SSH hijacking revolves around the use of SSH-Agent
and SSH Agent Forwarding.
SSH-Agent is a utility that keeps track of a user’s private keys and allows them
to be used without having to repeat the passphrases on every connection.
SSH agent forwarding is a mechanism that allows a user to use the SSH-Agent
on an intermediate server
as if it were their own local agent on their originating machine.
This is useful in situations where a user might need to ssh from an intermediate
host into another network segment,
which can’t be directly accessed from the originating machine.
It has the advantage of not requiring the private key to be stored on the
intermediate server
and the user does not need to enter their passphrase more than once.
This works by passing the SSH key response requests from the remote
destination servers back through the SSH-Agent on the intermediate hosts
to the originating client’s SSH Agent for key validation.
To demonstrate this concept, we’ll cover an attack scenario where a user connects
to an intermediate server and then to a subsequent remote server
using SSH agent forwarding.
Then we’ll discuss how we can exploit this connection.
To use an SSH-Agent,
there needs to be an SSH keypair set up on the originating machine.
This can be done with ssh-keygen as we covered earlier,
ensuring we set a passphrase.
For our SSH connections to work using SSH-Agent forwarding, we need to have our
public key installed on both the intermediate server
and the destination server.
In our case, the intermediate server will be the controller machine
and the destination server will be linuxvictim.
We can copy our key to both of them using the ssh-copy-id command,
specifying our public key with the -i flag.
In addition, we’ll set ForwardAgent to “yes” in our local SSH config file.
This tells the SSH client we’re connecting from to enable agent
forwarding for connections.
Next, on the intermediate server,
which in our case is the controller, we need to have AllowAgentForwarding
set to “yes” in sshd_config.
This allows the intermediate server to forward key challenges back to the
originating client’s SSH agent.
SSH-Agent is automatically set to run on many Linux distributions,
but we’ll need to start it manually on our Kali VM.
We can now add our keys to the SSH-Agent on our Kali VM using ssh-add.
If we just want to use the key that is in the default key location,
we don’t need to specify any parameters.
Alternatively, we can add the path to the key file we want to use immediately after
the command.
In our case, since our key is in the default location, we can just run ssh-add.
Now that our key is registered with the agent, we can use a pair of ssh commands
to connect to the downstream server.
We’ll first ssh to the controller,
and then from there, ssh to the linuxvictim host.
Note that we needed to type our private key passphrase for the first connection
so that the SSHAgent can keep track of it.
Now that we know how to use SSH agent forwarding,
let’s discuss how to exploit it.
We’ll talk about two scenarios as we did with the ControlMaster example.
We’ll cover a case where we compromised an unprivileged user who has an open SSH
session on the intermediate server
and the same scenario with a root privileged user.
We’ll begin with the first scenario and assume we have compromised the account
of a user who is logged in to the intermediate server.
With our previous ControlMaster exploitation, we were restricted to
connecting to downstream servers that the user had an existing open connection to.
With SSH agent forwarding, we don’t have this restriction.
Since the intermediate system acts as if we already have the user’s SSH keys
available, we can SSH to any downstream server
the compromised user’s private key has access to.
To exploit this, the compromised user needs to have an active SSH connection
to the intermediate server.
We’ll simulate this by closing the previous shell to the linuxvictim box
opened from the controller machine,
but we’ll leave the connection to the intermediate server open.
This will act as the victim SSH offsec user session.
Next, to simulate the attacker connection and ensure we aren’t using our kali user’s
public key, we’ll use the root account to open a shell to the intermediate server
using password authentication as the offsec user,
and from there, we will ssh to the linuxvictim machine.
Excellent! SSH-Agent forwarding did its magic and we were able to access
the downstream linuxvictim box through SSH key authentication
even though we are not in possession of the keys.
However, there may be a case where we don’t want to be logged in as the user
whose SSH session is currently open.
We may, for example, want to avoid adding artifacts to the logs related to that user
The SSH-Agent mechanism creates an open socket file on the intermediate server
that can be accessed by users with elevated permissions.
If we’ve compromised an account with root level access on the intermediate server,
we can leverage the victim user’s open socket directly.
To demonstrate this, we’ll leave our earlier offsec user’s SSH connection
to the controller server VM open.
We’ll then create a new SSH session from our Kali VM to the controller
with the root user to simulate the attacker shell access.
As an attacker logged in to the root account on the controller,
we first we need to find the user’s open SSH-Agent socket.
We can get a list of SSH connections with ps aux.
If we inspect processes with “ssh” in the name,
we’ll find any open connections from the host.
We can use the usernames listed in these connections with the pstree command
to get the process ID (PID) values for the SSH processes.
We’ll try using the PID in the final line of the output,
which seems to indicate a bash session.
We can cat the contents of the PID’s environment file,
and search for the SSH_AUTH_SOCK variable.
SSH-Agent uses this variable to determine the location of its socket.
As an elevated user, we can use the victim’s SSH agent socket file
as if it were our own.
First, we set our current privileged user’s SSH_AUTH_SOCK environment
variable to the open SSH socket of our victim.
We then use ssh-add -l to show that the key is in our SSH Agent cache.
Next, we re-set the environment variable for the socket and then ssh to the
linuxvictim host as the victim user.
SSH hijacking can be a useful tool for lateral movement within a network.
In the next section, we’ll inspect an infrastructure tool commonly used
to configure Linux systems and learn how it can be used for lateral movement.