Retour a la page d'accueil

Switch to english

CCTT(1)

NAME

CCTT - Covert Channel Tunneling Tool


VERSION

Cette version 0.1.5 est une version alpha.


DISPOSITIONS LEGALES

CCTT a ete developpe dans l'objectif d'offrir aux responsables securite un moyen de verifier par la pratique l'etat de securite des reseaux dont ils ont LEGALEMENT la charge.

Toute utilisation de CCTT est subornee a l'acceptation de sa licence (voir COPYING) ainsi qu'au respect des dispositions legales propres au pays d'utilisation (voir le fichier LISEZMOI).


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

Ce manuel documente succinctement l'utilisation de Cctt.

Cctt est un outil permettant d'etablir des canaux subliminaux dans les flux autorises par les systemes de controle d'acces reseau mis en place.


PARAMETRES

Cctt utilise la syntaxe courante des lignes de commande GNU, avec des options en toute lettre precedees du double tiret ('-') ou leur equivalent raccourci.

Les parametres qui peuvent etre passes en ligne de commande sont :


-v, --version
  Affiche la version de Cctt.

-h, --help
  Affiche l'aide.

-d, --debug
  Affiche les messages de debug (pour les developpeurs).


Serveur :

-s, --listen_address
  Positionne l'adresse IP d'ecoute du serveur.

-p, --listen_port
  Positionne le port d'ecoute du serveur (Tcp 4242 par defaut).

-l, --logging
  Enregistre les sessions reverse-shell dans un fichier de log (rshells.log par defaut).

-L, --logging-syslog
  Envoie les messages verbeux vers Syslogd (daemon.notice par defaut).
  Tous les messages verbeux (si le flag -V a ete passe en ligne de commande) sont envoyes vers le demon syslogd local.
  Si le flag -V n'a pas ete passe en parametre, seule l'initialisation et l'arret du serveur sont consignes.


Client :

-c, --connect_address
  Positionne l'adresse IP de destination.

-d, --connect_port
  Positionne le port de destination (Tcp 4242 par defaut).

-r, --rshell
  Le client doit executer un shell inverse.

-i, --list_proxy_mode
  Le client demande la liste de proxy autorise par le serveur.

-a, --proxy_mode
  Le client doit fonctionner en mode proxy.

-z, --reverse_proxy_mode
  Le client doit fonctionner en mode proxy inverse.


General :

-t, --channel_type
  Positionne le type de canal (socket par defaut).

-f, --config_file
  Positionne le fichier de configuration (cctt_srv.cf et cctt_cl.cf par defaut).

-v, --verbose
  Execute Cctt en mode verbeux.

-T, --check_conf_file
  Verifie la syntaxe du fichier de configuration et quitte.


TYPES DE CANAUX :

Les types de canaux sont positionnes via la ligne de commande mais font appel a des directives qui doivent etre positionnees dans les fichiers de configuration :


socket
Le canal consiste dans l'etablissement d'une socket PF_INET (basee sur le protocole TCP ou UDP : voir FICHIERS DE CONFIGURATION) standard entre client et serveur.
Aucun codage n'est realise et si la connexion tombe, les applications (shell, shell inverse et applications fonctionnant en mode proxy) sont tuees.


socket_encode
Ce type de canal est identique au canal socket mais le flot de donnees est code.
Une distance est calculee a partir d'une cle. Puis, on parcoure octet par octet un alphabet et la chaine a coder, on ajoute la distance au caractere courant de l'alphabet, on ajoute le resultat au caractere a coder, on fait quelques modulos pour demeurer dans une fourchette sizeof(unsigned char) et on cree la chaine codee. Si on parvient a la fin de l'alphabet, on boucle.
La chaine resultat est ensuite convertie en une suite de valeur hexadecimale (entre 00 et FF).


socket_http_proxy
Ce type de canal est identique au canal socket, mais utilise la methode CONNECT sur un serveur mandataire HTTP.
Le client ouvre une connexion avec un serveur mandataire HTTP, puis envoie la requete CONNECT @IP_serveur_Cctt:Port_serveur_Cctt HTTP/1.0. Si la connexion est acceptee par le serveur mandataire (reception de HTTP/1.0 200 Connection established), alors le canal est considere comme etabli.


socket_http_proxy_encode
Ce type de canal est identique au canal socket_http_proxy, mais les donnees sont codees comme pour le type de canal socket_encode.


client_only_with_http_proxy
Ce type de canal est identique au canal socket_http_proxy et n'est utilisable que par le client.

Il permet de beneficier des fonctionnalites de Cctt, tant du point de vue des services (shell, reverse-shell et mode proxy) que du point de vue de l'utilisation de la chaine de proxy sans etre oblige d'installer un serveur CCTT (le demon peut donc etre un service standard : ssh, netcat, etc...). Aucun paquet supplementaire n'est ajoute au flux (pas d'identification, pas de demande de service).


test
Ce type de canal est utilise pour le developement de nouvelles fonctionnalites.


FICHIER DE CONFIGURATION SERVEUR

Les fichiers de configuration permettent de positionner plusieurs directives relatives au fonctionnement de Cctt.


Directives du fichier de configuration Serveur :


PROTOCOL=tcp|udp
C'est le protocole qui est utilise pour l'etablissement de la socket entre le client et le serveur ou entre le client et le serveur mandataire. Dans le cas d'une utilisation d'un serveur mandataire, ce protocole est obligatoirement tcp.
Cette directive est obligatoire.


FAKE_WEBSERVER=file
Si un client ne parvient pas a passer le stage de l'identification, le contenu du fichier lui est envoye et la connexion est fermee.


Directives d'identification :

Ces directives permettent de specifier la methode d'identification utilisee entre client et serveur.


IDENT=xxx_ident
C'est le type d'identification parametre entre serveur et client. Il doit etre identique dans les deux fichiers de configuration et peut contenir les valeurs: clear_ident, basic_ident.

clear_ident ne contient aucun codage, la cle est envoyee telle quelle.
basic_ident contient un codage base sur le meme principe que le type de canal socket_encode.

Cette directive est obligatoire et est forcemment accompagnee de la directive IDENT_KEY.


IDENT_KEY=xxx
C'est la cle qui est utilisee pour identifier le client aupres du serveur. C'est une chaine ASCII.

Cette directive est obligatoire et est forcemment accompagnee de la directive IDENT.


Directives Mode Proxy :

Voir l'explication dans la partie relative au client.


PROXY_MODE_LIST=label:@IP:Port
Cette directive peut etre employee plusieurs fois si label est unique pour chaque ligne. C'est la liste d'autorisation de transfert pour les clients qui desirent fonctionner en mode proxy.
Le serveur recoit une requete, verifie si la demande est parametree dans sa liste et le cas echeant fonctionne en mode proxy pour le service label entre le client et l'application presente derriere @IP:Port.


PROXY_ONLY=ON|OFF
Indique au serveur de se positionner en mode proxy_only ou non. Ce mode configure le serveur de telle sorte qu'il refuse les demandes de shell ou de reverse-shell et de telle sorte que l'entree standard (voir MODE INTERACTIF) ne soit pas disponible.
Le serveur peut ainsi etre lance sans etat d'ame en background et utiliser les fonctionnalites de suppression des privileges (voir Directives de securisation du serveur).


Directives de configuration du shell :


SRV_SHELL_LOC=/path/to/shell
C'est le chemin absolu (attention au nom lors de l'utilisation de liens symboliques) menant a un interpreteur de commande (shell). Il est utilise dans le cas ou le client demande un shell au serveur.
Si le serveur ne veut pas offrir de shell au client, cette directive peut etre positionnee /path/to/false ou /path/to/nologin.

Cette directive est forcemment accompagnee de la directive SRV_SHELL_CMD.


SRV_SHELL_CMD=shell
C'est le nom de l'interpreteur de commande (shell) qui est configure dans la directive SRV_SHELL_LOC dont cette directive est forcemment accompagnee.


Directives de securisation du serveur :

Ces directives ne sont applicables que si le serveur est lance sous l'identite du super utilisateur.


PERM_USER_GROUP=user
Apres initialisation, le serveur prend l'identite (gid,uid) indiquee par l'utilisateur user.

Si la directive PERM_CHROOT est positionnee, celle-ci est d'abord appliquee.


PERM_CHROOT=path/to/chroot/directory
Apres initialisation, le serveur se bloque avec un chroot dans le repertoire indique.

Note: Ce repertoire doit etre un repertoire regulier et non un lien et doit permettre l'ecriture a l'identite sous laquelle tourne le serveur.


FICHIER DE CONFIGURATION CLIENT

Les fichiers de configuration permettent de positionner plusieurs directives relatives au fonctionnement de Cctt.


Directives du fichier de configuration Client :


PROTOCOL=tcp|udp
C'est le protocole qui est utilise pour l'etablissement de la socket entre le client et le serveur ou entre le client et le serveur mandataire. Dans le cas d'une utilisation d'un serveur mandataire, ce protocole est obligatoirement tcp.

Cette directive est obligatoire.


Directives d'identification :

Ces directives permettent de specifier la methode d'identification utilisee entre client et serveur.


IDENT=xxx_ident
C'est le type d'identification parametre entre serveur et client. Il doit etre identique dans les deux fichiers de configuration et peut contenir les valeurs: clear_ident, basic_ident.

clear_ident ne contient aucun codage, la cle est envoyee telle quelle.
basic_ident contient un codage base sur le meme principe que le type de canal socket_encode.

Cette directive est obligatoire et est forcemment accompagnee de la directive IDENT_KEY.


IDENT_KEY=xxx
C'est la cle qui est utilisee pour identifier le client aupres du serveur. C'est une chaine ASCII.

Cette directive est obligatoire et est forcemment accompagnee de la directive IDENT.


Directives Mode Proxy :

L'utilisation de l'une de ces directives entraine l'obligation d'utilisation des autres.


Le client se positionne en ecoute sur un couple @IP:Port. Quand une application se connecte, le client se connecte au serveur, s'identifie et envoie la demande de transfert au serveur. Si cette demande est acceptee, le client recupere les donnees envoyees par l'application, leur ajoute les divers codages demandes et envoie le resultat au serveur. Il procede inversement quand il recoit des donnees du serveur.

Si le serveur accepte la demande du client, il ouvre une connexion vers l'application qui est configuree dans sa liste et transmet les donnees du client a l'application apres suppression des divers codage realises sur le flot de donnees recu. Il procede inversement en recevant des donnees de l'application avant de les renvoyer vers le client.


PROXY_MODE_PROT=tcp
En mode proxy, c'est le protocole utilise entre l'application locale et le client ainsi qu'entre le serveur et le service distant. Pour l'instant, seul le protocole tcp est supporte.


PROXY_MODE_LOCAL_IP=@IP
En mode proxy, c'est l'adresse IP avec laquelle le client se positionne en ecoute.


PROXY_MODE_LOCAL_PORT=Port
En mode proxy, c'est le port sur lequel le client se positionne en ecoute.


PROXY_MODE_REMOTE_IP=@IP
En mode proxy, c'est l'adresse IP qui est envoyee dans la demande de transfert. Cette adresse IP est comparee par le serveur avec les adresses se situant dans ses directives PROXY_MODE_LIST.


PROXY_MODE_REMOTE_PORT=port
En mode proxy, c'est le port qui est envoye dans la demande de transfert. Ce port est compare par le serveur avec les ports situes dans ses directives PROXY_MODE_LIST.


Directives Mode Proxy Inverse:

L'utilisation de l'une de ces directives entraine l'obligation d'utilisation des autres.


Le client se connecte au serveur et s'enregistre comme relais pour le serveur defini grace aux directives de son fichier de configuration. Une fois l'enregistrement effectue, le client se met en attente de donnees.

Quand le serveur recoit une demande pour ce service, il envoie les donnees au client via la connexion existante en lui indiquant de quel client applicatif il les a recues.

Le client recoit les donnees et : soit il n'a recu aucune donnees de ce client applicatif, auquel cas il ouvre une connexion vers le service parametre et fait office de proxy - soit il a deja recu des donnees de ce client applicatif auquel cas il fait office de proxy pour une connexion qu'il a ouverte precedemment.

En d'autres termes, la connexion etablie entre le client et le serveur permet un multiplexage rudimentaire.


PROXY_MODE_PROT=tcp
En mode proxy inverse, c'est le protocole utilise entre le client et le service auquel il sert de relais. Pour l'instant, seul le protocole tcp est supporte.


PROXY_MODE_REMOTE_IP=@IP
En mode proxy inverse, c'est l'adresse IP du service auquel le client sert de relais. Cette adresse IP est ajoutee dynamiquement par le serveur dans une directive PROXY_MODE_LIST et retiree lorsque le client en mode inverse coupe la connexion.


PROXY_MODE_REMOTE_PORT=port
En mode proxy inverse, c'est le port du service auquel le client sert de relais. Ce port est ajoute dynamiquement dans une directive PROXY_MODE_LIST.


Directives utilisees pour un serveur mandataire :

L'utilisation de l'une de ces directives entraine l'obligation d'utilisation des autres.

Dans le cas d'une utilisation d'un serveur mandataire faisant l'intermediaire entre le client et le serveur (types de canaux *_http_proxy_*), ces directives permettent de configurer la liaison vers le serveur mandataire.


CHANNEL_PROXY_PROT=tcp
C'est le protocole utilise entre le client et le serveur mandataire. Pour l'instant, seul le protocole tcp est supporte.


CHANNEL_PROXY_IP=@IP
C'est l'adresse IP du serveur mandataire.


CHANNEL_PROXY_PORT=Port
C'est le port utilise par le serveur mandataire pour effectuer le proxying HTTP.


CHANNEL_PROXY_DEL=Delai
C'est le temps d'attente d'une reponse du serveur mandataire avant de considerer qu'on abandonne la connexion. Il s'exprime en micro-secondes.


HTTP_PROXY_CHAINE=@Ip2:Port2:Delai;...;@Ipx:Portx:Delai
Permet d'utiliser la methode CONNECT sur une chaine de serveurs mandataires HTTP.

La premiere connexion a lieu avec le proxy defini avec CHANNEL_PROXY_IP. Sur celui-ci est envoyee la requete CONNECT vers la premiere adresse IP de la chaine HTTP_PROXY_CHAINE. Quand cette chaine est vide, on envoie la requete CONNECT pour l'adresse IP du serveur que l'on veut atteindre.

Le delai d'attente est configurable pour chaque proxy.


MODE INTERACTIF

L'execution du serveur permet d'entrer quelques commandes en mode interactif. Ces commandes sont :


help
Affiche les commandes disponibles.


show connections
Affiche les connexions en cours.


show params
Affiche les informations d'initialisation du serveur.


kill connection X
Ferme la connexion allouee sur le socket descriptor X.


kill manager X
Tue le manager gerant la connexion allouee sur le socket descriptor X.


tell client X 'something'
Envoie la commande something au client de la connexion allouee sur le socket descriptor X.


quit
Stoppe le serveur.


SECURITE

Cctt est un outil de test. Je ne recommande donc pas son utilisation dans un environnement de production.


Aucun audit du code n'a eu lieu. Il serait preferable, si vous utilisez Cctt sur une plate-forme connectee a Internet, que vous l'executiez avec une identite possedant des droits restreints et qu'il soit bloque dans un cage.


Pour ce faire, soit vous creez votre environnement personel, soit vous utilisez les fonctionnalites presentees dans Directives de securisation du serveur.


AUTEUR

Simon Castro <scastro [at] entreelibre.com>


CONTRIBUTIONS

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


DISTRIBUTION

La derniere version de Cctt peut etre obtenue sur http://www.entreelibre.com/cctt


LICENCE

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

Simon Castro
Maj le 26 Mars 2003