Reverse TCP shell — SecurityTube Linux Assembly Expert 32 bit — Exercise 2
In the last post we saw how to craft a port binding shellcode, in this post we will look into the method/process of crafting a reverse TCP shell.
We will go through the basics of a reverse TCP shell and understand the motivation behind it. This is one of the foundational shellcode in the sense that this is an easy or simple entry into a victim/compromised machine which gives us the ability to do RCE(Remote Code Execution). This is also called a connect-back shellcode, which in plain terms mean, the victim machine connects back to the attacker’s machine via a pre-configured IP/Port combination. As a matter of fact, if this is accomplished, there is a lot more left to desire with regards to the security of the victim/compromised host. The code has to be executed on the victim machine and the victim talks to the attacker over the network. The attacker in turn needs to be listening on the exact IP/Port combination. As soon as the victim connects to the attacker machine, a remote shell(victim machine) is spawned and the attacker is presented with the shell console over the socket. Its similar to having a ssh or similar session established with a remote host.
The only difference between the port-binding shellcode and this one is that this one(reverse TCP shell) is a session/connection that is initiated from within the victim network(less scrutinized), while the port-binding is a service that is waiting listening for incoming connections(actively scrutinized by Firewalls, IDS etc..). This is a simple shellcode. The sequences involved are the normal setting up a TCP client and connecting to a remote(attacker) IP/Port combination service that is pre-configured. This means we need to do some socket programming as a PIE(Position Independent Executable) code. This sounds complicated, but in reality its something we all know theoretically but the implementation is a little different( a little challenging since its assembly code, x86 in this case). Let’s see.
A simple TCP client has to invoke the following system calls in sequence, ‘socket’, ‘connect’, ‘dup2’, ‘execve’.
‘socket’ — creates the socket interface for a particular family and protocol that client programs can use to communicate.
‘connect’ — This is the main network sys call that initiates the session/connection to the target remote system(attacker’s machine). There is a small trick we are doing here — the IP and the PORT number have been XOR encoded with a predefined XOR_KEY and converted to big-endian(HTON) format. The code during execution XORs it again with the key which effectively retrieves the original value and uses it in the system calls.
The reason for this operation is to take care of NULL(‘00’) bytes. IP addresses and Port numbers might have NULL bytes in the value Ex: 127.0.0.1 and we consider an input with NULL bytes(‘bad’ chars) not ideal for injection since it might get truncated when the program reads into it.
The conversion of the IP and PORT number to the XOR encoded right format is handled by the shellcode generation script that is found in the same source repo.
‘dup2’ — this system call is what prepares for the magic to happen. It duplicates the 3 standard file descriptors(STDIN, STDOUT and STDERR) in the context of the running program such that the socket descriptor becomes an alias to all these 3 standard file descriptors.
‘execve’— the magic, this is the system call that executes the binary specified and inherits all the env variables and open file descriptors from the parent, remember we duped the standard file descriptors? Now any program invoked by execve has the standard file descriptors but are now pointing to the ones we set up in the previous call. So in effect all our standard file descriptors have become an alias to the socket descriptor. Any communications on these are proxied over the socket descriptor to the other end of the network. Did I say magic?
Detection: This kind of vulnerability is still relevant these days because the connection is initiated from within the victim network and is more likely to be less scrutinized. But with multiple tiered security like EDRs, Firewalls and Host/Network based rules/whitelisting and packet inspection, its difficult for an intruder to just connect to the machine and abuse it.
Please check the following github repo for the entire set of source files and helper scripts to generate and test the shellcode.
https://github.com/vikrant-navalgund/SLAE32
This blog post has been created for completing the requirements of the SecurityTube Linux Assembly Expert certification.
Student ID: SLAE -1100
