While researching on data exfiltration techniques and covert channels, I thought of making one of my own, dubbed ChorTCP. Though protocol over protocol tunneling is a well known concept but I really wanted to actually try to hypothesize one aspect and then implement it, just for fun. The abstract below is taken from the white paper, as is. The main benefit of this technique is that any deep packet inspection firewalls will not be able to see. The traffic will, at most, seem like a malformed traffic.
Introduction
ChorTCP is a covert channel created over TCP protocol. The overall concept revolves around the exfiltration of data without sending any data on the application layer level. This is accomplished by sending specially crafted packets with specific flags enabled — to the server. When packets generated are analyzed — they appear to be either random scans or malformed traffic.
Detailed description
The technique requires two components — a server and a client. The client is used to exfiltrate data and to be sent to the server. To bypass analysis and what data is being exfiltrated — flags are used. The advantage of this technique is that the sending and receiving protocol and the dictionary can be changed thus having many possible iterations of the same exfiltration technique.
The dictionary selected for this technique is the Morse-code cipher dictionary. Which has been modified for the current requirements of the technique. The details of the POC will be described later in this chapter but for now the protocol would be illustrated.
In Mores-code “.” And “-” are represented as short tone and long tone respectively. For sending Morse-code style data on TCP/IP network via the flags subtle changes were required. This would be explained later in the chapter.
Under the hood
The exfiltration protocol works with 4 Flags — [SYN, FIN, PSH, URG]. This technique is versatile and if required the flags can be changed.
The data exfiltration is performed using the SYN and URG flags. The PSH and the FIN flags are used for delimiter purposes. As mentioned earlier that the dictionary used was that of Morse-code and then was changed to fit the current technique. The “.” And “-” was replaced with SYN and URG respectively. Moreover — few other characters were also added. Thus — converting the Morse-code dictionary into:
Any data that the client program encounters — is encoded and then sent to the server on a specific port. The server does not open a socket to listen on the port — but in fact sniffs the traffic for the mutually decided port. The protocol works as follows:
As per the data which is to be exfiltrated each character is converted into code of SYN and URG. Which means that the character ‘r’ in the word root is converted to ‘SSSUUSU’ which would send SYN packets 3 times and then send 2 URG packets and then a SYN and an URG. The server on the other end would convert the incoming SYN and URG into ‘r’.
The protocol explained:
- The protocol for a non-NAT environment is illustrated below [Implemented in the POC]:
Client —|SYN|—> Server
Client —|SYN|—> Server
Client —|SYN|—> Server
Client —|SYN|—> Server
Client —|URG|—> Server
Client —|URG|—> Server
Client —|SYN|—> Server
Client —|URG|—> Server
Client —|FIN|—> Server
This packet tells the server that end of letter has reached
Server —|PSH|—> Client
The Server responds with acknowledgement by sending a PSH packet
Client —|SYN|—> Server
The client resumes the next character.
Once the word has reached, the client sends a FIN + PSH packet to the server informing for an end of word. This process keeps going until the end of data has reached.
- The protocol for the NAT network is illustrated below. It is to note that — this option is yet to be implemented and would not be a part of the POC.
Client —|SYN|—> Server
Client —|SYN|—> Server
Client —|SYN|—> Server
Client —|SYN|—> Server
Client —|URG|—> Server
Client —|URG|—> Server
Client —|SYN|—> Server
Client —|URG|—> Server
Client —|FIN|—> Server
This packet tells the server that end of letter has reached
Server —|PSH|—> Client
The Server responds with acknowledgement by sending a PSH packet
Client —|SYN|—> Server
The client resumes the next character.
It was observed that, in the environment where the implementation was tested, Network Address Translation for the FIN, PSH and URG packets was not happening. It was tested against TP-Link home wireless router and F-Secure Sense. Thus, the solution of removing the PSH packet from the protocol was hypothesized, this would remove the overhead of the Client waiting for an acknowledgement from the Server.
POC (ChorTCP)
The POC is implemented using Python and Scapy library. The POC would be uploaded soon. The code can be downloaded here…
Way Forward
The SYN based scanner would be implemented on the client side to first detect which ports are accessible outbound from the Target box and once determined — the client would start using that port for exfil. Moreover — as the server would be sniffing traffic on all the ports but when it receives a packet with same source and destination port — it would only start sniffing that port.
This was a very basic concept and has been tested on Non-NAT networks. Though more sophistication, as for example, adding functions to detect if the firewall is blocking the requests etc would be added later on.
First off let me explain what tunneling really is ? Well to make it simple i wont go into technical details but would say that for example you take a LAYS chips packet and put some thing in side it , that you are usually not allowed to send and you seal it back and send it through mail. Now the mail check post will check that its a Lays Chips packet and forward it and when it reaches your frnd ,he just unwraps it and gets the other wise forbidden object.