Lateral Movement via SSH Alias Abuse
If you’re attempting to gain unwanted access to a server and the only port open is running SSH, you’re probably not too thrilled. A well-secured SSH server will have extra protections such as public-key or certificate authentication, 2FA, and more. But what if there is a way to bypass these protections by joining an SSH connection that has already authenticated to the server?
Enter SSH master mode. SSH master mode allows you to create multiple SSH sessions by multiplexing the underlying TCP connection. The master socket creates the channel and additional connections to the channel are made through file sockets. For this attack path, we will need C2 (command & control) on an endpoint that contains a user that frequently accesses the server.
Create socket example: ssh -M -S /tmp/mysock user@host
Join socket example: ssh -S /tmp/mysock user@host
The key: multiplexed channels are already authenticated to the server since the initial authentication has already occurred over the same TCP connection! This is great but we still have the issue of getting the victim user to create the multiplexed SSH socket on our behalf. Luckily, our victim utilizes an alias for the SSH command they use to access the server. We can abuse this alias so that the user creates the multiplexed socket for us. Here is an example of both techniques in action.
First, on the victim MacOS endpoint we are laterally moving from, we identify the SSH alias in their .bash_profile.
Next, we can edit this alias to execute SSH in master mode thereby creating a socket we can join.
The next time the user starts a bash session and uses their connect alias, they will secretly give us access to their authenticated SSH channel. There is no direct evidence to the victim user that they are running a different command.
Then, after the user has connected to the target SSH server, we can simply join the created socket. No password, key, or 2FA.
Although both sessions operate over the same TCP connection, they are independent of each other, and commands sent in one session will not be seen in another.
Unfortunately, many C2 tools will have trouble directly interacting with an SSH session because the C2 communication is connectionless (think HTTP beaconing). In my next blog post, I will detail how we can send commands to the SSH session from a remote C2 server. Until then, check out https://redblue42.code42.com/ for more interesting blogs!