Index
Version Francaise
CCTT(1)
NAME
CCTT - Covert Channel Tunneling Tool
VERSION
This 0.1.7 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_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.
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).
http_post
This channel type mimics the HTTP protocol allowing client and server to exchange HTTP requests and responses messages. Have a look on HTTP POST server directives and HTTP POST client directives for further informations.
http_post_proxy
This channel type mimics the HTTP protocol allowing client and server to exchange HTTP requests and responses messages. Have a look on HTTP POST server directives and HTTP POST client directives for further informations.
The intermediary proxy management is :
If the proxy-chain functionality is not used, a TCP connection is openned to the proxy server and a specially crafted HTTP POST request is sended.
If the proxy-chain functionality is used, the CONNECT method is used until the last proxy server is reached and a specially crafted HTTP POST request is sended.
http_post_proxy2
This channel type is identical to the http_post_proxy one but uses the CONNECT method on a mandatory HTTP server.
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.
KILL_QUIET_DEL=x
Tells the server to close connections quiet since x msecs. If this directive is not set, the default value of the includes/configuration.h file is used.
KILL_QUIET_DEL_CF=x
Tells the server to close connections quiet since x msecs if the close_flag is set. If this directive is not set, the default value of the includes/configuration.h file is used.
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.
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.
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.
HTTP POST server directives :
When the http_post mode is used, the server is waiting for HTTP POST requests and answers with HTTP responses. As the client can close the TCP connection at regular interval, the server keeps its applications side running and use an unique client magic number to know if a new connection was already openned or if it needs a new context.
If a TCP connection is openned to the server and that the client request doesn't have the good URI, the server sends back an error page before closing the connection.
It is possible to tell the server to answer to certain requests. In this case, the server matches the request URI and sends back the related content file.
Adding top and/or bottom padding datas to the communication channel related data is configurable in the client and server parts. These padding datas are discarded by the client and server parts.
The next directives are mandatory for an http_post mode server.
HTTP_MOD_URI=/cgi-bin/cctt.cgi
The URI set tells the server that there is usefull datas into the HTTP request body.
HTTP_MOD_SRV_ERROR_PAGE=error_page.txt
This file will be sended by the server if the URI defined in the HTTP request is different from the HTTP_MOD_URI one and if the request URI is not found in any HTTP_MOD_SRV_FAKE_URLS one.
Next directives are optional in the server http_post mode.
HTTP_MOD_SRV_TOP_PAD=bytes
Tells the server there is bytes of unnecessary data at the top of the communication channel data of the HTTP request.
HTTP_MOD_SRV_BOT_PAD=bytes
Tells the server there is bytes of unnecessary data at the bottom of the communication channel data of the HTTP request.
HTTP_MOD_CL_TOP_PAD=path/to/file
Tells the server to add the content of the path/to/file at the top of the communication channel it will sends in its HTTP response.
HTTP_MOD_CL_BOT_PAD=path/to/file
Tells the server to add the content of the path/to/file at the bottom of the communication channel it will sends in its HTTP response.
HTTP_MOD_SRV_FAKE_URLS=path/to/file
Tells the server that it has to send the path/to/file file content when it gets a request with an URI related to this file.
This directive can be used several times.
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.
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.
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 tcp 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.
HTTP POST client directives :
When the http_post is set, the client opens a TCP connection, sends a configurable number of HTTP POST requests and receive the related HTTP responses. When the configurable number is reached, the TCP connection is closed but the client side applications are kept running. A new TCP connection is then openned and etc...
The client can send a configurable number of unnecessary requests to hide the legitimate ones. If these requests have an URI set into the server configuration, the server will send the content of the related file.
The client can also add top and/or bottom padding to its communication channel data. This may confuse an eventual observer if he finds html pages or image on the data stream and doesn't look inside carefully.
The next directives are mandatory for an http_post client.
HTTP_MOD_CL_REQ_PER_CON=x
Set the number of HTTP requests to send on a TCP connection before closing it and openning a new one.
HTTP_MOD_CL_DELAY_BET_CON=x
Set the waiting delay between two HTTP requests on a TCP connection.
HTTP_MOD_CL_HOSTNAME=hostname
Set this hostname into the related HTTP POST request header field.
HTTP_MOD_CL_CONTENTTYPE=content-type
Set this content-type into the related HTTP POST request header field.
HTTP_MOD_CL_DATASIZE=x
Tells the client to not send more than x bytes of data into an HTTP POST request.
HTTP_MOD_URI=/cgi-bin/cctt.cgi
Send the /cgi-bin/cctt.cgi URI in the HTTP POST request. This URI will be used by the server to know if there is any usefull data in the HTTP request.
The next directives are optional in the client http_post mode.
HTTP_MOD_SRV_TOP_PAD=bytes
Tells the client there is bytes of unnecessary data at the top of the communication channel data of the HTTP response.
HTTP_MOD_SRV_BOT_PAD=bytes
Tells the client there is bytes of unnecessary data at the bottom of the communication channel data of the HTTP response.
HTTP_MOD_CL_TOP_PAD=path/to/file
Tells the client to add the content of the path/to/file at the top of the communication channel it will sends in its HTTP request.
HTTP_MOD_CL_BOT_PAD=path/to/file
Tells the client to add the content of the path/to/file at the bottom of the communication channel it will sends in its HTTP request.
HTTP_MOD_CL_FAKE_URLS=GET /index.html HTTP/1.0
Tells the client to send the GET /index.html HTTP/1.0 request to the server. This request is unnecessary : If the server is configured to send the related content file, the client will read a part of this content and discard it.
This directive can be used several times.
Using the HTTP_MOD_CL_FAKE_URLS_FREQ is mandatory if you use this directive.
HTTP_MOD_CL_FAKE_URLS_FREQ=x
Tells the client to send the unnecessary HTTP HTTP_MOD_CL_FAKE_URLS requests at this interval.
If x is equal to -1, the unnecessary requests will be sent every y real request (and y is random). If x is equal to 1, the unnecessary requests will be sent for each real request and if x is equal to y>1, the unnecessary requests will be sent each y real request.
Using the HTTP_MOD_CL_FAKE_URLS directive is mandatory if you use this directive.
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.7, 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.7 CCTT(1)
Licence :
This website and its content is part of the online documentation of CCTT - Covert Channel Tunneling Tool v0.1.7 - 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
Simon Castro Last updated on the 9th of June 2003
|