SSH session hijacking for port forwarding

SSH session hijacking for port forwarding

During penetration testing, we sometimes encounter situations where we build a testing environment, product servers, DMZ, or other similar machine groups. In this case, we can regard them as a stepping stone. These systems are designed as interfaces for external interaction. At this time, we consider using SSH session hijacking for users in other domains.

What if you have the permission to control a stepping stone and want users in another domain to access a remote domain? Of course, at this time, you do not have a password or a key. You cannot discard the binary method, and SSH logon uses two-factor authentication. What should I do now? Let's pick up our sleeves and practice the command line.

This article covers two methods of SSH session hijacking. We can directly implement dynamic port forwarding without authentication. When we need to hijack a session, we need to complete the following two conditions:

1. Create a session 2. There is an active SSH session

Our ultimate goal is to create a channel through the active sessions of another user to obtain the access permissions of the remote SSH host.

Create an SSH session hijacking

To hijack a newly created session, we can use a technology called SSH multiplexing. Hackers can use it to create their own sessions in a user's original socket without further authentication. The ControlMaster technology was mentioned in OpenSSH4, which was also mentioned in articles by famous hackers h d Moore and Val Smith. I personally talked about this attack method in a session-The Poor Man's Rootkit. In this article, I will show two methods to force the establishment of the master socket, and then demonstrate how to forward the port to them. The first method is related to the ControlMaster:

ControlMaster configuration on the SSH client:

After the ControlMaster is enabled, an ssh connection runs in the background and a local socket is created (controlpath is the name of this socket ).

When the ssh client needs to connect to the same remote host, it directly uses the created socket file for connection and does not need to create a connection. Similarly, it does not need to perform user authentication.

The most common way to use the socket of ControlMaster is to make special adjustments to the configuration of the SSH client in the computer.

VcmlnaW5hbD0 = "http://www.bkjia.com/uploads/allimg/150331/0405245Z9-0.png! Small "src =" http://www.bkjia.com/uploads/allimg/150331/0405245Z9-0.png "title =" 1.png"/>
 

These configurations allow all new sessions to establish persistent man-in-the-middle master socket. In the socket control command, % h is used to represent the target host, and % h can be any string.

 

Connect to socket:
This socket can be used to create a session later. Even if the original master quits the session, authentication is not required when we create the session again.

Add a dynamic channel:
You need to know that our ultimate goal is to reach other domains. The following command allows us to establish a dynamic channel on the existing master socket.

 

 

Remove socket after completion:
If we simply quit the reused Session, the master socket will not be closed. To really close it, you need to send an exit request.

 

 

Use SHELL commands to use SSH ControlMaster

Another method that uses this hijacking technology has not been announced before: the master socket can be created using the flag of the SSH client option. For this reason, we can use shell commands to intercept commands issued by a user through the SSH client, and inject our own ControlMaster parameters.
 

ssh () {     /usr/bin/ssh -o "ControlMaster=auto" -o "ControlPath=/tmp/%r@%h:%p" -o "ControlPersist=yes" "$@";}

This interception function creates the corresponding socket, which is similar to that created using ssh_config.
 

Attack flowchart:
 

 

 

Using the socket of SSH ControlMaster and the corresponding socket options, we can hijack the SSH session and inject it to implement port forwarding. These do not require any authentication. Now let's continue to look at another method:
 

Hijack an active SSH session

A normal user can create a screen session, which is easy to use. Simply type the screen command in SHELL to open a screen session. However, the screen session created in this way is used to control SSH connections to other machines with permissions, which is not in line with the security logic. Most users do not realize that these sessions may be hijacked and then used for port forwarding.
Find the screen session method:
Find the screen session method, of course, in the/var/run/screen directory. Of course, you can also use an incomplete screen-r command to enumerate and guess a user.

 

Attackers can bypass the limitations of screen pts/tty:
Obtaining screen session permissions for another domain user does not seem as simple as su commands. Many hackers are stuck here. When we use su to switch to the user corresponding to the screen session, the following error message may appear on the screen:
 

“Cannot open your terminal '/dev/pts/#' - please check.”“Must be connected to a terminal.”

 

One method that bypasses this restriction is to use the binary stream of the script to bypass the su-over user session.
 

 

 

Add a channel:

SSH has a rarely used feature, that is, escape sub-shell. If you are using other means to control the permissions to the stepping stone, you can use the transcoding sequence to add port forwarding to Sessions established by other users. Press ctrl + c to roll back to the sub-shell of SSH, and enter-D: <port> to add a dynamic port forwarding. To remove the port forwarding, press ctrl + c after entering-KD: <port>.
 

If you are using SSH in the original shell, the above suggestions will not be useful to you. This is because your SSH client will capture escape characters at the beginning. But don't worry. I will teach you how to bypass it.
Use screen to fill in the creation channel:
Screen has a feature that allows you to fill a buffer in the input queue. The text entered here is considered to be input inside the screen. So we can use it to bypass external SSH sessions and enter escape characters.

Note that the filled text is visible during screen session rollback, but you can change the rollback length to prevent it from appearing. As long as you change the return value to 0, you can clear the screen and set it back to the original:
 

screen -S 18323.my_ssh_session -X scrollback 0screen -S 18323.my_ssh_session -p 0 -X stuff $'~C'screen -S 18323.my_ssh_session -p 0 -X stuff $'-D:9090\nclear\n'screen -S 18323.my_ssh_session -X scrollback 15000

 

The following is a flowchart of screen session hijacking attacks:
 

 

Only by solving the SSH escape problem and using the screen filling feature can we hijack established sessions and inject new channels!
Channel to remote domain:
The last step is to bind a local port to connect to the channel we injected in ipv_1. Now we have full control over a dynamic channel. authentication is not required for accessing a remote domain.