Retour a la page d'accueil

Switch to english

Figurent ici divers exemples d'utilisation de CCTT presentes selon le plan suivant :

  Quel type d'architecture devons nous traverser ?
  Quelles sont les fonctionnalites que nous desirons ?
  Quels sont les fichiers de configuration client et serveur ?
  Quels sont les parametres a passer en ligne de commande ?

Les exemples présentés sont les suivants :

  I) Architecture HTTP avec serveur mandataire : Acces a divers services externes.
  II) Architecture a 'trous' sur le protocole UDP.
  III) Entrer Login/Password sur un site Web en utilisant CCTT.
  IV) Beneficier des fonctionnalites de CCTT (chaine de proxy) avec le client uniquement.
  V) Demonstration du concept de mode proxy inverse avec CCTT.
  VI) Mode HTTP : Confusion par emission/reception de messages HTTP inutiles.
  VII) Mode HTTP : Confusion par une gestion du comportement du serveur.
  VIII) Mode HTTP : Confusion par encapsulation des donnees utiles dans des donnees inutiles.


I) Architecture HTTP avec serveur mandataire : Acces a divers services externes


CCTT - Exemple 1

A] Type d'architecture


L'architecture type est celle d'une entreprise dont le seul moyen de sortir vers l'exterieur est d'utiliser un serveur mandataire HTTP offrant la methode CONNECT a destination de serveurs externes en ecoute sur le port 443.
Nous connaissons l'adresse IP du proxy : 192.168.1.1 et son port d'ecoute : 8080.


B] Fonctionnalites desirees


Nous desirons, a partir du reseau interne :
  * Acceder a notre station personnelle connectee a Internet en SSH (111.222.1.1).
  * Acceder a notre serveur SMTP heberge chez un ISP (111.222.2.1).
  * Acceder a notre serveur POP heberge chez un ISP (111.222.2.2).


C] Fichiers de configuration


Notre station personnelle doit etre configuree comme suit :
  * Un serveur SSH en ecoute sur le loopback.
  * Autorisations d'entree/sortie du Fw pour acceder a notre Pop et a notre Smtp.
  * Un utilisateur cctt sans shell doit etre cree sur notre station Internet.
  * Un repertoire cage servant au chroot doit etre cree sur notre station Internet.
  * Et pour finir, il nous faut l'acces super-utilisateur pour pouvoir binder le port 443.


Le fichier de configuration srv_exemple_1.cf du serveur doit etre le suivant :

    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


Les fichiers de configuration du client doivent etre les suivants :


  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] Parametres de ligne de commande et execution


Pour lancer le serveur, nous entrons (en tant que root) la commande :
  cctt -s 111.222.1.1 -p 443 -f srv_exemple_1.cf -t socket_encode -L -v &

Pour lancer les clients, nous entrons (sans etre root) les commandes :
  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 &

Nous disposons desormais sur notre station du reseau interne de trois ports en ecoute sur le loopback :
  * le port 4222 nous permet d'atteindre notre station personnelle connectee a Internet en SSH.
  * le port 4225 nous permet d'atteindre notre serveur SMTP externe.
  * le port 42110 nous permet d'atteindre notre serveur POP externe.

Le serveur present sur notre station personnelle Internet tourne sous l'identite restreinte cctt, est chroote dans le repertoire cage et envoie les messages verbeux au demon Syslogd.


II) Architecture a 'trous' sur le protocole UDP


CCTT - Exemple 2

A] Type d'architecture


L'architecture que nous traversons est fictive et composee d'un systeme de controle d'acces reseau mal parametre.
Nous imaginons qu'il est possible, a partir d'une station du reseau interne, d'envoyer/recevoir des datagrammes UDP a un serveur present sur Internet en ecoute sur le port 7272.


B] Fonctionnalites desirees


Nous desirons creer un reverse-shell se connectant au serveur present sur Internet (111.222.1.1:7272).
Ce faisant, nous obtenons a partir d'Internet un acces au reseau interne de l'entreprise.


C] Fichiers de configuration


Notre station personnelle doit etre configuree comme suit :
  * Autorisations d'entree/sortie du Fw pour recevoir/envoyer des datagrammes avec un port source UDP 7272.
  * Un utilisateur cctt sans shell doit etre cree sur notre station Internet.
  * Un repertoire cage servant au chroot doit etre cree sur notre station Internet.
  * Et pour finir, l'acces super-utilisateur pour pouvoir blinder le serveur.


Le fichier de configuration srv_exemple_2.cf du serveur doit etre le suivant :

  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


Le fichier de configuration cl_exemple_2.cf du client doit etre le suivant :

  PROTOCOL=udp
  IDENT=basic_ident
  IDENT_KEY=simsim


D] Parametres de ligne de commande et execution


Pour lancer le serveur, nous entrons (en tant que root) la commande :
  cctt -s 111.222.1.1 -p 7272 -f srv_exemple_2.cf -t socket_encode -l &
Pour lancer le client, nous entrons (sans etre root) la commande :
  cctt -c 111.222.1.1 -d 7272 -f cl_exemple_2.cf -t socket_encode -r &
En utilisant le mode interactif du serveur, nous avons desormais un access shell, a partir d'Internet, au reseau interne de l'entreprise.

De plus, la session du shell inverse est enregistre dans un fichier de log.


III) Entrer Login/Password sur un site Web en utilisant CCTT


A] Type d'architecture


Nous prenons une architecture semblable a celle de l'exemple I) mais n'importe quel type aurait fait l'affaire - C'est l'idee qui nous interesse.
Nous connaissons l'adresse IP du proxy : 192.168.1.1 et son port d'ecoute : 8080 - ainsi que son autorisation de sortie en mode CONNECT vers le port 443.


B] Fonctionnalites desirees


Nous devons nous identifier sur un site Web Internet (111.222.7.7) a partir du reseau local de l'entreprise.
Le Hic est que cette identification se fait sans SSL, et que nous ne voulons pas que les administrateurs systeme/reseau puissent avoir acces a notre login/password.


C] Fichiers de configuration


Notre station personnelle (111.222.1.1) doit etre configuree comme suit :
  * Autorisations d'entree/sortie du Fw pour acceder au serveur Web distant.
  * Un utilisateur cctt sans shell doit etre cree sur notre station Internet.
  * Un repertoire cage servant au chroot doit etre cree sur notre station Internet.
  * Et pour finir, il nous faut l'acces super-utilisateur pour pouvoir binder le port 443.


Le fichier de configuration srv_exemple_3.cf du serveur doit etre le suivant :

  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


Le fichier de configuration cl_exemple_3.cf du client doit etre le suivant :

  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] Parametres de ligne de commande et execution


Pour lancer le serveur, nous entrons (en tant que root) la commande :
  cctt -s 111.222.1.1 -p 443 -f srv_exemple_3.cf -t socket_encode -L -v &
Pour lancer le client, nous entrons (sans etre root) la commande :
  cctt -c 111.222.1.1 -d 443 -f cl_exemple_3.cf -t socket_http_proxy_encode -a &
Nous pouvons desormais configurer notre client web pour qu'il utilise 127.0.0.1:4280 comme proxy http. Ainsi, toutes nos requetes a destination du serveur Web (ou des virtualhosts qu'il gere) transiteront par le canal CCTT qui est encode.


IV) Beneficier des fonctionnalites de CCTT (chaine de proxy) avec le client uniquement


CCTT - Exemple 4

A] Type d'architecture


Nous prenons une architecture semblable a celle de l'exemple I) mais n'importe quel type aurait fait l'affaire - C'est l'idee qui nous interesse.
Nous connaissons l'adresse IP du proxy : 192.168.1.1 et son port d'ecoute : 8080 de notre reseau local d'entreprise.
Nous connaissons l'adresse IP de deux autres proxys se trouvant sur Internet et supportant egalement la methode CONNECT (111.111.1.1:8080 et 222.222.2.2:8080).
Nous savons que ces trois proxys possedent une autorisation de sortie vers les ports 443 et 8080.


B] Fonctionnalites desirees


Nous desirons nous connecter en SSH sur notre station personelle connectee a Internet et situee sur 111.222.1.1:443.
Notre serveur SSH personnel est en ecoute sur ce port et nous voulons : 'NE RIEN INSTALLER SUR NOTRE MACHINE PERSO' :)


C] Fichiers de configuration


Le fichier de configuration cl_exemple_4.cf du client doit etre le suivant :

  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] Parametres de ligne de commande et execution


Pour lancer le client, nous entrons (sans etre root) la commande :
  cctt -c 111.222.1.1 -d 443 -f cl_exemple_4.cf -t client_only_with_http_proxy &
Nous possedons desormais un client Cctt en ecoute sur localhost:4222. Quand ce client recoit une connexion, il se connecte sur le premier proxy, puis sur le deuxieme, puis le troisieme et finalement parvient a notre serveur.
A ce moment, nous disposons d'un canal TCP standard entre l'application locale et l'application distante.


V) Demonstration du concept de mode proxy inverse avec CCTT


CCTT - Exemple 5

A] Type d'architecture


Nous prenons une architecture semblable a celle de l'exemple I) mais n'importe quel type aurait fait l'affaire - C'est l'idee qui nous interesse.
Nous connaissons l'adresse IP du proxy : 192.168.1.1 et son port d'ecoute : 8080 de notre reseau local d'entreprise.


B] Fonctionnalites desirees


Nous desirons acceder au serveur Web interne (192.168.2.1:80) ainsi qu'au serveur SMTP (192.168.2.2:25) de notre entreprise depuis l'exterieur.
Nous desirons autoriser deux stations externes (W1 et W2) a acceder au serveur Web et une troisieme station (S) a acceder au serveur SMTP via notre serveur CCTT positionne egalement sur une station externe (C - 111.222.1.1:443).


C] Fichiers de configuration


Le fichier de configuration (srv_exemple_5.cf) du serveur doit etre le suivant :

  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


Le fichier de configuration (cl_Wint_exemple_5.cf) du client interne doit etre le suivant pour l'acces au serveur Web :

  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


Le fichier de configuration (cl_Sint_exemple_5.cf) du client interne doit etre le suivant pour l'acces au serveur Web :

  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


Le fichier de configuration (cl_Wext_exemple_5.cf) du client externe doit etre le suivant pour l'acces au serveur Web :

  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


Le fichier de configuration (cl_Sext_exemple_5.cf) du client externe doit etre le suivant pour l'acces au serveur Web :

  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] Parametres de ligne de commande et execution


Nous commencons par lancer le serveur en entrant (en tant que root) la commande :
  cctt -s 111.222.1.1 -p 443 -f srv_exemple_5.cf -t socket -L -v &
Nous lancons ensuite les deux clients presents sur le reseau interne en mode proxy inverse :
  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 &

  => Ces deux clients s'enregistrent aupres du serveur en lui indiquant qu'ils sont les points de passages pour acceder aux serveurs Web et SMTP et conservent la connexion ouverte avec le serveur.

Note : Le serveur ajoute et retire dynamiquement les clients en mode proxy inverse lors des etablissements et ruptures de connexion.


Nous lancons ensuite les deux clients presents sur le reseau externe en mode proxy :
Sur W1, nous lancons :
  cctt -c 111.222.1.1 -d 443 -f cl_Wext_exemple_5.cf -t socket -a &
Sur S, nous lancons :
  cctt -c 111.222.1.1 -d 443 -f cl_Sext_exemple_5.cf -t socket -a &

  => Ces deux clients se mettent en attente de clients applicatifs.

Nous possedons maintenant deux services en ecoute : Le service d'acces au serveur Web est en ecoute sur @IP_W1:4280 et le service d'acces au serveur Smtp est en ecoute sur @IP_S:4225.


Quand un client veut acceder au serveur SMTP :
  * Il ouvre une connexion vers @IP_S:4225.
  * Le client CCTT present sur S ouvre une connection vers le serveur CCTT C et lui demande d'acceder au serveur SMTP.
  * Le serveur CCTT verifie dans sa liste d'autorisation proxy, trouve la connexion inverse existante vers le client CCTT interne gerant le SMTP et fait office de proxy.
  * Le client CCTT interne recoit des donnees, ouvre une connexion vers le serveur SMTP et fait office de proxy.

La meme chose est valable pour d'autres clients applicatifs SMTP ou pour les clients applicatifs Web.



VI) Mode HTTP : Confusion par emission/reception de messages HTTP inutiles.


Pour les fichiers de configuration, referez vous a doc/confs/http_post1.
Pour les parametres de ligne de commande, referez vous aux exemples precedents.


A] Type d'architecture


N'importe quelle architecture autorisant un utilisateur a envoyer des requetes HTTP POST avec ou sans utilisation d'un serveur proxy intermediaire.


B] Fonctionnalite presentee


Le mode HTTP de CCTT permet l'envoi de requetes HTTP POST inutiles au fonctionnement du canal.
Ces requetes peuvent etre envoyees par le client CCTT a intervalle regulier ou aleatoire au serveur CCTT et ne font pas partie des requetes utilisees pour le transport des donnees utiles.
Si ces requetes sont configurees au niveau du serveur CCTT, le serveur CCTT renvoie le contenu des fichiers demandes et ce contenu n'est tout simplement pas utilise par le client.

On obtient donc un trafic superflu qui permet d'accroitre la confusion d'un eventuel observateur.


VII) Mode HTTP : Confusion par une gestion du comportement du serveur.


Pour les fichiers de configuration, referez vous a doc/confs/http_post1.
Pour les parametres de ligne de commande, referez vous aux exemples precedents.


A] Type d'architecture


N'importe quelle architecture autorisant un utilisateur a envoyer des requetes HTTP POST avec ou sans utilisation d'un serveur proxy intermediaire.


B] Fonctionnalite presentee


Si le serveur est configure comme dans l'exemple VI), il est en mesure d'accepter des requetes qui ne proviendraient pas de clients CCTT.
Quand ces requetes sont configurees au niveau du serveur (GET /index.html HTTP/1.0 par exemple), le serveur renvoie le fichier correspondant et quand ces requetes ne sont pas configurees, le serveur renvoie une page d'erreur.
Un exemple de page pouvant etre renvoyee par le serveur est disponible ici.


VIII) Mode HTTP : Confusion par encapsulation des donnees utiles dans des donnees inutiles.


Pour les fichiers de configuration, referez vous a doc/confs/http_post2.
Pour les parametres de ligne de commande, referez vous aux exemples precedents.


A] Type d'architecture


N'importe quelle architecture autorisant un utilisateur a envoyer des requetes HTTP POST avec ou sans utilisation d'un serveur proxy intermediaire.


B] Fonctionnalite presentee


Le mode HTTP de CCTT permet d'ajouter des donnees arbitraires au debut ou a la fin des donnees utiles au canal de communication.
Ce "padding" peut etre ajoute tant dans les requetes POST du client que dans les reponses HTTP du serveur.

Un exemple de padding des requetes et reponses lors d'un echange en mode HTTP est present ici.


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
Maj le 9 Juin 2003