Scenario: You are a system administrator of a small IT company which hosts a scooter club website. You are in the process of configuring SSH access to one of the web servers and your colleague, Peter, insists everyone should be able to log into the server directly as the root user. This, of course, is a bad idea for many reasons, one of them being the lack of accountability. But since you both use SSH agents to log into several locations for easier Git access and sometimes using multiple keys, the thing which concerns you most is SSH Agent Hijacking.

Rather than just explain the concept, you show Peter how it works. He also works on another website, https://vacation-planner.lab which is housed in a different remote server. To demonstrate the technique, you get permission to try to get access to that remote server as a proof of concept. He created a flag in the server’s /root directory for you to use as proof when you manage to log in.

There is already a private key added to the SSH agent in the Ubuntu desktop, so all you need to do is log into angelsscooters.lab server via SSH with agent forwarding enabled. You can view all the keys which have been added to the agent with ssh-add -l.

SSH Agent Socket

The way agent forwarding works is that SSH creates a UNIX domain socket used for communicating with the agent on the remote server, which is then tunneled back to the SSH gent socket in your Ubuntu desktop. This means that the SSH client in angelsscooters.lab can now send decryption requests directly back to the SSH agent running in the desktop. The location socket in angelsscooters.lab can be find your environment variables, namely the SSH_AUTH_SOCK variable.

Command env shows environment variables, and reveals SSH_AUTH_SOCK has a value set to: /tmp/ssh-pL8IOYpd1G/agent.1083

This shows us that the socket is located in /tmp.

If you have root access to the server, you have access to all the other SSH agent sockets as well. You already know which one is your own, so finding somebody else’s shouldn’t be an issue. There are several ways to find out another user’s SSH agent socket.

One is to look at the user’s processes and tracing the sshd process ID to the agent. Another is by simply noting the owner of the socket itself.

By replacing the SSH_AUTH_SOCK value with a socket to someone else’s SSH agent, you gain access to his agent and therefore the ability to log into systems using the keys in his agent. You don’t even need a passphrase as the keys have already been decrypted. While this will only last until the socket is open, there is nothing to stop you from seeding any backdoors into that system and ensuring future access.

pgrep -u peter sshd shows us the PID of the agent is 345 find /tmp -name 'agent.345' shows us the path of Peter’s agent

Now we just need to change the SSH_AUTH_SOCK value and connect to vacation-planner.lab.

SSH_AUTH_SOCK=<ssh-agent-socket-path>
ssh root@vacation-planner.lab
cat /root/flag.txt