What is the Reverse Shell technique and when or why I have to use it?
If the machine that you're trying to administer is behind a restrictive firewall that is not under your control, you will need to use the reverse shell technique to give you remote access to the server. This technique utilizes a somewhat unusual ssh connection sequence that can be broken down as:
First Session Server becomes a client and start the connection and the client become server and receive the information
Second Session When the channel is ready(after a procedure), roles return to be the correct ones for a normal client-server communication.
That is to say, the server first connects to the client, placing the burden of accepting incoming connections on the client and thus offering a way around the restrictive firewall.
More details about reverse shell
Which protocol must be used for this technique? What about the synchronization between server-client? Which tools i will have to use to create an reverse channel?
- Of course you will use the ssh protocol with certificates and algorithms, with public/private keys.
- Its important for the synchronization between server-client to make automate the process. Cron may be used such that the server connects back at regular intervals ensuring the connection is always active.
Multiple tools provide the reverse connection technique, but this wiki focuses on the rogram named RevSh.
Step 1 : Generate SSH Keys
Before doing anything, use ssh-keygen to create a key pair to allow password-less authentication:
mkdir ~/.ssh chmod 777 ~/.ssh ssh-keygen -q -f ~/.ssh/id_rsa -t rsa
This will generate two files--public and private key file--inside ~/.ssh. Remember to set the correct permissions to those two files to prevent other users from accessing them.
Now copy the generated public keys from the server to the client. The public key must be inserted into ~/.ssh/authorized_keys:
mkdir ~/.ssh chmod 777 ~/.ssh cat /id_rsa.pub >> ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys rm /id_rsa.pub
Doing this you will create the ssh folder inside the root one on the client machine, after the authorized_keys will be moved inside and the permission will be set ,that make possible only to you to view that file.
Step 2 : Compile RevSh
Now you have to download and install RevSh program in both server and client using this commands :
wget http://www.guru-group.fi/~too/sw/revsh/revsh-1.92.tar.gz tar zxvf revsh-1.92.tar.gz cd revsh-1.92 sh revsh.c + exec gcc -Wall -s -02 -O revsh /root/update/revsh-1.92/revsh.c -lutil 'DVEDA= "1.92(r756,2006-02-02 19:57:54Z)"' cp revsh /usr/bin cd ..
After in the /etc/hosts file you will have to add the server hostname followed by the public IP of the firewall that protects it. You can easily know what the hostname is by typing:
Step 3 : Server-Client synchronization
Now we have to create a communication channel.
revsh ssh -o PreferredAuthentication=publickey root@IP_pubclient -p 35000
Now the server will wait the client "wake up" to start the communication. Lets take a look to the options used above :
- -o this command is a derivation of the ssh syntax and determines the options that can be used/activated
- IP_pubclient client address in ip numeric format (10.x.x.x)
- -p client port where the ssh service is working. In our example is 35000
With the server connected to the client the First Session is now active. We can now create the Second Session by executing the following on the client machine.
revsh serverhostname shell
You now have working SSH interface from the client machine to the remote server. Use this just like a standard SSH connection.
Using the following script, the First Session can be automated such that the connection is always active. This will allow true remote administration as the server will connect to the client machine automatically, preventing the need for human interaction until the client is ready to connect.
!/bin/sh revsh ssh -o PreferredAuthentications=publickey root@IP_pubclient -p portnumber
Save this as a script and set it to execute via crontab or by linking in one of the /etc/cron.FREQUENCY/ folders. Hourly is recommended, but more frequently may be desirable depending on the stability of your internet connection and how long you're willing to wait before a reverse shell can be initiated.