(Please note this post was originally published in the Spanish version of Security Art Work last 26th Oct 2010)
Covert channels is an evasion technique that allows an attacker to send information using the communication protocols headers. In this post we will cover-up of channels in the TCP/IP protocols and provide a tool, CovertShell, designed as a proof of concept. The sources are at the end of this post.
The TCP/IP protocol has headers that usually are initialized by the client to maintain or number a communication. The technique covert channels uses these fields to assign them values so the target machine does not interpret these fields as part of the communication, but to obtain data.
An interesting example was developed by Craig H. Rowland in his paper back in 1996: Covert Channels in the TCP/IP Protocol Suite, where he created a small client/server “CovertTCP” of no more than 500 lines that allowed file transfer between client and server, using for it only the fields SEQ, ACK (TCP protocol) and ID field (IP protocol). This information was on the protocol overhead and not in the payload.
Following this idea, we could go further and use this technique to send command orders. Something that could be used for both backdoors and botnets. Imagine that we have a compromised server that has installed a service that simply listens packets with some values in its header. When it receives a package with some requirements, it processes the values of such fields to convert headers into command orders, which are then executed.
Following this idea we have created a small tool as a proof of concept following CovertTCP source code, called CovertShell. We have a service that uses a RAW socket. When it receives a packet with ACK bit and without SYN bit, it gets the ID of the IP header, which corresponds to a letter in ASCII code. This letter is stored in a vector. When it receives 3 packets with ID 255, the server executes the command stored in the vector. Thus we have a server that does not open any ports but listens to the traffic and that is able to interpret the IP header to generate commands. Put it another way, we have a backdoor that uses covert channels to communicate. Confusing? Let’s see an example of operation:
Compile and run the service that wait for packets on port 8888 on the victim machine (server):
In another shell we check that the process is running and that there is not any service listening in port 8888:
Now we’ll use a small bash script (I want to thank Raúl Rodriguez) that requires the installation of Nemesis to easily manipulate packets. The script receives a command (in quotes), so that it will generate a packet for each letter of that command, where the value ID of the IP field will the ASCII value of the letter.
Within the script and have IP_DST and DPORT where you must specify the IP and port of your server victim. We also have IP_ORIGEN and SPORT which contains the source IP and port (can be any). For this POC we will tell Nemesis that the source IP address is a Google server and the source port is 80. Doing this, the victim server will receive packets with the ACK flag set apparently coming from a Google IP and port 80.
Thus, if we read the network trace we will see only ACK packets that are coming from google, maybe more than usual, when really what we are getting are backdoor commands.
For this demo we will create the user “ximo” on the victim machine:
Server (Dato recibido translates as Data received ):
Did it work?
Now let’s look at the network trace from the server (IP 172.17.XX) when we sent the command “useradd ximo”. In this case remember that we used the Google IP, so the source IP used is “184.108.40.206” obtained from a simple ping:
The server has received a number of TCP packets with ACK flag ([.]) from the Google IP (220.127.116.11), with source port 80 without payload, to which we answered with a RST packet. If you look at the sent packets you will see the “ID number” field which identifies the value of the IP protocol ID field, which has values like 117, 115, 101, 104, … that match the ASCII values of u, s, e, r, …
As you can guess, the ability to track this command is really hard because the victim does not receive the IP of the attacker as it spoofs the source IP.
But let’s go further: what if instead of using the IP protocol header ID, we use the sequence value (SEQ) of the TCP packet, so we sent a TCP packet with SYN flag set (start connection) to a public server whose source IP and port are the victim’s? The public server will reply the victim with a SYN ACK packet to the port indicated as source port, having as ACK value the session value sent by the attacker plus 1. Therefore it could used legitimate public servers so they send in the TCP header the command to be executed, being even more difficult to track who executed the command.
See a image that explains this idea:
(Please note: “Paquete” translates as “Packet“, “Origen” as “Source“, “Victima” as “Victim“, “Destino” as “Destination“, “Servidor” as “Server“, “Comando” as “Command” and “Atacante” as “Attacker“).