What I might want to attempt during this post is a quick exhibition of how it tends to be manhandled, for the unpracticed and examine normal projections I see and why you ought to know about this issue.
Setting up the Environment
I'll use three machines to project this demonstration. The first and the second are Kali Linux machines, and the third is the Ubuntu machine. First, I made a "testing" user on all three machines.
Host 1: kali
Host 2: law
Host 3: ubuntu
On the first Kali Linux machine(kali), I have produced an SSH key-pair :
Now, we will take the public-key of our first Kali Machine(kali) and add it to the authorized keys file present on second Kali machine(law):
Next, we will repeat the same step and add our public-key to the authorized_keys file present on the third Ubuntu machine(ubuntu):
Now, both the machines(law & ubuntu) are configured for public-key authentication with this key. As we are performing this demonstration with the help of a terminal we need to start the ssh-agent manually. If we were authenticated in from the GUI many operating system will spring up a window and offers to save your key in agent for you naturally.
The accompanying gives us an idea of starting the ssh-agent, including my key (which we made above) and then listing out the keys which are currently present in my agent (kali):
Now, we're ready to SSH to second Kali machine(law) from first Kali machine(kali) using key-based confirmation, we will abrogate the default by indicating -A to forward our agent:
Presently, we are on the second Kali machine(kali) with our agent forwarded. We can verify it with ssh-add -l once more.
We would be able to SSH to Ubuntu machine(ubuntu) which likewise has our public-key in its authorized_keys file.
Incredible, we're good to go. How about we play with it.
Demonstration
We will probably misuse or root privileges on second Kali machine(law) to get to the third Ubuntu machine(ubuntu) server, on which we don't have a record, as the testing user. Sign in to the kali machine(law) and gain root privileges. Our testing user is still signed on:
We should examine /tmp and see what we find.
ssh-agent makes a UNIX socket file in /tmp. It gives a valiant exertion to verify them by making a registry prefixed with ssh-, chmod'ed to 700 and is possessed by the user who signed in. When a user signs in with the agent forwarded, the environment variable SSH_AUTH_SOCK is set to the path of this socket file. Since we have root rights, we can get to this socket document, so we need to simply modify the value of our SSH_AUTH_SOCK variable to this socket document and we can utilize the key information to verify, so the user is still signed in with active forwarding.
Goodness dear, it worked. We are currently being confirmed as the testing user to third Ubuntu machine(ubuntu). It is essential to take note that although a passphrase has been determined to the private key of the testing user, once the key is stacked into the ssh-agent and this maltreatment isn't secured by the passphrase.
Basic Scenario
A great number of people use agent forwarding but they don't confine it accordingly. Numerous people use consistent SSH keys for different machines or hosts. Let us take an example, they produce a key-pair at work for gaining access to work servers, then they use the same public-key on their home SSH server, or in "The Cloud". An insidious root user on one of those work servers (or penetration tester) may utilize those agent socket files to get to your home server, your VPS etc. A few firms even empower direct root logins with SSH giving it's "without-password". Woot - Instant root access.
How to protect yourself?
Unfortunately, there's no enchantment exhortation here. OpenSSH offers some setup decisions like IdentitiesOnly but this exclusively controls which identities to forward to a server for verification. Suppose you are successfully signed in and forward your agent, all identities stacked will still be offered on the remote host.
The best suggestion I will give is don't forward your agent to hosts that you can't trust --- simply like the documentation says!
Article Link: https://blog.lucideus.com/2019/11/ssh-agent-playing-with-trust-ssh-abusing.html