CCTT - Covert Channel Tunneling Tool

CCTT(1)

NAME

VERSION

This 0.1.5 version is an alpha one.

LEGAL CONSIDERATIONS

CCTT is aimed at offering security officers / engineers means for practically verifying the security of networks they're LEGALLY in charge of.

Any use of CCTT depends upon the acceptance of its license (see COPYING) as well as the respect of legal considerations specific to the country of use (see the README file).

SYNOPSIS

cctt -s listen_address [-p listen_port] [-f config_file] [-t channel_type] [-l] [-L] [-v] [-T]

cctt -c connect_address [-d connect_port] [-f config_file] [-t channel_type] [-r | -a | -i | -z] [-v] [-T]

cctt [ -V | -h ]

DESCRIPTION

This manual briefly describes the use of Cctt.

Cctt is a tool allowing the establishment of subliminal channels within the data streams authorized by the implemented network access control schemes.

PARAMETERS

Cctt uses the current syntax of the GNU command line, with capital letters options preceded by a double dash ('-') or their shortcut equivalent.

The corresponding parameters are :

-v, --version
Displays the Cctt version.

-h, --help
Displays help.

-d, --debug
Displays the debugging messages (for developers).

Server :

-s, --listen_address
Specifies the server's listening IP address.

-p, --listen_port
Specifies the server's listening port (Tcp 4242 by default).

-l, --logging
Specifies the reverse-shell sessions logfile to use (rshells.log by default).

-L, --logging-syslog
  Sends verbose messages to Syslogd (daemon.notice by default).
  All verbose messages (if the -V flag was specified at the command line) are sent to the local syslogd daemon.
  If the -V flag wasn't specified at the command line, the initialization and halting of the server are the only logged events.

Client :

-c, --connect_address
Specifies the server's destination IP address.

-d, --connect_port
Specifies the server's destination port (Tcp 4242 by default).

-r, --rshell
The client should execute a reverse-shell.

-i, --list_proxy_mode
The client asks for the list of proxies authorized by the server.

-a, --proxy_mode
The client should operate in proxy mode.

-z, --reverse_proxy_mode
The client should operate in reverse proxy mode.

General :

-t, --channel_type
Specifies the channel's type (socket by default).

-f, --config_file
Specifies the configuration file (cctt_srv.cf and cctt_cl.cf by default).

-v, --verbose
Executes Cctt in verbose mode.

-T, --check_conf_file
Checks the syntax of the configuration file and quits.

CHANNELS TYPES :

Channel types are specified at the command line but use directives that should be set in configuration files :

socket
The channel consists of the establishment of a standard PF_INET socket (based on the TCP or UDP protocol : see CONFIGURATION FILES) between the client and the server.
No encoding is performed and in case the connection is dropped, all applications (shell, reverse shell and applications operating in proxy mode) are killed.

socket_encode
This channel type is identical to the socket channel but the data stream is encoded.
A distance is computed from a key. Then, an alphabet and the chain to encode are scrolled byte by byte, the distance to the current alphabet character is added, the result being added to the character to encode, some modulos are performed in order to stay within a sizeof scope (unsigned char) and the encoded chain is created. If the alphabet's end is reached, one should recycle.
The resulting chain is then converted into a series consisting of hexadecimal values (between 00 and FF).

socket_encode_A
This channel type is identical to the socket_encode one but the encoded data are preceded by a simili HTTP header prior to being sent.

The pseudo header HTTP client is :

    POST /uri?random HTTP/1.0
    Content-Type: application/octet-stream
    User-Agent: Cctt
    Host: host
    Content-Length: length
    \n
    Encoded data
    \n\n

  random, length and Encoded data are dynamically computed before sending any data.
  The other fields are present is a static structure and are configurable.

  The pseudo header HTTP server is :

    HTTP/1.0 200 OK
    Date: Date
    Server: Cctt
    Last-Modified: Date
    Accept-Ranges: bytes
    Content-length: length
    Content-Type: text/html
    \n
    Encoded data
    \n\n

Date, length and Encoded data are dynamically computed before sending any data.
The other fields are present is a static structure and are configurable.

socket_http_proxy
This channel type is identical to the socket one, but uses the CONNECT method on a mandatory HTTP server.
The client opens a connection with a mandatory HTTP server, then sends the CONNECT request @IP_serveur_Cctt:Port_serveur_Cctt HTTP/1.0. If the connection is accepted by the mandatory server (reception of HTTP/1.0 200 Connection established), then the channel is considered established.

socket_http_proxy_encode
This channel type is identical to the socket_http_proxy one, but the data are encoded as for the socket_encode channel type.

socket_http_proxy_encode_A
This channel type is identical to the socket_http_proxy_encode channel, but the data are encoded as for the socket_encode_A channel type.

client_only_with_http_proxy
This channel type is identical to the socket_http_proxy channel and can be only be used by the client.

It allows to benefit from the Cctt functionnalities, such as services (shell, reverse-shell and proxy mode) as well as the use of the proxy chain without the constraint of installing a CCTT server (the daemon can hence be a standard service : ssh, netcat, etc...). No additional packet is added to the stream (no identification, no service request).

test
This channel type is used for the development of new functionnalities.

SERVER CONFIGURATION FILE

Configuration files allow for the positionning of several directives linked to the Cctt operation.

Directives of the server configuration file :

PROTOCOL=tcp|udp
It's the protocol used for the socket establishment between the client and the server or between the client and the mandatory server. In case a mandatory server is used, this protocol is necessarily tcp.
This directive is mandatory.

FAKE_WEBSERVER=file
If a client doesn't manage to overcome the identification stage, the file content is sent to him and the connection is closed.

Identification directives :

These directives allow specifiing the identification method used between the client and the server.

IDENT=xxx_ident
It's the identification type parametered between the server and the client. It must be identical to the two configuration files and can contain the clear_ident, basic_ident and basicA_ident values.

clear_ident doesn't contain any encoding, the key being sent as is.
basic_ident contains an encoding based on the same principle of the socket_encode channel type.
basicA_ident contains an encoding based on the same principles of the socket_encode_A channel type.

This directive is mandatory and is necessarily accompanied by the IDENT_KEY directive.

IDENT_KEY=xxx
This is the key used to identify the client before the server. It's an ASCII chain.

This directive is mandatory and is necessarily accompanied by the IDENT directive.

Proxy mode Directives :

See the explanation in the part pertaining to the client.

PROXY_MODE_LIST=label:@IP:Port
This directive can be used several times if label is unique for each line. It's the transfer authorization list for clients that wish to operate in proxy mode.
The server receives a request, verifies if the demand is parametered in its list and if it is, operates is proxy mode for the label service between the client and the application that is behind @IP:Port.

PROXY_ONLY=ON|OFF
Asks the server whether it should or not act in proxy-only mode. This mode configures the server such that it refuses shell or reverse-shells demands and such that the standard input (see INTERACTIVE MODE) isn't available.
The server can hence be launched in background and use the privilege suppression functionnalities (see Server Securing Directives).

Shell configuration directives :

SRV_SHELL_LOC=/path/to/shell
This it the absolute path (beware of the name when using symbolic links) leading to a command interceptor (shell). It is used when the client asks the server for a shell.
If the server doesn't want to offer the shell to the client, this directive can be set to /path/to/false or /path/to/nologin.

This directive is necessarily accompanied by the SRV_SHELL_CMD one.

SRV_SHELL_CMD=shell
It's the command interceptor's (shell) name which is configured is the SRV_SHELL_LOC directive by which this directive is necessarily accompanied..

Server securing directives :

These directives are only applicable if the server is launched under the super user identity.

PERM_USER_GROUP=user
After initialization, the server takes the (gid,uid) identity indicated by the user user.

If the PERM_CHROOT directive is set, PERM_CHROOT is first applied.

PERM_CHROOT=path/to/chroot/directory
After initialization, the server is jailed with a chroot in the specified directory.

Note: This directory must be a regular one and not a link and must allow writing under the identity under which the the server operates.

CLIENT CONFIGURATION FILE

Configuration files allow the setting of several directives relative to the Cctt functionning.

Directives for the client configuration file :

PROTOCOL=tcp|udp
This is the protocol used for establishing the socket between the client and the server or between the client and the mandatory server. If a mandatory server is to be used, this protocol is necessarily tcp.

This directive is mandatory.

Identification directives :

These directives allow for the specification of the identification method used between the client and the server.

IDENT=xxx_ident
This is the identification type parametered between server and client. It must be identical in the two configuration files and can contain the following values: clear_ident, basic_ident et basicA_ident.

clear_ident doesn't contain any encoding, the key being sent as is.
basic_ident contains an encoding based on the same principle as the socket_encode channel type.
basicA_ident contains an encoding based on the same principle as the socket_encode_A channel type.

This directive is mandatory and is necessarily accompanied by the IDENT_KEY directive.

IDENT_KEY=xxx
This is the key used by the server to identify the client. It's an ASCII chain.

This directive is mandatory and is necessarily accompanied by the IDENT one.

Proxy mode directives :

The use of one of these directives leads necessarily to the use of others.

The client listens on a couple @IP:Port. When an application is connecting, the client connects to the server, identifies itself and sends the transfer request to the server. If this demand is accepted, the client recuperates the data sent by the application, adds to them the several requested encodings and sends the result to the server. It proceeds reversely when it receives data from the server.

if the server accepts the client's demand, it opens a connection towards the application that is configured in its list and transmits the data from the client towards the application after suppressing the several encodings to which the received data stream was subjected. It proceeds reversely when receiving data from the application before sending them back to the client.

PROXY_MODE_PROT=tcp
In proxy mode, it's the protocol used between the local application and the client as well as between the server and the remote service. For the time being, only the tcp protocol is supported.

PROXY_MODE_LOCAL_IP=@IP
In proxy mode, it's the listening IP address of the client.

PROXY_MODE_LOCAL_PORT=Port
In proxy mode, it's the port on which the client is listening.

PROXY_MODE_REMOTE_IP=@IP
In proxy mode, it's the IP address that is sent in the transfer request. This IP address is compared by the server to the addresses contained in its PROXY_MODE_LIST directives.

PROXY_MODE_REMOTE_PORT=port
In proxy mode, it's the port that is sent in the transfer request. This port is compared by the server to the ports contained is its PROXY_MODE_LIST directives.

Reverse proxy mode directives :

The use of one of these directives leads necessarily to the use of others.

The client opens a connection to the server and records itself into the server proxy-mode list as a proxy for the service configured in its configuration file.

When the server gets a request for this service, it uses the openned connection to tell the client from which application client it received the datas and acts as a proxy for the data stream.

The client receives data and : If it never received datas from this application client, it opens a tcp connection to the configured service and acts as a proxy - if it already received datas from this application client, it acts as a proxy for an existing connection.

To sum up, the established connection between client and server allows a rudimentary multiplexing.

PROXY_MODE_PROT=tcp
In reverse proxy mode, it's the protocol used between the client and the application service for which the client acts as a proxy. For the time being, only the tcp protocol is supported.

PROXY_MODE_REMOTE_IP=@IP
In reverse proxy mode, it's the IP address of the application service for which the client acts as a proxy. This IP Address is dynamically added in the server PROXY_MODE_LIST and dynamically removed when the client drops the connection.

PROXY_MODE_REMOTE_PORT=port
In reverse proxy mode, it's the port of the application service for which the client acts as a proxy. It is dynamically added in the server PROXY_MODE_LIST.

Directives used for a mandatory server :

The use of one of these directives leads necessarily to the use of all others.

In case a mandatory server is used as an intermediary between client and server (*_http_proxy_* channel types), these directives allow for the link configuration towards the mandatory server.

CHANNEL_PROXY_PROT=tcp
It's the protocol used between the client and the mandatory server. For the time being, only the \fItcp\fP protocol is supported.

CHANNEL_PROXY_IP=@IP
It's the mandatory server IP address.

CHANNEL_PROXY_PORT=Port
It's the port used by the mandatory server for HTTP proxying.

CHANNEL_PROXY_DEL=Time
It's the waiting time for an answer from the mandatory server before considering the connection drop. It is expressed in microseconds.

HTTP_PROXY_CHAINE=@Ip2:Port2:Time;...;@Ipx:Portx:Time
Allows for the use of the CONNECT method on an HTTP mandatory servers chain.

The first connection takes place with the proxy defined with CHANNEL_PROXY_IP. The CONNECT request is sent on the latter towards the first IP address of the HTTP_PROXY_CHAINE chain. When this chain is empty, the CONNECT request is sent towards the IP address of the server to be reached.

The waiting delay is configurable for each proxy.

INTERACTVE MODE

The server execution allows for the seize of a few commands in interactive mode. These are :

help
Displays available commands.

show connections
Displays ongoing connections.

show params
Displays the server's initialization informations.

kill connection X
Closes the connection allocated on the X socket descriptor.

kill manager X
kills the manager handling the connection allocated on the X socket descriptor.

tell client X 'something'
Sends the something command to the client of the connection allocated on the X socket descriptor.

quit
Stops the server.

SECURITY

Cctt is a testing tool. Hence, I don't recommand its use within a production environment.

The tool's code hasn't been audited. It would be preferable, when using Cctt on an Internet connected platform, to launch it under a restricted rights identity and to block it in a jail.

To achieve this, one must either create a personal environment, either use functionnalities present under the Server securing directives.

AUTHOR

Simon Castro <scastro [at] entreelibre.com>

CONTRIBUTIONS

Olivier Dembour <odembour [at] entreelibre.com>, Hadi El-Khoury <helkhoury [at] entreelibre.com> and Alex Dyatlov <alex [at] gray-world.net>

DISTRIBUTION

The latest version of Cctt can be obtained from http://www.entreelibre.com/cctt

LICENSE

CCTT - Covert Channel Tunneling Tool - v0.1.5, Copyright (C) 2002,2003 Simon Castro (scastro@entreelibre.com)

Cctt is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.

Cctt is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with Cctt; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA02111-1307 USA

Cctt v0.1.5 CCTT(1)

Licence :

This website and its content is part of the online documentation of CCTT - Covert Channel Tunneling Tool v0.1.5 - Copyright (C) 2002,2003 Simon Castro.

Cctt is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.
Cctt is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License along with Cctt; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA02111-1307 USA

Hadi El-Khoury and Simon Castro
Last updated on the 26th of March 2003