Stage-Ta Thanh Dinh

Institut de la

Francophonie pour

l'Informatique

Centre de recherche

Nancy - Grande Est

MÉMOIRE de �n d'étudespour obtenir le titre de

Master en Informatique

Mention : Systèmes et Réseaux

Présenté et soutenu par

TA Thanh Dinh

Vers une méthode génériqued'attaque d'un botnet

STAGE dirigé par Jean-Yves Marion et Romain Péchoux

préparé à l'INRIA Nancy - Grande Est, Laboratoire de Haute

Sécurité

Remerciements

Ce travail n'aurait jamais vu le jour sans l'aide précieuse de monsieur Jean-YvesMarion. Il m'a guidé tout au long de la période de stage par ses explications aussiclaires que précises.

Je témoigne toute ma gratitude à monsieur Romain Péchoux qui m'a initié auπ − calcul appliqué au travers des discussions hebdomadaires et m'a donné desremarques sur la mémoire.

Je tiens à remercier monsieur Eric Thérond pour sa gentilesse. Il m'a aidé à dé-couvrir la vie en France, particulièrement à Nancy. Nous avons coopéré à l'executiond'un simulateur du botnet Waledac.

Je remercie chaleureusement toutes les personnes de l'équipe CARTE pour uneambiance de travail particulièrement favorable.

Merci en�n à mes parents, ma femme et mon �ls pour leur patience et leurencouragement à tout l'instant.

mailto:[email protected]




http://carte.loria.fr/

Résumé

Les travaux réalisés pendant la période de stage portent sur l'application des mé-thodes de la véri�cation des protocoles cryptographiques à l'attaque des botnets. Lavéri�cation automatique des protocoles cryptographiques est un sujet de recherchetrès actif. Elle vise à montrer mathématiquement la sécurité d'un protocole et détec-ter également des failles. Les botnets récents ont tendance d'utiliser des protocolescryptographiques pour protéger leur communication.

Nous étudions un botnet particulier, Waledac, qui utilise des algorithmescryptographiques pour sécuriser la communication entre ses bots. Ensuite, nousabordons quelques approches de la véri�cation des protocoles : spi−calcul et clausesde Horn. Pour attaquer de tels botnets, nous proposons �nalement une méthode gé-nérique qui exploite des vulnérabilités situées dans ses protocoles de communication.

Mots clés : méthode formelle, véri�cation des protocoles cryptographiques, spi-calcul, clauses de Horn, Waledac, botnet.

Abstract

In this internship, we deal with some methods of protocol veri�cation to proposea new method for attacking botnets. The veri�cation of cryptographic protocolsis a very active research topic. It aims to prove mathematically the security ofcommunication protocol. The recent botnets tend to use cryptographic protocols tosecure its communications.

We study the Waledac botnet as an particular use case. The bots of Waledac usesome cryptographic algorithms to protect their communications. Then we discussome approaches to protocol veri�cation : spi-calculus and Horn clauses. Finally, wepropose a generic method to attack Waledac botnet which exploits vulnerabilitieslocated in their communication protocols.

Keywords : formal method, protocol cryptographic veri�cation, spi-calculus,Horn clauses, Waledac, botnet.

Table des matières

1 Introduction 1

1.1 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Objectif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . 11.4 Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Le monde sauvage des botnets 3

2.1 Botnets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.1.1 Origin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.1.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.1.3 Objectif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 Méthodes de protection contre les botnets . . . . . . . . . . . . . . . 6

3 Botnet Waledac 9

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.1.1 Waledac . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.1.2 Objectif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.2 Caractéritiques techniques . . . . . . . . . . . . . . . . . . . . . . . . 103.2.1 Vecteurs d'infection . . . . . . . . . . . . . . . . . . . . . . . 103.2.2 Code binaire et protection . . . . . . . . . . . . . . . . . . . . 103.2.3 Taille du réseau Waledac . . . . . . . . . . . . . . . . . . . . . 113.2.4 Protocole de communication . . . . . . . . . . . . . . . . . . . 11

3.3 Structure du réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.3.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.3.2 Communications et messages échangés . . . . . . . . . . . . . 13

3.4 Primitives cryptographiques . . . . . . . . . . . . . . . . . . . . . . . 153.4.1 Chi�rement symétrique AES . . . . . . . . . . . . . . . . . . 153.4.2 Utilisation du chi�rement asymétrique RSA . . . . . . . . . . 16

3.5 Attaques contre Waledac . . . . . . . . . . . . . . . . . . . . . . . . . 163.5.1 Attaque de l'homme du milieu . . . . . . . . . . . . . . . . . 173.5.2 Attaque Sybil . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.6 Méthodes génériques d'attaque . . . . . . . . . . . . . . . . . . . . . 193.6.1 Analyses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193.6.2 Problématique et objectif . . . . . . . . . . . . . . . . . . . . 193.6.3 Outline de l'approche proposée . . . . . . . . . . . . . . . . . 20

4 Véri�cation des protocoles et méthodes formelles 25

4.1 Motivations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.1.1 Méthodes formelles pour la véri�cation de programmes . . . . 264.1.2 Protocole cryptographique, attaque et véri�cation . . . . . . . 27

vi Table des matières

4.1.3 Propriétés de sécurité . . . . . . . . . . . . . . . . . . . . . . 294.2 Protocole cryptographique . . . . . . . . . . . . . . . . . . . . . . . . 29

4.2.1 Primitives cryptographiques . . . . . . . . . . . . . . . . . . . 294.2.2 Exemple : protocole "Wide-Mouthed-Frog" . . . . . . . . . . 30

4.3 Modèles formels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.3.1 Algèbre de processus . . . . . . . . . . . . . . . . . . . . . . . 324.3.2 Pi-calcul et spi-calcul . . . . . . . . . . . . . . . . . . . . . . . 354.3.3 Modèle de traces et clauses de Horn . . . . . . . . . . . . . . 40

4.4 Modèles formels des attaques . . . . . . . . . . . . . . . . . . . . . . 444.4.1 Attaques en spi− calcul . . . . . . . . . . . . . . . . . . . . . 444.4.2 Attaques en clauses de Horn . . . . . . . . . . . . . . . . . . . 45

5 Solution à la méthode générique d'attaque 47

5.1 Méthode générique d'attaque . . . . . . . . . . . . . . . . . . . . . . 475.1.1 Plan d'attaque et analyses . . . . . . . . . . . . . . . . . . . . 475.1.2 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.2 Représentation de l'attaque contre Waledac . . . . . . . . . . . . . . 495.2.1 Modélisation du protocole de communication . . . . . . . . . 505.2.2 Attaque contre la distribution de la clé de session . . . . . . . 51

6 Conclusion et perspective 55

6.1 Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 556.2 Limite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 566.3 Perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 576.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

A ProVerif 59

A.1 ProVerif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59A.2 Modélisation du protocole de Waledac . . . . . . . . . . . . . . . . . 59

B Algèbre de processus 65

B.1 Processus Séquentiels Communicants . . . . . . . . . . . . . . . . . . 65B.2 LOTOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65B.3 Pi-calcul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

C Modèles des protocoles cryptographiques 67

C.1 Modèle symbolique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67C.2 Modèle calculatoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

D Simulateur du botnet Waledac 69

D.1 Conception du simulateur . . . . . . . . . . . . . . . . . . . . . . . . 69D.2 Expérimentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Bibliographie 73

Table des matières vii

Index 80

Table des �gures

2.1 Architecture traditionnelle. Crédit photo[Botezatu 2008] . . . . . . . 42.2 Architecture pair-à pair. Crédit photo[Botezatu 2008] . . . . . . . . . 52.3 Taille de quelques botnets. Crédit photo[atrocity 2010] . . . . . . . . 5

3.1 Opération de faux répéteur. Crédit photo[Stock 2009] . . . . . . . . . 113.2 Distribution de machines infectées pendant la journée 24 Août 2009.

Crédit photo[Stock 2009] . . . . . . . . . . . . . . . . . . . . . . . . . 123.3 Topologie du réseau de Waledac. Crédit photo[Tenebro 2009] . . . . 133.4 Messages échangés entre les spammeurs et le serveur de contrôle . . . 143.5 Méthode de mise à jour de RList . . . . . . . . . . . . . . . . . . . . 153.6 Méthode d'échange de clé de session . . . . . . . . . . . . . . . . . . 163.7 Modèle simple d'attaque . . . . . . . . . . . . . . . . . . . . . . . . . 213.8 Survol de l'approche proposée . . . . . . . . . . . . . . . . . . . . . . 22

4.1 Version simpli�ée du protocole de Denning-Sacco . . . . . . . . . . . 274.2 Attaque contre le protocole simpli�é de Denning-Sacco . . . . . . . . 284.3 Protocole Wide-Mouthed-Frog . . . . . . . . . . . . . . . . . . . . . . 314.4 Représentation symbolique du protocole . . . . . . . . . . . . . . . . 314.5 Diagramme états-transitions d'un distributeur des boissons . . . . . 344.6 Etablissement d'une connexion TCP . . . . . . . . . . . . . . . . . . 364.7 Modèle formel en π − calcul de l'établissement TCP . . . . . . . . . 364.8 Rélations de réaction . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.9 Modélisation des primitives cryptographiques . . . . . . . . . . . . . 384.10 Modèle formel en spi− calcul du protocole Denning-Sacco . . . . . . 39

5.1 Solution réalisable . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495.2 Communications entre les couches du botnet . . . . . . . . . . . . . . 505.3 Distribution de la clé session entre le spammeur et le serveur . . . . 505.4 Attaque contre protocole cryptographic du Waledac . . . . . . . . . . 51

6.1 Variant du protocole Needham-Schroeder . . . . . . . . . . . . . . . 56

C.1 Variant simple du protocole de Denning-Sacco . . . . . . . . . . . . . 68

D.1 Routage de messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 70D.2 Paramètres par défaut . . . . . . . . . . . . . . . . . . . . . . . . . . 70D.3 Simulateur de Waledac . . . . . . . . . . . . . . . . . . . . . . . . . . 71D.4 Le début du simulateur . . . . . . . . . . . . . . . . . . . . . . . . . 71D.5 Tous les spammeurs sont compromis . . . . . . . . . . . . . . . . . . 71

Chapitre 1

Introduction

Sommaire

1.1 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Objectif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.3 Environnement de travail . . . . . . . . . . . . . . . . . . . . . 1

1.4 Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.1 Problématique

Les botnets sont des réseaux de machines infectées. Ce réseau est structuré etune machine communique avec les autres par l'intermédiaire de protocoles sécurisés.Nous avons étudié le cas du botnet Waledac. À partir de cette étude, nous avonsconçu une attaque contre ce botnet. Il s'agit de pénétrer le botnet et de se fairepasser pour une machine infectée. À partir de là, il est possible de neutraliser unepartie du botnet. Ce concept d'attaque n'est possible que si le protocole de commu-nication entre les machines du botnet est vulnérable. La problématique générale estde concevoir une méthode pour pénétrer un botnet et le neutraliser.

1.2 Objectif

L'objectif du stage est la recherche d'attaque sur des protocoles malicieux. Pourcela, il faudra concevoir un modèle des communications du botnet. Ce modèle serabasé sur la logique du premier ordre ou sur un calcul de processus. Une fois la modé-lisation établie, il faudra concevoir un modèle d'attaque. En�n, il faudra ré�échir surdes outils automatiques capables de trouver une vulnérabilité dans ce protocole quipourrait conduire à neutraliser un botnet. Le travail demandé s'appuie sur les résul-tats établis dans le domaine de la véri�cation de protocoles et nos propres résultatsen virologie et sur les botnets.

1.3 Environnement de travail

Ce stage s'inscrit dans la mise en ÷uvre du laboratoire de haute sécurité (LHS)en informatique du LORIA. Les objectifs du LHS sont de conduire certaines expé-rimentations liées à la sécurité informatique, et plus particulièrement à la virologie.

http://lhs.loria.fr

http://www.loria.fr

2 Chapitre 1. Introduction

Cette plateforme de recherche est unique dans le monde académique et o�re denombreuses opportunités à l'application des recherches scienti�ques à la réalité.

1.4 Contribution

Les travaux réalisés pendant la période de stage se concentrent sur l'attaquecontre des protocoles cryptographiques utilisés par des botnets. Dans la section 3.6.3,nous proposons un nouveau "framework" servant à construire une attaque génériquecontre les botnets. Une telle attaque casse la sécurité des protocoles de communi-cation des botnet, donc peut être utilisée comme une base sur laquelle les attaquessuccessives peuvent se déroulent.

Dans la section 4.4.1, nous proposons une nouvelle idée de la modélisation de l'at-taque en spi−calcul. L'attaque est représentée comme un processus qui se fonctionneparallèlement au protocole, et essaie à révéler des informations que le protocole pro-tège. Cette modélisation nous permet de mettre en application une attaque formellecar la représentation en spi− calcul d'un processus est proche de sa représentationen un langage de programmation.

Dans le chapitre 5, nous donnons des analyses détaillés pour la mise en place duframework. D'une part, nous expliquons la nécessité d'utilisation des méthodes for-melles permettant de véri�er automatiquement les protocoles cryptographiques. Noustransformons donc un problème réel des botnets en un problème assez formel pourpro�ter les méthodes théoriques existantes. D'autre part, nous décrivons clairementquelle méthode appropriée à utiliser dans chaque étape du framework et propo-sons une solution réalisable du framework en se basant sur un outil de véri�cationautomatique, ProVerif.

Nous appliquons ces méthodes dans un cas particulier du botnet Waledac. Dansla section 5.2, nous présentons une représentation du protocole de communicationutilisé par le botnet en spi− calcul. Puis, nous utilison ProVerif pour véri�er cettereprésentation1. L'attaque contre Waledac est modélisée par un processus en spi−calcul, et nous décrivons une démonstration formelle qu'elle casse la con�dentialitédu protocole.

Notre framework ne se limite pas aux tels protocoles erronés comme ceux deWaledac. Il est capable de détecter des vulnérabilités (de protocole cryptographique)de n'importe quel botnet.

Finalement, nous implementons un simulateur2 de Waledac en C++. Ce simu-lateur nous permet de visualiser le fonctionnement du botnet.

1Le script de ProVerif est décrit dans l'annexe A2Ce simulateur peut être consulté dans l'annexe D

Chapitre 2

Le monde sauvage des botnets

Sommaire

2.1 Botnets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1.1 Origin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1.3 Objectif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 Méthodes de protection contre les botnets . . . . . . . . . . 6

2.1 Botnets

Cette section peut être considérée comme une introduction au monde des bot-nets. La plupart des informations présentées ici se base sur le travail de F. Ducrot,M. Danho et X. Marronnier[Ducrot 2007]. D'ailleurs, une analyse plus complète peutêtre consultée dans [Nachreiner 2008].

Nous commencerons par décrire l'origine et le développement des botnets, puisnous les examinerons au niveau de topologie de réseau. Ensuite, nous présenteronsquelques objectifs de botnet. Finalement, nous aborderons des méthodes de protec-tion.

2.1.1 Origin

Le terme botnet est revenu souvent dans l'actualité de la sécurité informatiquedepuis quelques années. Ce terme vient de la contraction de l'expression "roBOTNETwork", soit littéralement réseau de robots. Le botnet est donc l'ensemble derobots ou de bots, chacun étant un programme localisé sur la machine de victim ete�ectue des ordres préde�nis ou reçus par un serveur de contrôle.

Les premiers bots apparaissaient sur les réseaux IRC[Oikarinen 1993]. Les opé-rateurs du réseau IRC ont besoin des programmes qui les aident à gérer automa-tiquement des services du réseau, ils créent donc les robots IRC. Les robots IRCrestent toujours sur un canal IRC a�n de le maintenir tous les temps. Ils travaillentcomme un utilisateur normal du canal, mais il reste au repos jusqu'à ce qu'il ait uneaction particulière (une commande via canal IRC) à é�ectuer[EggHeads 2008]. Parexemple, le robot Eggdrop[Eggdrop 2008] est developé par R. Pointer en 1993 a�nde gérer et protéger le canal #gayteen sur le réseau EFnet[EFnet 2010].

4 Chapitre 2. Le monde sauvage des botnets

En 1999, le premier botnet utilisant IRC comme moyen de contrôle �t son ap-parition. Il s'agissait de W32. PrettyPark[Symantec 2007]. Ce botnet ne déclenchapas d'e�et de mode immédiat. À la �n de l'année 2000, le GTBot, un détournementdu client IRC Windows mIRC, �t son apparition. Ces robots de première générationn'apparurent pas cependant comme une menace majeure et sont aujourd'hui prati-quement oubliés. Ce fut à partir de 2002 que la menace commença à prendre saforme actuelle. Les programmes Agobot[InfectionVectors 2004], SDBot puis, l'annéesuivante, SpyBot sont les briques de base sur lesquelles se sont appuyés par la suiteles créateurs de botnets. Ces programmes sont construits de façon à faciliter l'émer-gence de nouvelles variantes en multipliant les moyens d'intrusion, les fonctionnalitéso�ensives et les moyens de protection.

2.1.2 Architecture

Un botnet est donc un ensemble de machines esclaves - les zombies, organisées enréseauu et contrôlées à distance par une ou plusieurs personnes. Du point de vue del'organisation, un botnet a pour objectif de permettre à un individu - le créateur dubotnet, de contrôler simultanément l'ensemble des machines esclaves. Le botnet estdonc un réseau hiéarchisé comprenant un serveur de contrôle et plusieurs machinesesclaves.

L'architecture traditionnelle comprend un ou plusieurs serveurs IRC qui sontutilisés comme canal de commande et contrôle. Après infection, les machines clientesdu botnet se connectent au serveur maître sur un calnal IRC privé a�n de signalerleur existence, d'obtenir des mises à jour ou des instructions.

Fig. 2.1: Architecture traditionnelle. Crédit photo[Botezatu 2008]

Le point faible de ce modèle d'organisation est sa sensibilité à la détection. Ene�et, une fois les maîtres identi�és, il su�t de surveiller et de �ltrer ceux-ci pourdémanteler le botnet ou le rendre inopérant sur un segment de réseau.

L'architecture pair-à-pair est caractérisée par la topologie décentralisée du réseaudans laquelle il n'y a plus de serveur de contrôle. Chaque machine infectée dispose

2.1. Botnets 5

d'une liste initiale d'adresses IP de points d'entrée dans le botnet. Une fois le botintégré au réseau, cette liste est mise à jour dynamiquement.

Fig. 2.2: Architecture pair-à pair. Crédit photo[Botezatu 2008]

Les commandes du maître sont relayées à travers l'ensemble du réseau grâce auxbots. Ils mettent donc plus de temps à se propager dans ce contexte, mais le réseauest plus robuste : la perte d'un n÷ud ne met pas à mal l'existence du réseau toutentier.

Il existe aussi des architectures variantes grâce à l'apparition de nouvelles mé-thodes de communication. Il s'agit de conserver les concepts essentiels de ces deuxarchitectures, mais en changeant le canal de contrôle. Par exemple, il est possibled'utiliser un serveur web en lieu et place du serveur IRC comme maître. L'avantagepour le pirate provient du fait que le tra�c web sortant d'un site n'est pratiquementjamais interdit, car trop abondant pour pouvoir être surveillé sans informationscomplémentaires.

La taille des botnets est très variable, de quelques centaines de machines zombiesà plusieurs dizaines de milliers. La moyenne est de l'ordre du millier d'éléments.

Fig. 2.3: Taille de quelques botnets. Crédit photo[atrocity 2010]

2.1.3 Objectif

En fait, les botnets sont l'illustration de la transformation du pirate informa-tique. Le dé� technique a fait place à une économie souterraine dans laquelle le

6 Chapitre 2. Le monde sauvage des botnets

piratage n'est qu'un outil qu'il faut rentabiliser. Le changement d'orientation dansles motivations des pirates, de la curiosité et de la recherche de notoriété vers larecherche de pro�ts �nanciers, a été marqué par l'apparition de bots de plus enplus sophistiqués et intégrant des fonctionnalités permettant de mener diverses ac-tions frauduleuses depuis les postes infectés. Les botnets présents servent donc auxobjectifs malveillants : attaques en dénie de service, di�usion de spams, etc.

Il est possible de louer les services d'un botnet pour monter une attaque dedéni de service distribué1. Ainsi, sur l'ordre du serveur maître, les machines esclavespeuvent lancer des attaques en présentant pour origine le site piraté. Par exemple,l'envoi sur le canal IRC d'une commande déclenche une attaque en déni de service.En utilisant plusieurs milliers de machines émettant des requêtes simultanément, ilest possible, par exemple, d'interdire l'accès à un site web. Les pertes subies par unsite commercial paralysé pendant plusieurs heures sont sans commune mesure avecle coût de location d'un botnet.

En 2004, Jay Echouafni, CEO d'une société de télévision enligne, a recouru auxservices d'un botnet pour attaquer des entreprises avec lesquelles il était en con�it.Sur le plan �nancier, l'attaque a coûté 1000$ à son organisateur et a entraîné despertes de l'ordre de 2.000.000$ à ses victimes[Poulsen 2004].

Les bots peuvent être utilisés pour émettre massivement des spams. Cette tech-nique o�re l'avantage à son commanditaire de camou�er son origine, permettantainsi de contourner les �ltrages par liste noire et les retours de bâton liés à l'envoimassif de spams2 ou encore le �ltrage de son accès par son fournisseur d'accès.

Il est possible d'utiliser les zombies3 pour recueillir des informations personnellessur les utilisateurs, informations qui seront utilisées dans le cadre de vols d'identitéou de fraude à la carte bancaire. Une autre attaque dirigée par les machines zombiesest la di�usion de logiciels publicitaires sur celles-ci.

2.2 Méthodes de protection contre les botnets

Dans cette section, nous aborderons des méthodes de protection contre les bot-nets. D'une part, il s'agit des méthodes concernant l'être humain, c'est-à-dire qu'ellesvisent à éduquer les utilisateurs à se mé�er. D'autre part, il existe des méthodes tech-niques qui éliminent les botnets en s'attaquant directement à ses vulnérabilités. Enfait, les deux méthodes se complétent en se formant un bouclier de multi-couches.Nous ne décrirons cependant que les méthodes techniques.

Les méthodes techniques visent à exploiter des vulnérabilités se situant danstoutes les caractéristiques (techniques) du botnet. Remarquons que le botnet n'estrien d'autre qu'un réseau de bots, ces caractéristiques peuvent être divisées doncen deux catégories, l'une concerne des codes binaires fonctionnant sur la machineinfectée, l'autre concerne des protocoles de communication sur le réseau.

1Distributed denial-of-service (DDoS)2Comme les vagues de retours d'erreurs massives pouvant survenir après les envois3Les machines infectées

2.2. Méthodes de protection contre les botnets 7

Le code du botnet fonctionne sur la machine infectée, il veux donc toujours se ca-cher de l'utilisateur. Les logiciels antivirus (ou anti-malware) visent à détecter, puisà élminer ce code malveillant. Ils doivent être capable donc de casser les techniquesde protection donc le bot se muni.

Le botnet peut être éliminé en attaquant à sa topologie du réseau. Par exemple,nous pouvons attaquer un botnet en isolant son maître et en bloquant tous sesordres.

Chapitre 3

Botnet Waledac

Sommaire

3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.1.1 Waledac . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.1.2 Objectif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.2 Caractéritiques techniques . . . . . . . . . . . . . . . . . . . . 10

3.2.1 Vecteurs d'infection . . . . . . . . . . . . . . . . . . . . . . . 10

3.2.2 Code binaire et protection . . . . . . . . . . . . . . . . . . . . 10

3.2.3 Taille du réseau Waledac . . . . . . . . . . . . . . . . . . . . 11

3.2.4 Protocole de communication . . . . . . . . . . . . . . . . . . 11

3.3 Structure du réseau . . . . . . . . . . . . . . . . . . . . . . . . 12

3.3.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.3.2 Communications et messages échangés . . . . . . . . . . . . . 13

3.4 Primitives cryptographiques . . . . . . . . . . . . . . . . . . . 15

3.4.1 Chi�rement symétrique AES . . . . . . . . . . . . . . . . . . 15

3.4.2 Utilisation du chi�rement asymétrique RSA . . . . . . . . . . 16

3.5 Attaques contre Waledac . . . . . . . . . . . . . . . . . . . . . 16

3.5.1 Attaque de l'homme du milieu . . . . . . . . . . . . . . . . . 17

3.5.2 Attaque Sybil . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.6 Méthodes génériques d'attaque . . . . . . . . . . . . . . . . . 19

3.6.1 Analyses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.6.2 Problématique et objectif . . . . . . . . . . . . . . . . . . . . 19

3.6.3 Outline de l'approche proposée . . . . . . . . . . . . . . . . . 20

3.1 Introduction

Dans ce chapitre, nous présenterons tout d'abord les caractéristiques techniquesdu botnet Waledac, puis nous parlerons de sa structure et de son protocole de com-muncication. Ensuite, nous nous concentrerons sur ses algorithmes cryptographiquesqui sont utilisés pour sécuriser ses messages. Nous décrirons aussi les attaques exis-tantes contre ce botnet. Finalement, nous présenterons des remarques sur ces at-taques et proposons en bref le survol d'une méthode générique d'attaque.

Les analyses présentées ici se basent principalement sur des travaux de J. Calvetet P. M. Bureau[Calvet 2009a, Calvet 2009b]. Ils ont découvert les caractéristiquestechniques de Waledac grâce à l'ingénierie inversée sur son code binaire.

10 Chapitre 3. Botnet Waledac

3.1.1 Waledac

Waledac a fait son apparition sur l'Internet vers la �n de l'année 2008. Ce mal-ware a d'abord attiré l'attention des chercheurs par sa ressemblance avec la célèbrefamille Storm[Sarat 2008], qui venait alors de s'éteindre. Au delà de ce probablelien de �liation, Waledac est particulièrement intéressant en lui même, ne serait-ceque parce que les machines du botnet qu'il constitue communiquent à l'aide d'unprotocole cryptographique pair-à-pair, ou bien encore parce que ses techniques deprotection logicielles s'avèrent particulièrement e�caces contre les antivirus.

3.1.2 Objectif

Le but principal de Waledac est d'envoyer des courriels indésirables (spams), quecela soit pour ses propres sites a�n d'infecter de nouvelles machines, ou pour d'autresgroupes de spam comme Canadian Health&Care Mall[Trackers 2010]. Quelques moisaprès la première version, une évolution apportée au binaire a créé un nouveau threadchargé d'explorer le disque dur de la machine infectée à la recherche d'adresses decourrier éléctronique. Le bot est aussi capable de �ltre le tra�c du réseau pourrechercher les mots de passe FTP, SMTP et HTTP. En plus d'être installé pard'autres familles de malwares, Waledac inclut une fonctionnalité qui lui permet detélécharger et d'éxécuter des autres malwares.

3.2 Caractéritiques techniques

Dans cette section, nous nous concentrerons plutôt sur les caractéristiques tech-niques qui sont concernées aux activités locales de bots.

3.2.1 Vecteurs d'infection

Les premières versions de Waledac ne utilisaient que l'ingénierie sociale1 pourse propager : ils envoient des spams pour convaincre un utilisateur de téléchargerun binaire, puis l'éxecuter. Les versions suivantes se propageaient grâce à l'instal-lation des ses binaires par d'autres malwares, l'exemple le plus médiatisé est celuide Con�cker[Keizer 2009]. D'après J. Calvet et P. M. Bureau, de Mai à Juillet 2009les machines du botnet Waledac infectées lors des campagnes d'ingénierie sociale nereprésentaient que 2%, toutes les autres installations ont été e�ectuées par d'autresfamilles de malwares.

3.2.2 Code binaire et protection

Le c÷ur du code de Waledac a été développé suivant le paradigme de la pro-grammation orientée objet avec la langage C++. Cela ajoute quelques di�cultés àson étude car il faut comprendre les liens entre les classes sans avoir le code source.Néanmoins, il existe des moyens de reconstruire l'architecture du programme en

1Social engineering

3.2. Caractéritiques techniques 11

s'aidant de mécanismes liés au compilateur utilisé par les créateurs de Waledac,TMMicrosoft Visual C++[Skochinsky 2006].

Avant de lancer une nouvelle vague de propagation, la couche de protection desbinaires Waledac est préparée et modi�ée a�n d'éviter la détection par les outilsde sécurité. Pendant le premier mois de propagation, les binaires Waledac étaientcompressés avec UPX[UPX 2010], un packer libre disponible sur Internet qui nepossède aucune capacités de protection2. En Janvier 2009, la première famille deprotection a apparu : résolument orientée contre les logiciels antivirus, ses premièresversions utilisaient des techniques anti-émulations. Les versions plus récentes sontremarquables par l'arrivée de protection anti-débuggages.

3.2.3 Taille du réseau Waledac

Le nombre de systèmes infectés par Waledac a beaucoup varié au cours de l'évo-lution du botnet. Il est di�cile d'avoir un résultat précis du nombre de machinesinfectées parce que les spammeurs (cf. section 3.3.1) ne sont pas accessibles3. D'aprèsles mesures données par J. Calvet et P. M. Bureau, il y avait au moins 40.000 sys-tèmes qui participent au botnet jusqu'à juillet 2009.

D'ailleurs, a�n d'évaluer la taille du botnet, B. Stock et al[Stock 2009] ont im-plementé les faux répéteurs4, le Walowdac, qui imitent les opérations de répéteurréel.

Fig. 3.1: Opération de faux répéteur. Crédit photo[Stock 2009]

Selon les informations recueillies le 06 Août et le 01 Septembre en 2009, ilsévaluaient le nombre de machines infectées est de 164.182, et il y avait environ55.000 bots activés par jour.

3.2.4 Protocole de communication

Le botnet utilise le protocole de communication de base HTTP[Fielding 1999]pour échanger des messages entre ses participants. A�n de protéger les mes-

2UPX est d'ailleurs toujours utilisé pour compresser le code binaire Waledac3Les spammeurs sont les machines ayant des adresses IP privées, ils ne connectent que aux

répéteurs. De plus, nous ne pouvons pas contrôler tous les répéteurs du botnet.4J. Calvet et P. M. Bureau utilisaient aussi cette technique, cependant leurs faux répéteurs ont

pour but de capturer les informations du botnet.


Fig. 3.2: Distribution de machines infectées pendant la journée 24 Août 2009. Créditphoto[Stock 2009]

sages circulant sur le réseau, Waledac utilise deux algorithmes cryptographiques :AES[NIST 2001] et RSA[Rivest 1978]. Pour cela, la bibilothèque cryptographiqueOpenSSL[OpenSSL 2010] est intégrée au code binaire du bot.

3.3 Structure du réseau

Dans cette section, nous nous concentrerons sur les activités de la couche deréseau du botnet, c'est-à-dire la topologie du réseau et les protocoles de communi-cation entre ses participants. Nous ne décrirons cependant que les communicationsde base, les analyses en détail (types des messages échangés, structure des messages,mécanisme de mise à jour la liste de répéteurs, etc) peuvent être consultées dans[Calvet 2009a, p.7-16].

3.3.1 Architecture

Du point de vue de l'organisation, l'architecture de Waledac est traditionnelle.Cette architecture se compose d'un serveur de commande et de contrôle, et de plu-sieurs machines esclaves. Les auteurs de Waledac ajoutaient cependant des couchessupplémentaires visant à protéger les serveurs maîtres. Le botnet se muni donc d'unearchitecture hiérarchique qui comprend (au moins) 4 couches.

Spammeurs : les spammeurs sont les bots qui réalisent le travail de basecomme envoyer des spams ou exécuter les attaques DDOS. Ce sont des machinesTMWindows ayant seulement des adresses IP privées. Ils ne se connaissent pas entreeux mais chacun d'eux possède une liste de répéteurs5 avec lesquels il prend contactpour chercher des tâches à accomplir.

Répéteurs : les répéteurs servent de relais pour les commandes de contrôle dubotnet. Ils sont aussi des serveurs de nom qui résolvent des requêtes DNS envoyées

5RList

3.3. Structure du réseau 13

Fig. 3.3: Topologie du réseau de Waledac. Crédit photo[Tenebro 2009]

par les spammeurs. Chaque répéteur a une adresse IP publique directement sur unede ses intefaces et modi�e le pare-feu TMWindows pour être joignable de l'extérieur.Les répéteurs relayent les requêtes des spammeurs vers le serveur de contrôle enpassant par les protecteurs.

Protecteurs : les protecteurs sont des serveurs TMLinux qui exécutent di�érentesversions de nginx[Sysoev 2010], un serveur HTTP léger utilisé comme un manda-taire6. Il y avait 5 ou 6 protecteurs disséminés partout dans le monde (2 ou 3 enAllemagne, 1 aux États-Unis, 1 en Russie, et 1 aux Pays-Bas).

Serveur de contrôle : l'existence du serveur de contrôle est en fait une hypothèse.Les chercheurs trouvaient que les valeurs du champ HTTP Date des réponses desprotecteurs sont identiques quand ils les interrogent au même moment. Comme ilsemble peu probable que les auteurs de Waledac aient synchronisé les 6 protecteurs,ils sont plutôt les mandataires pour une autre couche constituée d'un serveur decontrôle. C'est le serveur qui contient toutes les informations sur le botnet et sonfonctionnement.

3.3.2 Communications et messages échangés

Le protocole pair-à-pair utilisé par les bots repose sur le protocole HTTP. Lastructure des messages HTTP est la suivante :

POST /jyl.png HTTP/1.1

Referer: Mozilla

Accept: */*

Content-Type: application/x-www-form-urlencoded

User-Agent: Mozilla

nHost: A.B.C.D

Content-Length: Y

6Proxy server


Cache-Control: no-cache

a=BwAAC3Jrvsqwur_.....jBJlP7cpNrERG-c7uHr-&b=AAAAAA

Il s'agit donc d'une requête POST sur une image au nom aléatoire dont leschamps sont remplis de façon classique. Le bloc de données de la requête est constituéde deux parties, derrière le paramètre "a"7 se trouve le message en langage XMLqui est compressé avec l'algorithme de compression bz2[Seward 2008], puis chi�répar l'algorithm de chi�rement symétrique AES-128 et �nalement encodé en codagebase64.

Les participants8 du botnet s'échangent entre eux plusieurs types de messages.Ces messages se distinguent par la structure du message XML en forme claire (aprèsêtre déchi�ré) situé dans le message HTTP. Les structures des messages sont décritesen détail dans [Calvet 2009a, p.9-15].

Nous pouvons diviser ces messages en deux catégories : l'une se compose de mes-sages ayant pour but de réaliser les commandes particulières du serveur de contrôleou d'échanger les clés de sessions (getkey, �rst, notify, etc), l'autre vise à mainte-nir la structure du botnet (mise à jour de la liste des répéteurs9 ou de la liste desprotecteurs10).

Les messages de la première catégorie sont échangés de façon indirecte entre lesspammeurs et le serveur de contrôle. En fait, ces messages sont relayés grâce auxrépéteurs et aux protecteurs (cf. �gure 3.4), c'est-à-dire les répéteurs et les protec-teurs ne réalisent aucune activité sur le contenu de XML chi�ré du message HTTP,ils ne ajoutant que des champs HTTP aux messages réçus et puis les transmettent.

Spammeur oo messages // Repeateur oo messages // Protecteur oo messages // Serveur

++

messages

ss WXXYZZ[[\]]^^_``aabccddeffg

Fig. 3.4: Messages échangés entre les spammeurs et le serveur de contrôle

Le spammeur ne contacte pas directement le serveur de contrôle. Il transmetson message à un répéteur qui va relayer (grâce à un protecteur) ce message auserveur de contrôle. Le répéteur mandataire est choisi aléatoirement dans une listede répéteurs, RList , stockée par le spammeur. L'idée principale de la procédure peutêtre représentée par la �gure 3.5.

Le spammeur transmet une partie de sa RList contenant les informations sur100 répéteurs à un répéteur aléatoire. Ceux-ci sont aussi choisis aléatoirement danscette liste. En réponse, le spammeur reçoit aussi du répéteur un extrait de sa proprelist.

7Il y a de nombreux types de paramètres, e.x "b" indique l'adresse IP de l'émetteur8spammeur, repeateurs, protecteurs, et serveur de contrôle9RList10PList

3.4. Primitives cryptographiques 15

Spammeur

requeteRList //Repeteur{RList}K2oo

Fig. 3.5: Méthode de mise à jour de RList

3.4 Primitives cryptographiques

A�n d'assurer la sécurité des messages échangés, les auteurs du botnet ont créépar leur-mêmes un protocole cryptographique de "textbook"11[Mao 2003, p.13] danslequel le chi�rement des messages se fait par un système à clé secrète. Cette clésecrète est échangée de façon sécurisée (selon l'idée des auteurs du botnet) par unprotocole d'échange de clés qui utilise un chi�rement à clé publique.

Les deux algorithmes cryptographiques sont utilisés par Waledac sont tous forts,l'algorithme de chi�rement symétrique12 AES[NIST 2001] vise à chi�rer tous lesmessages échangés entre les participants du botnet, l'algorithme de chi�rement asy-métrique13 RSA[Rivest 1978] est utilisé dans le mécanisme d'échange de clés desession[Menezes 1997, p.494] entre les bots et le serveur de contrôle.

3.4.1 Chi�rement symétrique AES

Le système de chi�rement symétrique (cf. section 4.2.1) AES (Advanced En-cryption Standard) repose sur le système Rijndael[Daemen 1999], élaboré par J.Daement et V. Rijmen en réponse à un appel d'o�re du NIST14 lancé en 1997 pourremplacer le chi�rement DES (Data Encryption Standard)[NIST 1999].

Cet alogrithme est utilisé pour chi�rer tous les messages échangés pendant l'opé-ration du botnet. Waledac utilise trois clés AES : K1, K2 et K3, de taille 128 bits.Cette taille est su�sante pour protéger des données dont le niveau de sécurité estSECRET [NIST 2007, p.67].

La clé K1 est codée en dur dans le code binaire des tous les bots. Cette cléest utilisée pour chi�re le message getkey qui est le premier message envoyé parspammeur quand il commence un dialogue avec le serveur de contrôle. Ce messagese trouve dans la procédure d'échange de clés de session (cf. �gure 3.6).

La clé K2 est codée aussi en dur dans le code binaire des bots. Dans la procédurede mise à jour de RList, les bots utilisent cette clé pour chi�rer sa partie de RList(cf. �gure 3.5).

La clé K3 est une clé de session15 pour sécuriser la communication entre lesspammeurs et le serveur de contrôle. Pour chaque spammeur, après l'étape d'échangede la clé de session (cf. �gure 3.6), tous les messages circulants entre lui et le serveurde contrôle sont chi�rés par cette clé.

11Ceci signi�e un protocole qui n'est pas encore sérieusement véri�é12Chi�rement à clé secrète13Chi�rement à clé publique14National Institute of Standards and Technology.15C'est-à-dire qu'elle n'est que valide en une session de communication


3.4.2 Utilisation du chi�rement asymétrique RSA

Le système de chi�rement asymétrique RSA, baptisé d'après le nom de ses in-venteurs, R. Rivest, A. Shamir et L. Adleman, est le premier algorithme de crypto-graphie à clé publique. L'algorithme RSA, apparu en 1972, est encore l'algorithmeasymétrique le plus utilisé[Schneier 2001, p.491].

Pour s'échanger secrètement des données, la session de communication entreles bots et le serveur de contrôle débute par une phase de négociation dans la-quelle la clé de session K3 est partagée. Les motivations de la clé de session sontvariées[Menezes 1997, p.494], et la méthode le plus utilisée est d'utiliser un systèmeà clé publique pour chi�rer la clé secrète d'un système à clé secrète[Barthélemy 2005,p.42]. Les créateurs de Waledac ont utilisé le système de chi�rement asymétriqueRSA pour réaliser leur protocole d'échange de clé de session16 décrit ci-dessous :

Spammeur

{pkspammeur}K1 //Serveur{K3}pkspammeuroo

Fig. 3.6: Méthode d'échange de clé de session

Le spammeur génére une paire de clés, constituée d'une clé privée skspammeur etd'une clé publique pkspammeur. Il divulgue sa clé publique en le chi�rant par la cléK1 et envoye le message chi�ré, {pkspammeur}K1 , au serveur de contrôle. Le serveurdéchi�re ce message, grâce à la cléK1, pour obtenir la clé publique pkspammeur. Puis,le serveur de contrôle génére aléatoirement une clé de session K3, la chi�re avec laclé publique pkspammeur du spammeur. Finalement, il renvoie cette clé de sessionchi�rée, {K3}pkspammeur , au spammeur. Personne, à l'exception du spammeur, neconnait la clé secrète skspammeur. Ainsi personne, à l'exeception du spammeur, nepeut obtenir la clé de session K3 en déchi�rant le message envoyé.

3.5 Attaques contre Waledac

Le mécanisme de communication entre les participants du botnet, celui de miseà jour le RList des bots, et surtout ses vulnérabilités cryptographiques conduisent àdeux méthodes d'attaque. La première méthode se base sur le fait que les bots et leserveur de contrôle se contactent en utilisant toujours des serveurs de mandataire17.La deuxième méthode exploite le mécanisme de mise à jour le RList pour propagerles informations d'un faux répéteur.

Il existe une vulnérabilité très sérieuse située dans le générateur de clés de sessionK3 du serveur de contrôle, la clé générée a toujours la même valeur. De plus, les

16Le protocole d'échange de clé ne se passe qu'entre deux participants, il n'a pas besoin d'une

autorité de con�ance qui distribue les clés[Stinson 2006, p.394]17Les répéteurs et les protecteurs

3.5. Attaques contre Waledac 17

deux clés K1 et K2 sont codées en dur dans le code binaire des bots, elles sont doncidenti�ables par la rétro-ingénierie. Ce qui permet de déchi�rer très facilement tousles messages échangés dans le botnet.

3.5.1 Attaque de l'homme du milieu

Si le protocole de communcication entre deux parties n'a aucun moyen de véri�erqu'ils parlent bien l'un à l'autre, un attaquant peut intercepter les messages entreeux pour que personne ne puisse détecter le changement des messages envoyés. L'at-taquant, s'appelle homme du milieu, va lire et modifer les informations circulantesentre deux parties pour casser la con�dentialité du protocole. Cette type d'attaques'appelle attaque de l'homme du milieur18.

Dans le cas de Waledac, tous les messages envoyés par des participants ne sontpas signés19. De plus, les spammeurs utilisent toujours des répéteurs pour relayerleurs messages au serveur de contrôle. L'attaque de l'homme du milieu devient donctrès pratique si nous pouvons contrôler le répéteur.

J. Calvet et P. M. Bureau ont créé un faux-répéteur qui n'est rien d'autre qu'unserveur mandataire HTTP réalisant deux opérations de base d'un répéteur :

� Envoyer et recevoir les messages de mises à jour : le mécanisme de mise àjour le RList est imité en mettant les informations de faux-répéteur dans lesmessages envoyés pour qu'elles puissent être connues sur le réseau.

� Relayer de tra�c de contrôle : le tra�c de contrôle entre les spammeurs et lesprotecteurs est relayé de même façon qu'un répéteur réel.

En déchi�rant des messages relayés par le faux-répéteur, ils pouvaient à la foisdétecter des activités de Waledac et intevenir dans ces activités : les ordres du serveurde contrôle ou l'URL20 de distribution des nouveaux bots peuvent être découvertset changés, etc.

Les clés de chi�rement et la structure des messages sont alors connues. Nouspouvons injecter nos propres messages de commande et contrôle. Les faux messagesnous permettent d'avoir diverses exploitations :

1. Nous pouvons faire télécharger aux bots un code exécutable qui désinfecteWaledac en utilisant la commande downloadexe21.

2. Une attaque par déni de service contre les protecteurs peut être lancée par lebiais du tag <dos>22.

3. Les templates de spam distribués peuvent être remaniés pour les rendre innof-fensifs23.

18man-in-the-middle attack19Par un mécanisme de la signature numérique20Les nouveaux versions binaires des bots sont distribuées en donnent une URL vers un répertoire

particulier21La valeur downloadexe est située dans le champ commands de la réponse du message notify22La demande d'attaque par déni de service est située dans le tag <dos> de la réponse du

message notify23Le template de spam est situé dans la réponse du message taskreq


4. Les rapports de spam envoyés par les bots peuvent être modi�és en mettanttoutes les adresses du courriel comme injoignables24.

3.5.2 Attaque Sybil

L'attaque Sybil[Douceur 2002] trouve son origine dans le réseau pair-à-pair oùchaque entité se présente par une seule identité. L'attaquant peut gagner la plupartde la ressource du système (ex. dans le système de partage de données pair-à-pair,l'attaquant essaie de gagner des données en partageant peu) en se présentant commeplusieurs identités virtuelles.

Dans le cas de Waledac, il existe une vulnérablité dans le mécanisme d'identi�ca-tion d'un bot : le bot est identi�é par un ID de 16 octets et une adresse IP. L'adresseIP n'a donc pas besoin d'être unique et ceci permet de créer avec une seule adresseun ensemble de bots Waledac.

L'idée principale de cette attaque est de créer un super-répéteur dont l'adresse IPest très répandue dans le réseau sous di�érents ID. Le super-répéteur va être choisitrès souvent par les spammeurs comme le serveur mandataire pour faire transmettreleurs requêtes. De plus, toutes les clés de chi�rement sont connues, le super-répéteurpeut lire donc tous les messages et les modi�er.

Pour propager les informations du super-répéteur, J. Calvet et P. M. Bureau ontexploité le mécanisme de mise à jour de RList (cf. �gure 3.5). Les bots s'échangentrégulièrement des messages qui contiennent un extrait de 100 répéteurs de leurRList. Cependant, chaque bot ne véri�e pas si les messages de mise à jour qu'il reçoitcontiennent exactement 100 entrées, il est donc possible d'envoyer un message avec500 entrées (dont les timestamps sont bien choisis) pour remplir toute la RList dureceveur25 par les entrées de ce message. Par exemple, les messages envoyés sont dela forme :

<lm>

<localtime>0</localtime>

<nodes>

<node ip="ourIPaddress" port="80"time="0">

00000000000000000000000000000001</node>

<node ip="ourIPaddress" port="80" time="0">

00000000000000000000000000000002</node>

...

<node ip="ourIPaddress" port="80" time="0">

00000000000000000000000000000500</node>

</nodes>

</lm>

Lorsque le bot reçoit un tel message, toutes les entrées de sa RList seront rem-placées grâce à la di�érence zéro entre le timestamp global et les locaux, qui indique

24Le rapport de spam est situé dans le message taskrep25Pour chaque bot, sa taille maximale de la RList est 500[Calvet 2009a, p.16].

3.6. Méthodes génériques d'attaque 19

que le nouveau timestamp est le plus récent possible.

3.6 Méthodes génériques d'attaque

L'étude de cas présentée ci-dessus a illustré certains attaques contre le botnetWaledac, cependant les attaques présentées ne sont pas les seules solutions pos-sibles. Pour les types di�érents de botnet[Bacher 2005, Di�erent Types of Bots], denombreuses autres méthodes sont envisageables. Tous les méthodes d'attaque (etd'protection) se basant sur un bouclier de multi-couches. Elles se divisent en deuxcatégories : l'une vise à éliminer des activités malveillantes sur les machines infectées(ex. les logiciel antivirus), l'autre essaie d'analyser, de tracer et d'arrêter les activitésde botnet sur la couche de réseau (ex. [TechNet 2010] ou [Honeynet 2010]).

Les travaux réalisés dans ce stage se concentreront sur l'étude des méthodes quinous permettent de bloquer les botnets au niveau de topologie de réseau. Plus préci-sément, ces méthodes visent à exploiter des vulnérabilités, surtout des vulnérabilitéscryptographiques situées dans le protocole de communications entre les participantsdu botnet. Nous ignorons des attaques visant à exploiter des vulnérabilités "locales",qui concernent plutôt aux activités sur la machine infectée.

3.6.1 Analyses

Les deux méthodes d'attaque présentées dans la section 3.5 se basent sur un fait :nous pouvons toujours déchi�rer, falsi�er et changer tous les messages échangés.

En e�et, l'attaque de l'homme du milieu utilise un faux-répéteur qui imite descomportements du répéteur réel26. En déchi�rant des messages relayés, nous pou-vons obtenir des informations du botnet. De façon analogue, l'attaque Sybil change(ou falsi�e) les messages de mise à jour de RList pour propager l'identité du super-répéteur.

Nous notons que tous les messages échangés entre les parties du botnet sontdéchi�rés par l'alogrithme de chi�rement AES (avec un des trois clés de 128 bitK1, K2 ou K3). Les deux clés K1 et K2 sont codées en dur dans le code binaire dubot, la clé de session K3 est échangée par le protocole d'échange de clés (cf. �gure3.6). Plus généralement, nous disons que les parties de Waledac se communiquenten utilisant un protocole cryptographique.

3.6.2 Problématique et objectif

L'étude de cas du botnet Waledac nous montre deux méthodes d'attaque quise basent sur les vulnérabilités du protocole de communication. Dans le partie ci-dessus, nous reconnaissons que ces méthodes d'attaque ne sont possibles que si leprotocole de communication est vulnérable. Dans le cas général, nous cherchons desattaques contre le protocole de communication d'un système quelconque.

26Le faux-répéteur relaie des messages des spammeurs au serveur de contrôle


Actuellement, les créateurs de codes malveillants ont tendance à utiliser les pri-mitives cryptographiques pour protéger leurs produits[Stamford 2002], [Vogt 2007] :les logiciels malveillants27, les botnets, etc. La première idée, le cryptovirologie,a été proposée par A. Young et M. Yung[Young 1996]. Ces auteurs proposentmême un exemple pratique utilisant le cryptocounter [Young 2004, p.130]. Un ré-sultat récent d'E. Filiol[Filiol 2004] a proposé un virus informatique expérimental,le virus Bradley, dont la complexité d'analyse est NP-complet28. Dans un articlerécent[Desnos 2009], A. Desnos a mise cette idée en pratique en propsant une im-plémentation de virus Bradley en Python.

Les botnets utilisent aussi les algorithms de chi�rement pour sécuriser leurscommunications, le botnet Rustock[Chiang 2007] chi�re ses messages par l'al-gorithme de chi�rement à �ot RC4[Rivest 1992]. Le ver informatique Stormutilise l'algorithme de chi�rement asymétrique RSA pour sécuriser certainescommunications[Holz 2008]. Les trois auteurs R. Hund, M. Hamann, et T. Holzont proposé même un botnet avancé, le Rambot, qui est doté des primitives cryp-tographiques fortes[Hund 2008].

Les primitives cryptographiques, surtout les algorithmes de chi�rement asymé-trique, fournissent aux auteurs de codes malveillants un outil très fort. Dans le casdu botnet, grâce aux algorithmes de chi�rement, les auteurs peuvent cacher tousles messages circulant en utilisant un tel protocol cryptographique. Ainsi, pour em-pêcher ces nouvelles menaces de sécurité, la question fondamentale est de casser leprotocole cryptographique utilisé par botnet. Une attaque avec succès au protocoleva nous o�rir des possibilités pour réaliser des attaques successives, comme attaqueSybil ou attaque de l'homme du milieu29. En conséquence, nos travaux dans ce stagese concentreront sur les attaques génériques contre les protocoles cryptographiques.

3.6.3 Outline de l'approche proposée

Le problème est de chercher automatiquement des attaques contre un protocolecryptographique quelconque (qui est utilisé par un botnet). La première étape dela recherche est de véri�er si ce protocole est vulnérable ou non. Ensuite, nousessaierons d'étudier comment exploiter les vulnérablitiés trouvées, c'est-à-dire quenous construirons l'attaque contre ce protocole. Nous décrivons donc la premièreapproche dans la �gure 3.7.

A première vue, il est possible de juger que l'étape de véri�cation peutêtre réalisée "à la main" en appliquant, par exemple, le processus "corriger,attaquer"[Mao 2003, p.23]. En fait, nous pouvons aussi reconnaitre que la méthode"à la main" n'est su�sant que pour quelques protocoles simples. Dans le cas gé-néral, ce processus peut mettre beaucoup de temps pour trouver une vulnérabilitéd'un protocole. Par exemple, le protocole de Needham-Schroeder[Needham 1978] est

27Malwares28Nous avons besoin toujours d'un temps d'exécution exponentiel pour résoudre des problèmes

NP-complets jusqu'à présent [Garey 1979]29C'est l'attaque de l'homme du milieu présentée dans 3.5.1


protocole cryp-tographique

véri�er ceprotocole

protocole estvulnérable ?

construirel'attaque

s'arrêter

yes

no

Fig. 3.7: Modèle simple d'attaque

proposé en 1978, mais sa vulnérabilité n'a été prouvée qu'en 1981[Denning 1981]. Ilva sans dire qu'un retard de trois ans n'est pas acceptable pour la protection contreune attaque botnet.

Nous avons donc besoin d'une méthode qui permet de véri�er automatiquementdes protocoles cryptographiques et, dans le cas où ces protocoles sont vulnérables,de reconstruire des attaques.

Il s'agit maintenant d'un problème de véri�cation des protocoles cryptogra-phiques et de reconstruction des attaques. Heureusement, notre problème se si-tue dans un contexte connu de la véri�cation automatique des protocoles crypto-graphiques. Les méthodes formelles nous fournissent une preuve mathématique dela sécurité d'un protocole. Jusqu'à présent, il existe de nombreuses approches duproblème de véri�cation des protocoles cryptographiques, un bref survey peut êtreconsulté dans [Comon 2002]. Pour que les outils mathématiques soient applicables,une méthode formelle de véri�cation a besoin essentiellement d'un modèle formeldu protocole à véri�er. Ce modèle formel fournit des techniques servant à modéliserle protocole.

Nous avons maintenant des idées principales d'une méthode générique d'attaque.Nous proposons dans la �gure 3.8 un survol de l'approche utilisée, l'attaque géné-rique contre le protocole de communication du botnet se compose donc les étapessuivantes :

1. Découvrir le protocole de communication en analysant (écoutant, bloquant ou


envoyant des faux messages sur le réseau, etc) les activités du botnet.

2. Créer le modèle formel en modélisant ce protocole.

3. Chercher des vulnérablitiés en véri�ant ce modèle.

4. Si la vulnérabilité est détectée, reconstruire l'attaque.

modéliserce protocole


véri�er cetmodèle

modèle estvulnérable ?

construirel'attaque

s'arrêter

yes

no

Fig. 3.8: Survol de l'approche proposée

La première étape a pour but de découvrir le protocole de communication. Ellecomprend donc des méthodes qui visent à analyser le code binaire du bot (ex. rétro-ingénierie informatique), à lire ou à intercepter des données circulantes sur le réseau(ex. en utilisant le reni�eur de paquets30), etc. Il est bien entendu que la plupartde codes malveillants essaient de se protéger à l'aide de plusieurs méthodes31. Parexemple, pour empêcher l'analyse par les chercheurs, les codes binaires de Waledac32

sont compressés avec UPX et se munissent de techniques anti-émulations.En fait, il faut accepter que la première étape soit extrêmement di�cile à dé-

passer dans certains cas. Si les algorithmes du bot sont bien dressés et son code estimplémenté correctement, il est très di�cile de découvrir les protocoles de commu-nication sous-jacents. L'exemple typique est Skype[Skype 2010], un logiciel proprié-taire de messagerie instantanée, délivré la première fois en 2003. Il se muni volon-tairement de techniques de protection tellement compliquées que les chercheurs ne

30Packet sni�er31Ces méthodes se situent dans la contexte de la sécurité par l'obscurité[Fortier 2005]32Remarquons que les deux clés AES − 128 : K1 et K2 sont codées en dur dans le code binaire

de bot


peuvent pas savoir exactement ses protocoles de communication jusqu'à présent33,une liste des articles analysant les méthodes utilisées par Skype peut être consultéedans [Salman 2010].

Les botnets les plus populaires ne disposent pas d'une telle protection. En fait,il n'existe pas encore de botnet qui peut rendre impossible l'analyse par rétro-ingénierie. La raison est peut-être que le but premier des auteurs du botnet et legain rapide, ils n'ont aucune raison de chercher à créer un botnet parfait qui prendplus de temps à se développer et se déployer et donc à être rentabilisé[Calvet 2009a,p.19].

Nous acceptons donc que les protocoles de communication des botnets soient tou-jours facilement détectables34. Ainsi nos travaux se concentrerons sur la résolutiondes problèmes posés dans les étapes 2, 3 et 4. Dans les chapitres suivants, noustravaillerons sur des modèles formels servant à modéliser les protocoles de commu-nication.

33Récemment, une équipe des hackers proclame son succès pour le déchi�rement des données

envoyés par Skype[O'Neil 2010]34Ce n'est pas une supposition irrationnelle, e.x les bots de Waledac se communiquent en utilisant

le protocole HTTP, les en-têtes du protocole ne sont jamais chi�rés et sont facilement à détecter

Chapitre 4

Véri�cation des protocoles etméthodes formelles

Sommaire

4.1 Motivations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

4.1.1 Méthodes formelles pour la véri�cation de programmes . . . . 26

4.1.2 Protocole cryptographique, attaque et véri�cation . . . . . . 27

4.1.3 Propriétés de sécurité . . . . . . . . . . . . . . . . . . . . . . 29

4.2 Protocole cryptographique . . . . . . . . . . . . . . . . . . . . 29

4.2.1 Primitives cryptographiques . . . . . . . . . . . . . . . . . . . 29

4.2.2 Exemple : protocole "Wide-Mouthed-Frog" . . . . . . . . . . 30

4.3 Modèles formels . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.3.1 Algèbre de processus . . . . . . . . . . . . . . . . . . . . . . . 32

4.3.2 Pi-calcul et spi-calcul . . . . . . . . . . . . . . . . . . . . . . 35

4.3.3 Modèle de traces et clauses de Horn . . . . . . . . . . . . . . 40

4.4 Modèles formels des attaques . . . . . . . . . . . . . . . . . . 44

4.4.1 Attaques en spi− calcul . . . . . . . . . . . . . . . . . . . . . 44

4.4.2 Attaques en clauses de Horn . . . . . . . . . . . . . . . . . . 45

4.1 Motivations

Revenons à la question de méthode générique pour attaquer le protocole decommunication des botnets. Dès que nous trouvons le protocole de communication,l'étape suivante, la deuxième étape dans la �gure 3.8, sera de modéliser formellementce protocol pour que, dans le troisième étape, nous puissions detecter des vulnéra-bilités du modèle en utilisant des outils mathématiques. Ce chapitre est consacrédonc aux méthodes formelles visant à la véri�cation des protocoles sécurisés.

La véri�cation des protocoles sécurisés trouve son contexte dans la réalisationdes systèmes informatiques �ables. Nous voulons parler de cas des systèmes cri-tiques dans lesquels les erreurs informatiques ne sont pas absolument acceptables.La véri�cation des programmes critiques ont donc besoin de méthodes formelles quipeuvent assurer que aucun comportement du système ne peut entraîner d'erreurs.De façon analogue, les protocoles de communication peuvent être considérés commeun type particulier des programmes. Ce type de programme se forme de plusieurs

26 Chapitre 4. Véri�cation des protocoles et méthodes formelles

processus, ceux dépendent de nombre de parties qui participent au protocole, qui secommuniquent en échangant des messages.

4.1.1 Méthodes formelles pour la véri�cation de programmes

Dans les systèmes informatiques, nous pouvons toujours constater des dysfonc-tionnements : l'écran bleu de la mort1 dans les ordinateurs qui se chargent le systèmed'exploitation TMMicrosoft Windows, la panique du noyau2 dans les systèmes d'ex-ploitation TMLinux, un a�chage d'une erreur de segmentation3 d'un logiciel malfonctionné, ou plus simplement un logiciel de traitement de texte se �ge en pleintravail, etc.

Dans certains cas, les dysfonctionnements ne nous causent que des désagréments :l'écran bleu de la mort dans l'ordinateur de bureau nous demande à le faire redé-marrer, nous pouvons forcer à quitter le logiciel le logiciel de traitement de texte etcontinuer à taper le document en le rouvrant, etc.

Cependant, les bugs informatiques ne sont plus acceptables pour les applicationscritiques. Nous voulons aborder des cas des systèmes critiques dont les bugs peuvententraîner morts, blessures, ou du moins des coûts élevés. En 1996, la fusée Ariane5, dans son vol inaugural, a explosé 40 secondes après le décollage. Une commissiond'enquête[Lions 1996], fondée par ESA4 et CNES5, a établi que l'accident était dûà la réutilisation d'un logiciel prévu pour la fusée Ariane 4 et donc n'avait jamaisvéri�é qu'il fonctionnait bien sur la nouvelle fusée[Monniaux 2009, p.2]. L'incidenta provoqué la destruction de la fusée ainsi que la charge utile d'une valeur totale de370 millions de dollars, ce qui en fait l'un des bugs informatiques les plus coûteuxde l'histoire[Wikipédia 2010].

Les faiblesses en matière de sûreté informatique proviennent de l'utilisation d'ap-proches, de méthodes, par exemple : la véri�cation de programmes, l'utilisation desmatériels redondants6[Monniaux 2009, p.4], etc. Dans ce cas, nous ne nous concen-trerons que sur la véri�cation du logiciel. Il est bien entendu que les logiciels, crééspar l'être humain, contiennent toujours des erreurs. Pour les systèmes informatiquescritiques dans lesquels l'existance des erreurs est absolument inacceptable, il s'agitdonc d'un problème sérieux de la véri�cation de programmes.

A�n de détecter les erreurs dans les logiciels, il va sans dire que nous pouvonsles tester, c'est l'approche la plus simple. Cependant, elle est limitée par le nombre�ni de comportements potentiels sont explorées. Pour les programmes critiques,

1Blue Screen of Death2Kernel panic3Segmentation fault4European Space Agency5Centre National d'Etudes Spatiales6L'utilisation des matériel redondants : au lieu de mettre un dispositif, on en met plusieurs.

Cependant, cette méthode n'est que su�sante aux pannes matérielles "aléatoires" parce que la

redondance entre dispositifs identiques est inutile s'il s'agit de dysfonctionnements logiciels. Le

premier boîtier signale une erreur suite à un problème de conception de son logiciel, le deuxième

boîtier fonctionnant avec le même logiciel sur les mêmes données va aboutir au même résultats ! ! !,

et donc tomber également en panne[Monniaux 2009, p.4].

4.1. Motivations 27

l'approche retenue à l'heure actuelle est de fait la preuve mathématique a�n d'assurerque le logiciel est juste dans tous les cas. C'est ce qu'on appelle la véri�cation delogiciels grâce aux méthodes formelles[Cortier 2009, p.7].

4.1.2 Protocole cryptographique, attaque et véri�cation

Le protocole de communication7 est une suite structurée de messages échan-gés entre plusieurs participants. Il existe un ensemble de protocoles qui s'ap-pelle procotoles de sécurité, ayant pour objectifs de garantir le secret des don-nées échangées, d'authenti�er un des participants, de garantir l'anoymat ou la non-répudiation[Cortier 2009, p.8].

Les protocoles de sécurité sont crées en supposant que leurs environnementsde travail soient publiques. Autrement dit, les protocoles doivent être capable desécuriser leurs communications voire même le réseau est totalement contrôlé parl'attaquant, qui peut écouter les messages transmis, faire des calculs sur ces mes-sages, et envoyer aux participants du protocole n'importe quel message qu'il a réussià calculer[Blanchet 2008, p.6].

Jusqu'à maintenant, la plupart des protocoles de sécurité en pratique utilise desprimitives cryptographiques (cf. 4.1.3) pour protéger leurs communications8. Ainsi,nous utilisons la phrase protocoles cryptographiques pour parler des protocoles desécurité. Si l'une primitive cryptographique est cassée, il est bien entendu que leprotocole cryptographique, qui se base sur cette primitive, est aussi cassé. Cepen-dant, la robustesse des primitives cryptographiques sous-jacentes ne peut pas assurerla sécurité du protocole. Nous considérons maintenant un protocole :

A

{{k}skA}pkB //

B{m}koo

Fig. 4.1: Version simpli�ée du protocole de Denning-Sacco

Le protocole présenté dans le �gure 4.1 est une version simpli�ée du protocolede distribution de clés de Denning-Sacco[Denning 1981] à clé publique.

Message 1.A→ B : {{k}skA}pkB

Message 2.B → A : {m}k

Le participant A choisit une clé fraîche k à chaque exécution du protocol, signe laclé k avec sa clé secrète skA, et chi�re la signature avec la clé publique du participantB. En�n, A envoie la signature chi�rée à B. Quand le participant B reçoit le messagechi�ré, il le déchi�re en utilisant sa clé secrète skB et obtient la clé k. Ayant véri�é

7Dans ces travaux, les protocoles de communication est consacré aux protocoles informatiques8Nous ignorons des techniques immatures, par exemple les techniques de la cryptographie quan-

tique comme la distribution quantique de clés[Mao 2003, p.203]


la signature9, B est convaincu que la clé k a été choisie par A, et le chi�rementsous la clé publique pkB garantit que seul B peut déchi�re le message, donc la clék doit être partagée entre A et B. Le participant B peut donc envoyer, de manièresécurisée, un messages s au participant A en le chi�rant avec la clé k et seul A estcapable d'obtenir ce message en déchi�rant le message chi�ré[Blanchet 2008, p.3].

À première vue, en supposant que les chi�rements utilisés dans le protocole 4.1soient parfaits10, c'est-à-dire qu'il est absolument impossible d'obtenir d'informationsur un message chi�ré à moins de connaître la clé de décryptage[Cortier 2005, p.2].En suivant exactement sur ce que le protocole nous renseigne, étape par étape, nouspouvons naturellement croire que le protocole est absolument sécurisé. En fait, il estassez facile de casser ce protocole en utilisant l'attaque de l'homme du milieu.

A

{{k}skA}pkC //

C(attaquant){m}koo

{{k}skA}pkB //

B{m}koo

Fig. 4.2: Attaque contre le protocole simpli�é de Denning-Sacco

Dans cette attaque, le participant A exécute le protocole avec un participantmalhonnête C, c'est ce qu'on appelle homme du millieu. L'attaquant C récupère lepremier message du protocole {{k}skA

}pkC, le déchi�re avec sa clé secrète skC et le

rechi�re avec la clé publique pkB du participant B. Le message obtenu {{k}skA}pkB

correspond exactement au premier message d'une session entre A et B. L'attaquantC envoie alors ce message à B en se faisant passer pour A. Le participant B seleurre sur l'identié de l'émetteur du message, et répond en envoyent un message m,destiné à A, chi�ré sous la clé k. En possédant la clé k, l'attaquant C est toujourscapable de déchi�re le message m[Blanchet 2008, p.4]. Maintenant, nous voyons ai-sément que la sécurité du protocole n'est pas complètement la sécurité des primitivescryptographiques sous-jacentes.

D'une part, les protocoles cryptographiques doivent être assurés qu'aucuncomportement ne peut pas entraîner de vulnérabilités. D'autre part, la véri�-cation informelle sera facilement à faire d'erreurs dès que le protocole devientcompliqué[DeMillo 1982, p.2], par exemple : le protocole comprend de nombreuxparticipants, le protocole a besoin de plusieurs interactions de communication11,l'existence de l'attaquant et ses activités, etc. Ainsi, nous devons résoudre le mêmeproblème que la véri�cation des programmes critiques, la véri�cation des protocolescryptographiques a besoin également une méthode formelle.

9Nous ne montrons par clairement comment le participant B peut obtenir la clé publique du

participant A. En fait, les clés publiques sont distribuées implicitement par une autorité de certi-

�cation.10C'est celui qu'on appelle l'hypothèse du chi�rement parfait [Cortier 2005, p.3]11Le nombre de messages requis forme le protocole

4.2. Protocole cryptographique 29

4.1.3 Propriétés de sécurité

Les propriétés de sécurité sont des objectifs qu'un protocole de sécurité cherche àassurer. Parmi plusieur propriétés des protocoles cryptographiques12, nous croyonsqu'il y a deux propriétés qui sont les plus utilisées par les botnets : le secret etl'authenti�cation.

Secret : un protocole assure le secret d'une donnée M si, pour tout déroulementvalide, l'attaquant ne peut pas apprendre cette donnée[Cortier 2005, p.7]. Le botneta toujours besoin d'assurer le secret de ses messages participants13. Remarquons icique les capacités de l'attaquant ne sont rien parlées. Ainsi sous certaines conditions,le protocole assure le secret de la donnée M , cependant sous les autres conditions,il ne peut pas l'assurer.

Authenti�cation : le botnet peut se munir d'une capacité qui permet aux parti-cipants de détecter des altérations des messages reçus. Dans ce cas là, nous disonsque le protocole de communication du botnet fournis le service d'authenti�cation dumessage. Il est bien entendu que si le botnet Waledac se munir de l'authenti�cationdu message, tous les attaques présentées dans la section 3.5 ne marchent plus.

4.2 Protocole cryptographique

Un protocole est une convention déterminant les messages échangés entre plu-sieurs participants. Un protocole cryptographique utilise des primitives cryptogra-phiques (chi�rement, signature, ...) a�n de garantir que les données14 sont échangéesde façon sûre15, même si le réseau lui-même n'est pas sûr.

Il su�t de remarquer que nous distinguons la couche logique des protocolescryptographiques qui détermine la suite des messages échangés, et des primitivescryptographiques qui créent ces messages.

4.2.1 Primitives cryptographiques

Les primitives cryptographiques jouent un rôle de briques stables sur lesquellesles protocoles cryptographiques se basent. Une liste assez complète de primitivescryptographiques peut être consultée dans [Menezes 1997, p.5]. Dans ces travaux,nous ne parlons que de quelques primitives qui sont concernées directement à deuxpropriétés de sécurité présentés ci-dessus (authenti�cation et secret) : la cryptogra-phie symétrique et asymétrique, la signature numérique.

La cryptographie symétrique16 réalise sur les données m une transformation c =Ek(m), par l'intermédiaire d'un algorithme de chi�rement E. Cet algorithme prenden entrée le message clairm et un paramètre secret k, s'appelle la clé. La restauration

12Une list plus complète peut être consultée dans [Cortier 2005, p.7-10]13Le botnet Waledac utilise le chi�rement symétrique AES−128 pour protéger ses messages (cf.

section 3.4.1)14Les messages en clair15En fait, le protocole a pour but de garantir des propriétés de sécurité particuliers16Cryptographie à clé secrète


du texte clair à partir de la chi�re se fait par un algorithme de déchi�rement Dk,prenant en entrée la chi�re et la même clé[ENS 2004, p.7]. Le chi�rement et ledéchi�rement ont une rélation :

Dk(Ek(m)) = m

Remarquons aux primitives cryptographiques utilisées par botnet Waledac, lechi�rement symétrique AES− 128 garantit la con�dentialité des messages. Jusqu'àprésent, le décryptement17 de AES avec la taille de clé de 128 bits est extrêmementdi�cile18.

La cryptographie asymétrique19 utilise une paire de clés. La clé publique e, estutilisée pour le chi�rement : c = Ee(m). La clé privée d, est utilisée pour le déchif-frement m = Dd(c). Le chi�rement est le déchi�rement ont donc une rélation :

Dd(Ee(m)) = Ee(Dd(m)) = m

De plus, étant donnée la clé publique e, il est impossible20 de découvrir la clésecrète d. Cependant, il su�t de remarquer que le décryptement du chi�rementasymétrique n'est pas tout à fait la découverte de la clé secrète[Boneh 1999].

Le schéma de cryptographie asymétrique est aussi la base de nombreux primi-tives cryptographiques, l'un d'entre eux est la signature numérique. La signaturenumérique est un mécanisme qui permet de[CGI 2002, p.4-5] :

� Authenti�er un message, en d'autres termes prouver qu'un message provientbien d'un expéditeur donné, à l'instar d'une signature sur un document papier.

� Garantir l'intégrité d'un message, autrement dit véri�er qu'un message n'estpas altéré après il est signé, toute altération du message sera aussitôt détectée.

La procédure de la signature numérique est à l'inverse du chi�rement asymé-trique : la clé de signature est secrète. Seul le possesseur de cette clé peut signer, lasignature numérique d'un message m est calculée par s = Ed(m)21. La clé de véri-�cation des signatures est publique, de sorte que n'importe qui peut véri�er qu'unesignature est correcte m = De(s).

4.2.2 Exemple : protocole "Wide-Mouthed-Frog"

Pour illustrer des protocoles cryptographiques, nous considérons une versionsimpli�ée d'un protocole d'établissement de clés, s'étant appelé "Wide-Mouthed-Frog", proposé la première fois par M. Burrows[Burrows 1990, p.25]. Ce protocolea pour but d'aider deux interlocuteurs A et B à se mettre d'accord sur une clé desession secrète grâce à un serveur d'authenti�cation S. Nous remarquons que cetteversion ne utilise pas l'horodatage, elle est donc vulnérable à l'attaque par rejeu.

17Le décryptement est l'opération qui consiste à calculer le texte clair m à partir du chi�ré

c = Ek(m) sans la connaissance de la clé k[ENS 2004, p.7]18Cette taille est su�sante pour protéger des données dont le niveau de sécurité est SE-

CRET [NIST 2007, p.67]19Cryptographie à clé publique20C'est-à-dire il est très di�cile de calculer la clé secrète à partir des informations connues (clé

publique, etc) en un temps raisonnable21En fait, la signature numérique est créée en signant sur la hachage du message[Krawczyk 1997]

4.3. Modèles formels 31

S{A,kAB}kBS

))SSSSSSSSSSSSSSSSSSSS

A

A,{B,kAB}kAS

55kkkkkkkkkkkkkkkkkkkkB//{M}kAB

oo

Fig. 4.3: Protocole Wide-Mouthed-Frog

L'expéditeur A genère une nouvelle clé de session kAB, elle crée un messagequi se compose de l'identité de la destinataire B et la clé de session. Ce messageest chi�ré par la clé secrète kAS partagée entre A et le serveur d'authenti�cationS : {B, kAB}kAS

. Puis, A envoie au serveur S la composition : A, {B, kAB}kAS. Le

serveur S obtient la clé de session kAB et la destinataire B en déchi�rant le message{B, kAB}kAS

. Ensuite, S envoie à B le message chi�ré par la clé secrète partagéekBS : {A, kAB}kBS

. B chi�re alors le messageM sous la clé partagée kAB, et l'envoieà A.

Message 1. A→ S : A, {B, kAB}kAS

Message 2. S → B : {A, kAB}kBS

Message 3. B ↔ A : {M}kAB

Le protocole "Wide-Mouthed-Frog" utilise la cryptographie symétrique a�n deprotéger des informations échangées sur les réseaux. Il n'exite que deux personnesA et S qui procèdent la clé secrète kAS , grâce à la cryptographie symétrique, lecontenu du message {B, kAB}kAS

est donc protégé contre les autres. La clé secrètekAS n'est partagée que entre le serveur S et la destinataire B, le contenu du message{A, kAB}kBS

ne peut être déchi�ré que par S et B.En utilisant ce protocole, les deux interlocuteurs sont convaincus que la clé de

session kAB est échangée de façon sécurisée entre eux. Ils peuvent alors s'échangentde façon sécurisée des messages en les chi�rant par cette clé.

4.3 Modèles formels

Le modélisation d'un protocole n'est pas simplement une traduction symboliquede la spéci�cation de cet protocole. En e�et, considérons le protocole illustré dansla �gure 4.1, sa spéci�cation peut être traduite en une représentation symboliquedécrite ci-dessous :

A→ B : {{k}skA}pkB

B → A : {m}k

Fig. 4.4: Représentation symbolique du protocole


La représentation 4.4 ne parle que d'un déroulement normal du protocole, il estassez facile d'y s'apercevoir de quelques lacunes :

� il n'y a auccun existence d'attaquant : sa capacité, ses activités, etc.� la représentation ne peut parler rien de propriété de sécurité qu'elle assure(dans ce cas c'est le secret du message m).

� le comportement de chaque participant est ambigu : si le participant B nereçoit pas le premier message, est-ce qu'il envoie le deuxième message ?.

La modélisation doit est donc capable de décrire non seulement les activités duprotocole mais encore l'environnement dans lequel ce protocole se déroule. L'environ-nement du protocole est e�ectivement les activités des attaquants et leurs capacités.De plus, la modélisation doit fournir exactement et formellement des propriétés desécurité que le protocole assure.

De nombreux modèles dédiés à la véri�cation des protocoles crypto-graphiques ont été développés dans littérature, tels ques les systèmes decontraintes[Millen 2001], les règles de réécriture[Cervesato 1999], les clausesde Horn[Blanchet 2001], les strand spaces[Fabrega 1999] ou les algèbres deprocessus[Abadi 2001, Schneider 1998]22. Ces modèles peuvent être divisés en deuxgrandes familles : les modèles de traces et les algèbres de processus[Cortier 2005,p.11].

Les modèles de traces représentent les protocoles et les attaquants par des règlesd'inférence. Les règles décrivent les transitions possibles entre traces. Les tracescontiennent en général l'ensemble des messages circulants sur le réseau et éventuel-lement les états locaux des participants ou des annotations décrivant explicitementles transitions e�ectuées[Cortier 2005, p.11]. Dans ces travaux, nous aborderons unmodèle de traces particulier : les clauses de Horn (cf. section 4.3.3).

Les algèbres de processus représentent le protocole par des processus. Cela cor-respond à une modélisation plus proche de l'implémentation des protocoles : chaqueparticipant est représenté par un processus indépendant des processus représentantles autres rôles[Cortier 2005, p.11]. En particulier, nous utiliserons un modèle del'algèbre de processus : le spi− calcul (cf. section 4.3.2).

Dans ces travaux, nous nous concentrons plutôt sur des méthodes d'algèbre deprocessus parce qu'elles correspondent à une modélisation plus proche de l'implé-mentation des protocoles. C'est-à-dire, il est assez facile de créer une représentationformelle à partir d'une spéci�cation informelle de protocole et d'implémenter un pro-tocole si nous savons sa représentation formelle23. Cependant, nous utiliserons aussiles modèle de traces pace qu'ils permettent de reconstruire facilement des attaques.

4.3.1 Algèbre de processus

Au-delà des programmes séquentiels, qui prennent des données en entrée etfournissent des résultats en sortie, beaucoup de systèmes informatiques sont pa-

22Une discription courte des modèles peut être consultée dans [Cortier 2003, p.19-21]23En fait, la représentation d'un protocole en spi − calcul ressemble à un représentation d'une

fonction en le langage de programmation Caml[INRIA 2010]


rallèles, c'est-à-dire composés de plusieurs processus qui s'exécutent simultané-ment et s'échangent des messages. L'algèbre de processus (ou calcul de proces-sus) est un formalisme mathématique pour la description et l'étude des systèmeconcurrents[Garavel 2003, p.1].

Le processus s'addresse aux comportements d'un système. Nous pouvons ima-giner qu'un système est caractérisé (ou dé�ni) par ses comportements dans les in-teractions avec des autres. Ainsi, le système est quelque chose qui montre des com-portements. Nous considérons ici des exemples :

� Exécution d'un logiciel : quand un logiciel fonctionne, d'une part il commu-nique toujours avec d'autres services du système informatique. D'autre part, ilest caratérisé par ses comportements (ex. pour un �chier MP3, une applicationmultimédia restitue ses sons, un éditeur de �chiers binaires a�che ses octes).

� Activités d'une machine : un distributeur automatique de café nous o�re unetasse de café si le montant d'argent que nous lui donnons est su�sant, sinon ilattend et compte (avec chaque sou) jusqu'à le montant d'argent est su�sant.

Dans les cas ci-dessus, l'exécution du logiciel et celui du distributeur de cafépeuvent être considérées comme des processus. Chacune d'entre elles change soncomportement au long de sa vie.

Le comportement du système se compose généralement de : (1) un ensembledes actions que ce système peut é�ectue, (2) un ordre avec lequel les actions sonté�ectuées. Pour modéliser un système particulier, nous ne mettons que en valeurcertains aspects de son comportement et les autres aspects sont laissés passer,c'est-à-dire on ne considère que une abstraction ou une idéalisation d'un systèmeréel[Baeten 2009, p.1]. Par exemple, dans la spéci�cation du protocole de com-munication sécurisé SSH[Ylonen 2006b], nous négligons tous les détails qui sontconcernés à la couche physique, tels que les signaux électriques, ou sa modulation.Nous nous concentrons plutôt sur les algorithmes de l'étabilissement de clés oud'authenti�cation[Ylonen 2006a].

L'abstraction d'un système est créée par une réalisation des observations sur cesystème (en d'autres termes, sur des comportements du système). Une activité24

est constatée pour chaque observation é�ectuée sur le système. Ainsi, l'abstractiondu système se compose des plusieurs activités discrètes, le processus s'appelle aussisystème à événements discrets25[Baeten 2009, p.1].

Pour illustrer la modélisation par processus, nous décrivons dans la �gure 4.5un exemple d'un distributeur automatique des boissons : l'opération du distributeurdes boissons est modélisée par un diagramme d'états-transitions. L'état start n'estque un état-faux 26, la machine commence en attendant des sous (état 1) jusqu'àl'utilisateur met deux sous (état 2). A cet état, si l'utilisateur appuye sur le buttontea, la machine lui donne une tasse de thé et elle change son état à 1. Si l'utilisateurcontinuer à met deux sous, la machine change son état à 3. A l'état 3, si l'utilistateur

24Une activité est une période de temps pendant lequel l'état du système ne change

pas[Naoufel 2002]25Discrete Event System26pseudo-state


appue sur le button coffe, la machine lui donne une tasse de café et elle change sonétat à 1.

start,,WVUTPQRSONMLHIJK1

2p-- _^]\XYZ[2

tea

ll2p

-- _^]\XYZ[3

coffe

ii

Fig. 4.5: Diagramme états-transitions d'un distributeur des boissons

Le process est illustré par le diagramme d'états-transitions 4.5 qui se composedes états et des transitions, l'état 1 est à la fois l'état initial et l'état �nal27. Unetransition signi�e l'exécution d'une activité, le processus comprend donc des activi-tés : 2p, tea, coffe. Le comportement est une suite des activités successives de l'étatinitial à l'état �nal, le processus se compose donc deux comportements : 2p . tea et2p . 2p . coffe.

Le terme algèbre signi�e une structure mathématique qui se compose d'unensemble des valeurs et des opérations sur les valeurs. Les opérations béné�-cient des propriétés algébriques, tels que commutavité, associativité, idempotence,distributivité[Wing 2002, p.3]. L'algèbre de processus est donc un algèbre qui se munid'un ensemble des processus et les opérations sur les processus (ex. la compositionparallèle, l'addition).

Nous donnons ici la dé�nition du groupe en mathématiques pour illustrer claire-ment le terme algèbre de processus :

Groupe. Un groupe est un ensemble G muni d'une opération interne (g, g′) 7→ g ∗ g′véri�ant les propriétés suivantes :

� il existe un élément e ∈ G tel que pour tout g ∈ G, e ∗ g = g ∗ e = g (existenced'un élémént neutre)

� pour tout g ∈ G, il existe g′ ∈ G tel que g ∗ g′ = g′ ∗ g = e (existence d'uninverse)

� pour tous g, g′, g′′ ∈ G, on a g ∗ (g′ ∗ g′′) = (g ∗ g′) ∗ g′′) (associativité)

Le groupe28 est donc une structure mathématique qui consiste en un ensembledes éléménts et une opération qui satisfait des axiomes du groupe. Il en va de mêmepour l'algèbre de processus : l'algèbre consiste en un ensemble des processus et desopérations satisfaissant des axiomes prédé�nis. Les axiomes permettent de réaliserdes calculs sur les processus.

27Dans ce cas, le diagramme états-transitions est en fait un automate28Un exemple simple d'un groupe est l'ensemble des réels non nuls avec la multiplication


4.3.2 Pi-calcul et spi-calcul

Nous consacrons cette section à présenter une méthode de l'algèbre de processustrès �exible pour la modélisation des systèmes de multi-processus, le π − calcul.Nous aborderons aussi une extension cryptographique du π− calcul, le spi− calcul,qui est une algèbre de processus très adaptée à la modélisation des protocoles cryp-tographiques.

Pi-calcul

Le π−calcul[Milner 1999] modélise un système de communication en dé�nissantformellement ses processus. Le processus se caractérise par une liste des activités. Ilpeut envoyer ou recevoir des messages par ses canaux, de même qu'il peut é�ectuerdes actions internes. Le processus en π− calcul est donc représenté par une formuledes termes dé�nissant ses activités, ses messages échangés et ses canaux.

En fait, il existe de nombreuses versions de π−calcul. Ces versions se distinguentpar ses propres dé�nitions des termes, qui représentent les structures des messageséchangés et dé�nissent des opérations internes. Nous décrivons ici une version par-ticulière dont les termes sont dé�nis par la grammaire :

L,M,N.= termes

x, y, z, . . . variable

a, b, c, k, s, . . . nom

(M,N) paire

Les noms a, b, c, k, s représentent des données atomiques, alors que les variablesx, y, z peuvent être substituées par n'importe quel message. La paire (M,N) repré-sente une structure de message.

En suite, les processus sont dé�nis par la grammaire :

P,Q.= processus

M〈N〉.P émission

M(x).P reception

0 processus nul

P |Q composition parallèle

!P réplication

(new a)P restriction

Le processus M(x).P reçoit un message sur le canal29 M , le stocke dans lavariable x, puis execute P . Le processus M〈N〉.P envoie un message, qui est dé�nipar le terme N sur le canal M , puis s'execute comme le processus P . Le processus0 dé�ni un cas spécial où il s'agit d'un processus qui ne fait rien. Le processus P |Q

29Le canal est représenté par un terme


se compose de deux processus concurrents P et Q. Le processus !P veut dire qu'ilcomprend des plusieurs processus P qui fonctionent simultanément. Le processus(new a)P crée un nouveau nom privé a, puis s'execute comme le processus P .

Pour illustrer la modélisation de protocoles en π − calcul, nous décrivons ci-dessous une modélisation de la première étape d'un protocole très répandu sur l'In-ternet, le TCP[Postel 1981]. L'établissement de la connexion du protocole TCP estréalisé grâce au mécanisme appelé three way handshake :

A

{m}SY N //

{m}ACK //

B{m}SY N_ACKoo

Fig. 4.6: Etablissement d'une connexion TCP

L'établissement d'une connexion TCP entre deux parties A (l'émetteur) et B (lerécepteur) se déroule comme le suivant :

� Etape 1 : l'émetteur A initialise l'établissement en transmettant un segmentdont le drapeau SY N est activé (le bit SY N du segment est mise à 1) aurécepteur B.

� Etape 2 : le récepteur B reçoit le segment initial provenant de l'émetteur A,il répond un accusé de réception étant un segment dont le drapeau SY N etle drapeau ACK sont activés.

� Etape 3 : l'émetteur A transmet au récepteur B un accusé de réception étantun segment donc le drapeau ACK est activé.

A partir de cette spéci�cation informelle, le π − calcul modélise formellementl'établissement par un système PTCP de deux processus indépendants PA et PB quicorrespondent respectivement aux rôles de A et B :

PA = c〈mSY N 〉 . c(xSY N_ACK) . c〈mACK〉 . FA

PB = c(xSY N ) . c〈mSY N_ACK〉 . c(xACK) . QB

PTCP = PA|PB

Fig. 4.7: Modèle formel en π − calcul de l'établissement TCP

Le processus PA modélise des activités de l'émetteur A. Il se compose de quatreactivités (processus) séquentielles : c〈mSY N 〉, c(xSY N_ACK), c〈mACK〉 et FA. Lasuite des activités signi�e que le processus PA doit fonctionner conformément àl'ordre dé�ni par la suite : il doit transmettre le segment SY N , représenté par lenommSY N avant il peut recevoir le segment SY N_ACK, représenté par la variablexSY N_ACK . Le nom c représente un canal publique, qui signi�e l'environnement pu-blique de l'Internet, tous les segments sont envoyés sur un environnement publique.Le processus FA signi�e le fonctionnement de l'émetteur A après l'établissement


de la connexion. Le processus PB modélise des activités du récepteur B, il se com-pose de quatre processus séquentiels : c(xSY N ), c〈mSY N_ACK〉, c(xACK) et QB. Leprocessus QB signi�e le fonctionnement du récepteur B après l'établissement de laconnexion. Finalement, le protocole d'établissement de la connexion TCP PTCP estaussi un processus qui se compose deux processus concurents PA et PB.

Le π − calcul utilise des règles propres pour modéliser les interactions entre desprocessus, s'appellant rélations de réaction :

TAU : τ.P +M → P

REACT : (a.P +M)|(a.P ) +N → P |Q

PAR :P → P ′

P |Q→ P ′|Q

RES :P → P ′

(new a)P → (new a)P ′

STRUCT :P → P ′

Q→ Q′si P ≡ P ′ et Q ≡ Q′

Fig. 4.8: Rélations de réaction

Les signi�cations de ces règles peuvent être consultées dans [Milner 1999, p.34].Nous ne utilisons que ici le règle REACT pour modéliser les interactions entre deuxprocessus PA et PB. Il su�t de remarquer que ces interactions sont des activitésexternes de PA et de PB. Ils sont cependant des activités internes du processusPTCP :

PTCP = PA|PB

= c〈mSY N 〉 . c(xSY N_ACK) . c〈mACK〉 . FA |c(xSY N ) . c〈mSY N_ACK〉 . c(xACK) . QB

REACT−−−−−→ c(xSY N_ACK) . c〈mACK〉 . FA | c〈mSY N_ACK〉 . c(xACK) . QB

REACT−−−−−→ c〈mACK〉 . FA | c(xACK) . QB

REACT−−−−−→ FA | QB

Il en résulte que

PTCP∗−→ FA | QB

L'équation ci-dessus signi�e que : après l'étape de l'établissement �ni avec suc-cès30, le protocole PTCP se transforme en l'intéraction entre deux processus FA et

30En fait, cette modélisation n'est pas tout à fait complète, il faut ajouter à chaque processus PA

et PB des opérations ayant pour but de véri�er des messages reçu. Pour simpli�er les expressions

formelles de A (PA) et de B (PB) nous ignorons ces opérations


QB qui représente l'échange des données entre PA et PB lorsque la connexion TCPa été établie.

Spi-calcul

Le spi − calcul est une extension31 de pi − calcul. Il est proposé la premièrefois par M. Arbadi et A. D. Gordon[Abadi 1998] ayant pour but de modéliser et devéri�er les protocoles cryptographiques.

La version originale de π − calcul[Milner 1999] n'a pas d'opérations cryptogra-phiques qui sont nécessaires pour la modélisation des protocoles cryptographiques.Les auteurs ont étendu donc π − calcul en y ajoutant des primitives cryptogra-phiques :

spi-calcul = pi-calcul + cryptographiques primitives

Les opérations cryptographiques en spi − calcul sont dé�nies par les paires(constructeur, destructeur)32. En général, le constructeur représente le chi�rementet le destructeur représente le déchi�rement. Les primitives cryptographiques (cf.section 4.2.1) sont représentées comme les suivantes :

� Chi�rement symétriqueConstructeur : chi�rement de x sous la clé y, sencrypt(x, y)Destructeur : déchi�rement sdecrypt(sencrypt(x, y), y)→ y

� Chi�rement asymétriqueConstructeur : chi�rement de x sous la clé y, pencrypt(x, y)génération de la clé publique à partir de la clé secrète y, pk(y)

Destructeur : déchi�rement pdecrypt(pencrypt(x, y), y)→ y

� Signature numériqueConstructeur : signature du x avec la clé secrète y, sign(x, y)génération de la clé publique à partir de la clé secrète y, pk(y)

Destructeur : véri�cation de signature checksign(sign(x, y), pk(y))→ x

Fig. 4.9: Modélisation des primitives cryptographiques

Les constructeurs sont ajoutés dans la grammaire des termes. Ils permettentdoncs de construire de nouveaux termes.

L,M,N.= termes

x, y, z, . . . variable

a, b, c, k, s, . . . nom

(M,N) paire

f(M1, . . . ,Mn) application de constructeur

31Remarquons qu'il existe plusieurs versions di�érents de π − calcul32Dans ces travaux, nous utilisons les expressions proposées par B. Blanchet[Blanchet 2008, p.19]


Les destructeurs n'apparaissent pas dans les termes car ils manipulent plutôt lestermes dans les processus33. La grammaire de processus en spi−calcul sont étendueen ajoutant des opérations comme la suivante :

P,Q.= processus

M〈N〉.P émission

M(x).P reception

0 processus nul

P |Q composition parallèle

!P réplication

(new a)P restriction

let x = g(M1, . . . ,Mn) in P esle Q application de destructeur

let x = M in P dé�nition locale

if M = N then P then Q conditionnelle

Les destructeurs sont des fonctions partielles que les processus peuvent appliquer.Le processus let x = g(M1, . . . ,Mn) in P esle Q essaie d'évaluer g(M1, . . . ,Mn) ; sicela réussit, x est lié au résultat obtenu et P est exécuté ; sinon, Q est exécuté. Ladé�nition locale let x = M in P est égale à une substitution P{M/x} qui assigne lenomM à la variable x du processus P . La condition ifM = N then P thenQ exécuteP si M et N se réduisent vers le même terme, sinon elle exécute Q[Blanchet 2008,p.19].

Pour illustrer la modélisation en spi − calcul des protocoles cryptographiques,nous décrivons ci-dessous la représentation formelle du protocole de distribution declés de Denning-Sacco (cf. �gure 4.1) :

PA = (new k) (new skA) let pkA = pk(skA) in

c〈pkA〉 . c(pkB) . c〈encrypt(sign(k, skA), pkB)〉 . 0

PB = (new m) (new skB) let pkB = pk(skB) in

c(pk) . c〈pkB〉 . c(mencrypt) . let msign = pdecrypt(mencrypt, pkB) in

let k = checksign(msign, pk) in

c〈sencrypt(m, k)〉 . 0

P =PA|PB

Fig. 4.10: Modèle formel en spi− calcul du protocole Denning-Sacco

Les processus PA, PB correspondent respectivement aux participants A et B. Leprotocole est représenté par le processus P qui se forme de deux processus PA etPB fonctionnant parallèlement. Le processus PA génére deux clés fraîches : k de la

33C'est-à-dire, les destructeurs sont utilisés pour modéliser des activités de processus


cryptographique symétrique (elle sera la clé de session), skA de la cryptographiqueasymétrique. Puis, PA construit la clé publique pkA correspondant à la clé secrèteskA en utilisant le constructeur pkA = pk(skA). Ensuite, la clé publique pkB estenvoyée sur le canal publique c : c〈pkA〉. Le processus PA reçoit la clé publique deB sur le canal c : c(pkB), il signe sa clé de session k avec sa clé secrète skA par leconstructeur sign(k, skA). La signature numérique est chi�rée avec la clé publiquede B en appliquant le constructeur encrypt(sign(k, skA), pkB), puis la signaturechi�rée est envoyée sur le canal publique c : c〈encrypt(sign(k, skA), pkB)〉. Le pro-cessus PB généré aussi une clé secrète de la cryptographique asymétrique skB. Il créela clé publique correspondante en utilisant le constructeur pkB = pk(skB). Il reçoitune clé publique sur le canal publique c et la stocke dans le variable pk : c(pk), puisil émet sa clé publique sur ce canal : c〈pkB〉. Le processus PB reçoit le message surle canal publique c et le stocke dans la variable mencrypt, c'est une signature chi�rée.Il utilise sa clé publique pour déchi�re ce message, le résultat du déchi�rement estassigné à la variable msign. Le processus B véri�e la donnée msign en utilisant la clépublique reçue pk, si la véri�cation est �nie avec succès, il utilise la clé de session kétant reçue par la véri�cation pour chi�re le message m : sencrypt(m, k). En�n, ilémet le message chi�ré sur le canal publique c : c〈sencrypt(m, k)〉.

Nous avons étudié la modélisation des protocoles en π− calcul (cf. �gure 4.7) etdes protocoles cryptographiques en spi−calcul (cf. �gure 4.10). Les modèles formelssont créés naturellement à partir des spéci�cations informelles.

4.3.3 Modèle de traces et clauses de Horn

Il existe une autre approche de la modélisation des protocoles, s'appelle modèlesde traces. Le modèle de traces a été utilisé la première fois par D. Dolev et A.Yao[Dolev 1983] pour modéliser et véri�er des protocoles cryptographiques. Ils ontproposés une représentation formelle des protocoles cryptographiques en utilisantdes règles de réécriture34. Une variante de la modélisation sous forme de réécritureest la modélisation sous forme de clauses de Horn. Cette modélisation présentel'avantage de permettre l'utilisation des techniques déjà développées sur les clausescomme la méthode de résolution[Cortier 2009, p.10].

Dans cette section, nous présenterons une méthode de modélisation et devéri�cation basée sur les clauses de Horn, proposée par B. Blanchet et X.Allamigeon[Allamigeon 2005, Blanchet 2001]. En basant sur cette méthode, ils ontcréé aussi un outil informatique, ProVerif[Blanchet 2005], qui permet de véri�er lesprotocoles cryptographiques et de reconstruire de l'attaque contre les protocole vul-nérables.

34Ils utilisent des règles de réécritutre dans une classe des protocoles, s'appelle protocole de

cascade[Dolev 1983, p.3]


Clauses de Horn

Les clauses de Horn sont des clauses logiques35 qui comportent au plus un atomepositif. Les clauses de Horn donc s'écrivent sous la forme :

(r1 ∨ r2 ∨ . . . ∨ rn) ∨ h

our1 ∧ r2 ∧ . . . ∧ rn → h

Les clauses de Horn peuvent être utilisées pour modéliser l'excution des pro-tocoles cryptographiques et les véri�er. L'idée d'utiliser les clauses de Horn a étéproposée la première fois par Weidenbach[Weidenbach 1999]. Les clauses de Hornsont aussi le formalisme au c÷ur du logiciel ProVerif, un outil de véri�cation automa-tique des protocoles cryptographiques, développé par Blanchet B.[Blanchet 2001].La modélisation d'un protocole en clauses de Horn est en fait celle des capacitésde l'attaquant, qui se construisent par les opérations cryptographiques et par lescaractères propres du protocole.

Les capacités de l'attaquant se composent des capacités de déduction et desconnaissances. Les opérations dans la �gure 4.9 sont modélisées sur les formes declauses de Horns :

I(x) ∧ I(y)→ I(pair(x, y)) Forme la paire de deux messages

I(m) ∧ I(pk)→ I(pencrypt(m, pk)) Chi�re un message avec une clé publique

I(sk)→ I(pk(sk)) Crée une clé publique d'une clé secrète

I(pencrypt(m,

pk(sk))) ∧ I(sk)→ I(m) Déchi�re un message avec une clé secrète

I(m) ∧ I(k)→ I(sencrypt(m, k)) Chi�re un message avec une clé partagée

I(sencrypt(m,

k)) ∧ I(k)→ I(m) Déchi�re un message avec une clé partagée

La notion logique prédicat unaire36 I représente la connaissance de l'attaquant37.Les capacités initiales38 de l'attaquant se modélisent en considérant l'ensemble �nide clauses[Cortier 2009, p.35] :

CI0 = {I(t) | t ∈ I0} (4.1)

La clause I(m) ∧ I(pk) → I(pencrypt(m, pk)), représente une capacité de dé-duction de l'attaquant, signi�e que, si l'attaquant sait le message m et la clé pu-blique pk, il peut réaliser une chi�rement asymétrique pour créer le message chi�ré

35Une clause logique s'est formée d'une disjonction (∧) des atomes logiques36Un prédicat se réfère à un propriété que le subjet possède, par exemple le prédicat attacker(m)

veut dire : l'attaquant attacker connaît le message m37Par exemple, le prédicat I(m) signi�e que l'attaquant sais m38Remarquons que l'capacité de l'attaque s'écrire en un prédicat, l'capacité de déduction de

l'attaquant s'écrire en un clause de Horn


pencrypt(m, pk). La clause I(sk) → I(pk(sk)) veut dire que, si l'attaquant saitla clé secrète sk, il peut créer la clé publique correspondante pk(sk). La clauseI(pencrypt(m, pk(sk))) ∧ I(sk) → I(m) signi�e que, si l'attaquant sait le messagechi�ré (par le chi�rement asymétrique) et il sait aussi la clé secrète, il peut déchi�rele message pour savoir le texte claire.

L'idée principale de la véri�cation des procotoles est de découvrir toutes lescapacités de l'attaquant en utilisant un système de déduction39. Un système dedéduction est un ensemble �ni des règles, chacun d'eux peut s'écrire en un clausede Horn :

u1 ∧ u2 ∧ . . . ∧ un → u

Étant donné un système de déduction, le prédicat t est déductible en un pasà partir d'un ensemble de prédicats S s'il existe u1, . . . , un ∈ S et une règle dedéduction[Cortier 2009, p.21] :

u1 ∧ . . . ∧ un → t

Le prédicat t est déductible à partir de S s'il existe une suite �nie t1, . . . , tn telque : ti+1 est déductible en un pas à partir de S ∪ {t1, . . . , ti} ∀ 0 ≤ i ≤ n− 1et t = tn.

Le protocole comprend des règles, chacun d'entre eux est représenté de façoninformel par un échangé de message complexe entre des participants. Pour chaqueprotocole particulière, l'attaquant peut l'expoiter de façon propre. Dans le cas gé-néral, ses capacités étant obtenues par l'expoitation d'un protocole, sont modéliséespar des clauses de Horn sur la forme :

I(u) → I(v)

En début de la modélisation, les capacités de l'attaquant se trouvent dans l'en-semble CI0 (cf. équation 4.1). L'ensemble de capacités s'est augmenté en ajoutantdes nouveaux prédicats qui sont déductibles à partir de CI0 en appliquant les règlesde déduction situés dans la modélisation de l'attaquant et dans la modélisation duprotocole.

Nous illustrons la modélisation des protocoles cryptographiques en donnant ci-dessous un exemple d'une version simpli�ée du protocole de distribution de clésDenning-Sacco[Denning 1981] illustrée dans le �gure 4.1 :

A→ B : {{k}skA}pkB

B → A : {m}k

La modélisation des capacités de l'attaquant en clauses de Horn se base sur lestravaux de B. Blanchet[Blanchet 2001, p.3]. Elle se divise en deux étapes : (1) modé-liser les capacités étant obtenues par les opérations cryptographiques, (2) modéliserles capacités étant obtenues en exploitant le protocole propre.

39L'utilisation de système de déduction en la véri�cation des protocoles cryptographiques est

aussi proposée la première fois par D. Dolev et A. C. Yao, ils utilisent un ensemble des règles de

réduction[Dolev 1983, p.5]


Modéliser les capacités étant obtenues par les opérations cryptographiques : leprotocole Denning-Sacco utilise des primitives cryptographiques de la cryptogra-phique asymétrique et de la cryptographique symétrique. Les capacités de l'atta-quants sont modélisées par les clauses :

attacker(m) ∧ attacker(pk)→ attacker(pencrypt(m, pk))

attacker(sk)→ attacker(pk(sk))

attacker(pencrypt(m, pk(sk))) ∧ attacker(sk)→ attacker(m)

attacker(m) ∧ attacker(sk)→ attacker(sign(m, sk))

attacker(sign(m, sk))→ attacker(m)

attacker(m) ∧ attacker(k)→ attacker(sencrypt(m, k))

attacker(sencrypt(m, k)) ∧ attacker(k)→ attacker(m)

L'attaquant sait les deux clés publiques de A et de B. Ainsi, ses connaissancesinitiales sont :

attacker(pk(skA)), attacker(pk(skB))

Modéliser les capacités étant obtenues en exploitant le protocole propre : l'envi-ronnement des intéractions entre A et B est publique, tout le monde peut écouter,intercepter, changer les messages envoyés par ces interlocuteurs. Dans le premiermessage : A→ B : {{k}skA

}pkB, A émet toujour le message {{k}skA

}pkBs'il obtient

la clé publique de B : pkB. Alors, un attaquant actif X peut trompe A en l'envoyantsa clé publique pk(skX) et puis il va obtenir le message {{k}skA

}pkX. Le premier

message permet donc d'ajouter une clause :

attacker(pk(x))→ attacker(pencrypt(sign(k, ska), pk(x)))

De façon analogue pour le deuxième message B → A : {m}k, B répond toujoursce message s'il peut déchi�re le message précédent et véri�er le résultat. Un atta-quant actif peut trompe B en l'envoyant un message pencrypt(sign(k′, ska), pk(x))qu'il a stocké auparavant. Dans ce cas là, l'attaquant va obtenir le message {m}k′ .Le deuxième message permet donc d'ajouter une clause :

attacker(pencrypt(sign(k′, skA), pk(skB)))→ attacker(sencrypt(s, k′))

Les clauses de la modélisation du protocole propre (les clauses obtenues par lesdeux messages), les clauses obtenues par les primitives cryptographiques utiliséeset les connaissances initiales de l'attaquant forment un système de déduction quireprésente le modèle formel en clauses de Horn du protocole.

Nous remarquons que le système de déduction du protocole, créé par les clausesde Horn, cache les activités du protocole. En fait, ce système ne représente que lescapacités de l'attaquant.


4.4 Modèles formels des attaques

Nous avons étudié la modélisation formelle des protocoles cryptographiques parspi− calcul et par les clauses de Horn. Cette section est consacré à représenter lesmodèles formels des attaques contre un protocole cryptographique.

Revenons à la section 4.1.3, un protocole de sécurité vise à assurer des propriétésde sécurité. L'attaque contre un protocole donc vise à casser le propriété de sécuritéque le protocole assure. Dans ces travaux, nous n'aborderons que aux protocolesdont la propriété de sécurité est le secret.

Il existe deux notions de secret[Abadi 2000, p.14], chacune d'entre elles est signi-cative dans un modèle formel. L'une se base sur l'équivalence40 entre des processus,cette notion est utilisée dans les modèles d'algèbres de processus. L'autre se base surles connaissances que l'attaquant peut déduire en utilisant un système de déduction,il est bien entendu que cette notion est utilisée dans les modèles de traces.

4.4.1 Attaques en spi− calcul

Etant donné un process P représentant un protocole de sécurité, le protocoleveut assurer le secret d'un donnée, qui est représenté par la variable x du processus.Le processus s'écrit donc P (x). Le processus P (x) protége le secret de x si P (M) etP (N) sont équivalents pour tous les termes M et N [Abadi 2000, p.14].

Intuitivement, l'équivalence entre P (M) et P (N) signi�e que un autre processus,qui communique avec P , ne peut jamais déterminer si la variable x du processusP (x) est assignée à M ou à N . L'équivalence est illustrée par un exemple : leprocessus c〈sencrypt(x,K)〉 qui envoie le message chi�ré {x}K sur le canal c, nepeut pas protéger le secret de x contre un attaquant qui sait le canal c et la clé K.L'attaquant contre ce processus peut être représenté par le processus Q

Q = c(m) . let y = sdecrypt(m,K) in c〈y〉

En utilisant des règles des réactions (cf. �gure 4.8), nous pouvons déduire :

P (M)|Q =c〈sencrypt(M,K)〉|c(m) . let y = sdecrypt(m,K) in c〈y〉∗−→c〈M〉

P (N)|Q =c〈sencrypt(N,K)〉|c(m) . let y = sdecrypt(m,K) in c〈y〉∗−→c〈N〉

Alors, Q peut toujours distingue P (M) de P (N).L'attaquant contre un processus général P (x) est donc dé�ni par un proces-

sus Q. Il va essayer de détecter le changement de la variable x. Autrement dit,l'attaquant est un processus Q, tel que le processus P |Q émet x sur un canalpublique[Abadi 2005, p.11]41.

40L'équivalence observationnelle est très importante dans la démonstration formelle de la véri�-

cation des protocoles cryptographique[Cortier 2009, 65]41Il est bien entendu que si P |Q émet x sur un canal publique, le changement de x sera détecté

4.4. Modèles formels des attaques 45

4.4.2 Attaques en clauses de Horn

Pour la modélisation en clauses de Horn, le protocole ne peut pas protéger unedonnées x si x se trouve dans l'ensemble de connaissances de l'attaquant qui est créépar un système de déduction. Il n'existe pas d'une expression explicite d'attaqueen clauses de Horn. En fait, l'attaque est trouvée par la résolution du systèmede déduction, il est donc décrite par une trace qui est créée par l'algorithme derésolution é�ectué sur le système de clauses de Horn.

Chapitre 5

Solution à la méthode génériqued'attaque

Sommaire

5.1 Méthode générique d'attaque . . . . . . . . . . . . . . . . . . 47

5.1.1 Plan d'attaque et analyses . . . . . . . . . . . . . . . . . . . . 47

5.1.2 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.2 Représentation de l'attaque contre Waledac . . . . . . . . . 49

5.2.1 Modélisation du protocole de communication . . . . . . . . . 50

5.2.2 Attaque contre la distribution de la clé de session . . . . . . . 51

5.1 Méthode générique d'attaque

Au chapitre précédent, nous avons présenté des connaissances théoriques de lavéri�cation automatique des protocoles cryptographiques. Ce chapitre est consa-cré à proposer une solution à la méthode générique d'attaque contre les botnets.Cette solution suivre le plan d'attaque proposée dans la �gure 3.8. Elle se basesur les travaux originaux de R. Milner[Milner 1999] en π − calcul, sur les tra-vaux de M. Abadi et A. D. Gordon[Abadi 1998] en spi − calcul et la dé�nitionformelle d'attaque[Abadi 2000, Abadi 2005], et sur les travaux de B. Blanchet et X.Allamigeon[Blanchet 2005, Allamigeon 2005] en véri�cation des protocoles par lesclauses de Horn et en reconstruction d'attaque.

5.1.1 Plan d'attaque et analyses

Nous réviserons le plan d'attaque générique proposé dans la section 3.6.3. Puisnous analyserons en détail chaque étape dans ce plan pour construire une solutionréalisable.

Plan d'attaque

Nous avons vu dans la section 3.6.3, l'approche proposée (cf. �gure 3.8) pourl'attaque générique contre les botnets comprend trois étapes les plus importantes :

1. Modéliser le protocole de communication du botnet.

2. Véri�er le modèle obtenu.

48 Chapitre 5. Solution à la méthode générique d'attaque

3. Reconstruire l'attaque si le protocole est vulnérable.

Le but de notre plan n'est rien d'autre qu'une solution réele, c'est-à-dire nousvoulons créer un système informatique qui permet d'attaquer automatiquement lesbotnets. Cependant, nous visons à une attaque générale qui casse la sécurité du pro-tocole de communication. Cette attaque est considérée comme une base sur laquelleles autres attaques peuvent se dérouler1.

Analyses

La première étape peut être réalisée en utilisant une méthode d'algèbre de pro-cessus (une révision courte des travaux existants peut être consultée dans l'annexeB) ou celle de clauses de Horn. D'une part, un algèbre de processus, par exemplespi− calcul, nous permet de construire naturellement un protocole de communica-tion. D'autre part, les clauses de Horn ne modélise pas le protocole, ils construisentplutôt l'ensemble de capacités d'attquant.

La deuxième étape peut être réalisée aussi par l'algèbre de processus ou lesclauses de Horn. Cependant, la véri�cation des protocoles en utilisant les outils d'al-gèbre de processus est assez compliquée2. Il est di�cile de réaliser une telle véri�ca-tion par un algorithme étant capable d'être implémenté en un logiciel. D'autre part,la véri�cation par les clauses de Horn peut être réalisée en utilisant des algorithmesde résolution sur les clauses3.

L'algèbre de processus nous permet d'écrire une attaque formelle sur la formed'un processus. Cette forme nous permet d'implémenter facilement ce attaque dansun système informatique. Cependant, la réconstruction d'une telle attaque en algèbrede processus est di�cile. En fait, il n'existe pas encore de méthodes permettantde reconstruire les attaques en modèle de l'algèbre de processus. En clauses deHorn, les deux auteurs B. Blanchet et X. Allamigeon ont proposé une méthodede la reconstruction d'attaques. De plus, ils ont implémenté aussi un outil, appeléProVerif[Blanchet 2005], qui permet de reconstruire automatiquement les attaques.

5.1.2 Solution proposée

À partir des analyses ci-dessus, nous proposons une solution réalisable à l'attaquegénérique contre les botnet en concrétisant des étapes du plan théorique. Le c÷urde la solution est l'outil ProVerif qui permet à la fois de véri�er un protocole enforme de spi − calcul et de reconstruire d'attaque si le protocole est vulnérable.Cette solution se compose des étapes :

1. Découvrir le protocole de communication du botnet

1Par exemple, l'attaque Sybil et le faux-répéteur dans le cas de botnet peuvent s'e�ectuer

seulement si les messages des bots sont déchi�rés et modi�és2Une démonstration formelle de secret ou celle de autheti�cation en spi − calcul est basée sur

l'équivalence observationnelle, une telle démonstration du protocole Wide-Mouthed-Frog peut être

consultée dans [Abadi 1998, p.35]3Un algorithme de résolution sur les clauses peut être consulté dans [Blanchet 2008, p.28]

5.2. Représentation de l'attaque contre Waledac 49

2. Modéliser ce protocole en spi− calcul3. Véri�er ce protocole en utilisant ProVerif

4. Si le protocole est vulnérable, reconstruire l'attaque sous forme de spi−calculen utilisant ProVerif

5. Implémenter l'attaque (dans un système informatique)

modéliser ceprotocole enspi − calcul


découvrir leprotocole de

communicationdu botnet

véri�er ceprotocoleen utilisantProVerif

protocole estvulnérable ?

reconstruirel'attaque

sous forme despi − calculen utilisantProVerif

s'arrêterimplémenterl'attaque

yes

no

Fig. 5.1: Solution réalisable

5.2 Représentation de l'attaque contre Waledac

Dans cette section, nous appliquerons la méthode ci-dessus pour le cas du botnetWaledac en décrivant les réprésentations en spi − calcul du protocole de commu-nication du botnet. En fait, le protocole est très vulnérable et il est assez facile dedécouvir une attaque de l'homme milieu contre ce protocole. Il existe même uneautre attaque plus simpli�ée grâce à la découverte de la clé K1. De plus, nous pou-vons aussi utiliser ProVerif pour le véri�er et recontruire l'attaque contre lui. L'im-plémentation par le langage dédié4 de ProVerif peut être consultée dans l'annexeA.

4Domain Speci�c Language


5.2.1 Modélisation du protocole de communication

Le réseau du botnet Waledac (cf. section 3.3.1) a l'architecture hiérarchique secomposant de 4 couches :

1. Spammeurs : les esclaves, envoyent des spams

2. Repeateurs : les relais, transmettent des informations de contrôle du botnet

3. Protecteurs : les serveurs HTTP, cachent et protegent l'existence du serveurde contrôle

4. Serveur(s) de contrôle : chef du botnet, contrôle son fonctionnement.

Si nous ne considerons que les messages de commande circulant entre les spam-meurs et le serveur de contrôle, les répéteurs et les protecteurs ne sont rien d'autresque les machines de relais qui ne retransmettent que ces messages. Alors, nous pou-vons considérer qu'il existe un canal virtuel entre les spammeurs et le serveur decontrôle.

Spammeur oo messages // Repeateur oo messages // Protecteur oo messages // Serveur

++

messages

ss WXXYYZ[[\]]^^_``aabccdeeffg

Fig. 5.2: Communications entre les couches du botnet

Sur le point de vue de sécurité, l'étape le plus importante du protocole de com-munication entre un spammeur et le serveur de contrôle est la distribution de la cléde session5, parce que si nous connaissons la clé de session, nous pouvons déchi�rertous les messages circulants.

Spammeur

pkspam //

Serveur{ksession}pkspamoo

//messageksessionoo

Fig. 5.3: Distribution de la clé session entre le spammeur et le serveur

Cette étape se compose des messages :

Message 1. spammeur→ serveur : {pkspammeur}K1

Message 2. serveur→ spammeur : {ksession}pkspammeur

Message 3. spammeur→ serveur : {message}ksession

5Cette étape est initialisée par le message getkey (cf. 3.4.1)


Nous remarquons que la clé K1 a été découverte par rétro-ingénierie, alors lepremière message peut être simpli�é à un message clair, comme le �gure 5.3. Nousmodélisons donc le protocole de distribution de clé de session en spi− calcul :

Spammer , (new skspam) c〈pk(skspam)〉 . c(m) . let k = pdecrypt(m, skspam)

in c〈sencrypt(M,k)〉Server , (new ksession) c(pkspam) . c〈pencrypt(ksession, pkspam)〉 .

c(Ms) . let M = sdecrypt(Ms, ksession) in F (M)

Pdistribution , Spammer|Server

5.2.2 Attaque contre la distribution de la clé de session

Le protocole cryptographique du botnet n'est pas sécurisé du tout. Nous pouvonsaisément le casser grâce à la découverte de la cléK1, et la sécurité du protocole est unjeu d'enfants ! ! !. Cependant, nous présentons ici une autre attaque plus compliquée,l'attaque de l'homme du milieu :

Spammeur

pkspam //

Adversaire

pkadv //

{ksession}pkspamoo

//{message}ksessionoo

Serveur{ksession}pkadvoo

//{message}ksessionoo

Fig. 5.4: Attaque contre protocole cryptographic du Waledac

Dans cette attaque, l'attaquant intercepte et change les messages circulant entrele spammeur et le serveur de contrôle. Il intercepte la clé publique du spammeur etla change à sa clé publique. Puis, il envoie sa clé publique au serveur de contrôle.Le serveur utilise cette clé pour chi�re la clé de session, et envoie la clé de sessionchi�rée à spammeur. L'attaquant intercepte ce message encore une fois, déchi�rece message en utilisant sa clé publique. L'attaquant rechi�re le message avec laclé publique du spammeur, et envoie le message rechi�ré à spammeur. Avec cetteattaque, le spammer et le serveur de contrôle ne peuvent pas reconnaître l'existencede l'attaquant. La modélisation de l'attaque en spi− calcul :

Attacker , (new skatt) c(pkspam) . c〈pk(skatt)〉 .c(mserver) . let ksession = pdecrypt(mserver, skatt) in

c〈pencrypt(ksession, pkspam)〉 . c(Mencrypted) .

let M = sdecrypt(Mencrypted, ksession) in Q(M)

Attack , Attacker|Pdistribution

Nous pouvons maintenant montrer que l'attaque casse la con�dentialité du pro-tocole :


Attack , Attacker|Pdistribution

, (new skatt) c(pkspam) . c〈pk(skatt)〉 .c(mserver) . let ksession = pdecrypt(mserver, skatt) in



| (new skspam) c〈pk(skspam)〉 . c(m) . let k = pdecrypt(m, skspam)

in c〈sencrypt(M,k)〉| (new ksession) c(pkspam) . c〈pencrypt(ksession, pkspam)〉 .c(Ms) . let M = sdecrypt(Ms, ksession) in F (M)

REACT−−−−−→ c(mserver) . let ksession = pdecrypt(mserver, skatt) in



| c(m) . let k = pdecrypt(m, skspam) in c〈sencrypt(M,k)〉| c〈pencrypt(ksession, pkatt)〉 .c(Ms) . let M = sdecrypt(Ms, ksession) in F (M)

REACT−−−−−→ c(mserver) . let ksession = pdecrypt(mserver, skatt) in



| c(m) . let k = pdecrypt(m, skspam) in c〈sencrypt(M,k)〉| c〈pencrypt(ksession, pkatt)〉 .c(Ms) . let M = sdecrypt(Ms, ksession) in F (M)

REACT−−−−−→ c〈pencrypt(ksession, pkspam)〉 . c(Mencrypted) .


| c(m) . let k = pdecrypt(m, skspam) in c〈sencrypt(M,k)〉| c(Ms) . let M = sdecrypt(Ms, ksession) in F (M)

REACT−−−−−→ c(Mencrypted) .


| c〈sencrypt(M,ksession)〉| c(Ms) . let M = sdecrypt(Ms, ksession) in F (M)

REACT−−−−−→ Q(M)

| c(Ms) . let M = sdecrypt(Ms, ksession) in F (M)

Il est en résulte que


Attack∗−→ Q(M) | c(Ms) . let M = sdecrypt(Ms, ksession) in F (M)

Q(M) est un processus quelconque de l'attaquant, le processus Attacker peutdonc toujours distingue P (M) et P (N) (ex. Q(M) , c〈M〉). De plus, le protocolevise à protéger le message M (ou N). C'est-à-dire, l'attaquant peut casser le secretdu protocole.

Chapitre 6

Conclusion et perspective

Sommaire

6.1 Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

6.2 Limite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

6.3 Perspective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

6.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

6.1 Contribution

Les contributions du stage sont rappelées : les travaux réalisés pendant la périodede stage se concentrent sur l'attaque contre des protocoles cryptographiques utiliséspar des botnets. Dans la section 3.6.3, nous proposons un nouveau "framework"servant à construire une attaque générique contre les botnets. Une telle attaquecasse la sécurité des protocoles de communication des botnet, donc peut être utiliséecomme une base sur laquelle les attaques successives peuvent se déroulent.

Dans la section 4.4.1, nous proposons une nouvelle idée de la modélisation de l'at-taque en spi−calcul. L'attaque est représentée comme un processus qui se fonctionneparallèlement au protocole, et essaie à révéler des informations que le protocole pro-tège. Cette modélisation nous permet de mettre en application une attaque formellecar la représentation en spi− calcul d'un processus est proche de sa représentationen un langage de programmation.

Dans le chapitre 5, nous donnons des analyses détaillés pour la mise en place duframework. D'une part, nous expliquons la nécessité d'utilisation des méthodes for-melles permettant de véri�er automatiquement les protocoles cryptographiques. Noustransformons donc un problème réel des botnets en un problème assez formel pourpro�ter les méthodes théoriques existantes. D'autre part, nous décrivons clairementquelle méthode appropriée à utiliser dans chaque étape du framework et propo-sons une solution réalisable du framework en se basant sur un outil de véri�cationautomatique, ProVerif.

Nous appliquons ces méthodes dans un cas particulier du botnet Waledac. Dansla section 5.2, nous présentons une représentation du protocole de communicationutilisé par le botnet en spi− calcul. Puis, nous utilison ProVerif pour véri�er cettereprésentation1. L'attaque contre Waledac est modélisée par un processus en spi−

1Le script de ProVerif est décrit dans l'annexe A

56 Chapitre 6. Conclusion et perspective

calcul, et nous décrivons une démonstration formelle qu'elle casse la con�dentialitédu protocole.

Notre framework ne se limite pas aux tels protocoles erronés comme ceux deWaledac. Il est capable de détecter des vulnérabilités (de protocole cryptographique)de n'importe quel botnet.

Finalement, nous implementons un simulateur2 de Waledac en C++. Ce simu-lateur nous permet de visualiser le fonctionnement du botnet.

6.2 Limite

La première limite, il est bien entendu que notre framework n'est pas encoreimpléménté comme un système informatique. Ainsi nous ne pouvons que prévoirqu'il est feasible. Nous ne pouvons pas parler des di�cultés réeles de la réalisationdu framework.

Notre approche rencontre aussi des limité théorique. La première limite concernela version de π − calcul (ou spi− calcul) utilisée : c'est une version monoadic danslaquelle nous ignorons la structure de tous les messages. En fait, cette simpli�ca-tion peut entraîner des erreurs. Pour illustrer cette situation, nous décrivons ici unexemple assez théorique3 :

S

{A,B,IA,{IB}kSB}kSAvvmmmmmmmmmmmmmmmm

A

A,B

66mmmmmmmmmmmmmmmm

{IB}kSB

// B

Fig. 6.1: Variant du protocole Needham-Schroeder

Le variant du protocole d'authenti�cation de Needham-Schroeder[Needham 1978] illustré ci-dessus est présenté dans [Abadi 1999,p.5], nous ne faisons attention que aux trois premières messages :

Message 1. A→ S : {A,B}Message 2. S → A : {A,B, IA, {IB}kSB

}kSA

Message 3. A→ B : {IB}kSB

A envoie son identité et l'identité de l'interlocuteur B au serveur S. Puis, leserveur renvoie à A des informations con�dentielles IA et IB qui sont chi�rées avecles clés partagées kSB et kSA. A reçoit le message {A,B, IA, {IB}kSB

}kSA, il le dé-

chi�re en utilisant la clé kSA et fait suivre le donnée {IB}kSBà B. Dans le cas

spécial : A et B sont une même personne, s'appelle X : lorsque X reçoit le mes-sage {IX}kSX

mais X ignore la structure du message, il croit que le message reçu

2Ce simulateur peut être consultée dans l'annexe D3Ce n'est pas tout à fait un exemple qui concerne directement à l'attaque, cependant il est un

avertissement de mauvais utilisation si la structure de message est ignorée

6.3. Perspective 57

est {X,X, IX , {IX}kSX}kSX

et alors il le déchi�re en utilisant la clé kSX , puis faitsuivre une partie du message déchi�ré. Dans ce cas là, X a révélé une informationcon�dentielle.

Une autre limite théorique réside à l'algorithme de résolution de ProVerif : dansle cas général, cet algorithme ne s'arrête pas[Blanchet 2001, p.9]. Nous remarquonsque la véri�cation du protocole, dans le cas général, est aussi un problème NP-complet[Rusinowitch 2001].

Nous ne pouvons pas encore résoudre complètement le problème de la reconstruc-tion d'attaque en spi− calul. En théorique, cette reconstruction peut être obtenuepar la trace de l'alogrithme de résolution en clauses de Horn. Cependant, l'outilutilisé, ProVerif, ne peut pas donner une représentation de l'attaque en spi− calul.

6.3 Perspective

Une solution plus complète peut être obtenue en utilisant la version polyadic dupi− calcul[Milner 1991]. L'extension cryptographique de pi− calcul polyadic a étéproposée par M. Abadi et B. Blanchet[Abadi 1999, Abadi 2005].

Dans notre approche, la reconstruction d'attaque se base sur une transformationde spi − calcul aux clauses de Horn. Nous souhaitons donc avoir une methode quipermet de reconstruire directement l'attaque en spi− calcul.

Le bi-graph est une nouvelle méthode créée par R. Milner[Milner 2001]. Il per-met aussi de modéliser les processus concurents de façon plus forte que pi− calcul,sa extension cryptographique donc est une approche potentielle pour l'analyse au-tomatique des protocoles cryptographiques.

6.4 Conclusion

De nos jours, les botnets deviennent de plus en plus compliqués. Pour les élimi-ner, il est nécessaire de coordonner plusieurs méthodes. Il existe des méthodes quisont considérées comme "théoriques". Cependant, ces méthodes nous permettent derésoudre le problème de façon plus radicale.

Dans ce stage, nous avons prouvé que il est possible d'appliquer les méthodesthéoriques pour proposer un framework générique d'attaque des botnets. Notre ap-proche vise à exploiter des vulnérabiltés des protocoles de communication des botnet,particulièrement les protocoles cryptographiques.

Annexe A

ProVerif

Sommaire

A.1 ProVerif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

A.2 Modélisation du protocole de Waledac . . . . . . . . . . . . . 59

A.1 ProVerif

ProVerif[Blanchet 2005] est un véri�cateur automatique de protocoles développépar B. Blanchet et X. Allamigeon. ProVerif permet de véri�er un protocole quis'écrit en spi− calcul ou en clauses de Horn. Dans le cas général, le véri�cateur estproximatif[Blanchet 2001, p.2], c'est-à-dire s'il dit qu'il existe de vulnérabilité, c'estpeut-être une alerte fausse. Cependant, s'il dit qu'il n'existe pas de vulnérabilité, leprotocole est sécurisé.

A.2 Modélisation du protocole de Waledac

Nous implémentons ici le protocole de communication du botnet Waledac enutilisant langage dédié de ProVerif.

(*

TA Thanh Dinh (Réalisé au LHS - LORIA - Nancy)

Protocole du botnet Waledac

Spammeur -> Serveur : pkSpam

Serveur -> Spammeur : {sskServer}pkSpam

*)

(* Paramètres *)

param attacker = active.

param reconstructTrace = true.

param traceDisplay = short.

(* Chiffrement asymétrique *)

fun pencrypt/2.

fun pk/1.

60 Annexe A. ProVerif

reduc pdecrypt(pencrypt(m,k), pk(k)) = k.

(* Chiffrement symétrique *)

fun sencrypt/2.

reduc sdecrypt(sencrypt(x,y),y) = x.

(* Environnement *)

free c.

(* Clé de session *)

private free s.

(* Attaquant *)

query attacker:s.

(* Processus *)

let spam = new skSpam;

let pkSpam = pk(skSpam) in

out(c, pkSpam).

let server = in(c, x);

let npk = x in

out(c, sencrypt(s, npk)).

process

spam | server

Le protocole est modélisé par spi − calcul. Nous dé�nissons tout d'abord desprimitives cryptographiques :

(* Chiffrement asymétrique *)

fun pencrypt/2.

fun pk/1.

reduc pdecrypt(pencrypt(m,k), pk(k)) = k.

(* Chiffrement symétrique *)

fun sencrypt/2.

reduc sdecrypt(sencrypt(x,y),y) = x.

Le canal publique sur lequel les messages sont échangés est modélisé par unevariable :

(* Environnement *)

free c.

La clé de session génerée par le serveur est modélisée par une variable privée :

A.2. Modélisation du protocole de Waledac 61

(* Clé de session *)

private free s.

Nous voulons véri�er si l'attaquant est capable d'obtenir cette clé :

(* Attaquant *)

query attacker:s.

Nous exécutons le code par l'outil ProVerif :

./proverif -color -in pi piwaledac

Et nous recevons le résultat :

Process:

(

new skSpam_10;

{4}let pkSpam_11 = pk(skSpam_10) in

{5}out(c, pkSpam_11);

0

) | (

{1}in(c, x_8);

{2}let npk_9 = x_8 in

{3}out(c, sencrypt(s,npk_9));

0

)

-- Query not attacker:s[]

Completing...

Starting query not attacker:s[]

goal reachable: attacker:s[]

1. The attacker has some term y_40.

attacker:y_40.

2. The message y_40 that the attacker may have by 1 may be received at input {1}.

So the message sencrypt(s[],y_40) may be sent to the attacker at output {3}.

attacker:sencrypt(s[],y_40).

3. By 2, the attacker may know sencrypt(s[],y_40).

By 1, the attacker may know y_40.

Using the function sdecrypt the attacker may obtain s[].

attacker:s[].

A more detailed output of the traces is available with

param traceDisplay = long.

62 Annexe A. ProVerif

out(c, pk(skSpam_10_2)) at {5}

in(c, a_1) at {1}

out(c, sencrypt(s,a_1)) at {3}

The attacker has the message s.

A trace has been found.

RESULT not attacker:s[] is false.

ProVerif nous informe que le protocole entré n'est pas sécurisé :

The attacker has the message s.

A trace has been found.

RESULT not attacker:s[] is false.

Le prédicat attacker(s) est false, c'est-à-dire, l'attaquant est capable de savoirla clé de session s. De plus, ProVerif trouve un attaque, il nous dit A trace has beenfound.

Nous remarquons que si l'attaquant est passive, c'est-à-dire s'il ne peut quelire des messages circulant, le protocole est sécurisé. En e�et, nous changons leparamètre :

param attacker = active.

Et nous recevons le résultat suivant :

Process:

(

new skSpam_10;

{4}let pkSpam_11 = pk(skSpam_10) in

{5}out(c, pkSpam_11);

0

) | (

{1}in(c, x_8);

{2}let npk_9 = x_8 in

{3}out(c, sencrypt(s,npk_9));

0

)

-- Query not attacker:s[]

nounif mess:c[],x_27/-5000

Completing...

Starting query not attacker:s[]

goal reachable: mess:c[],y_36 & attacker:y_36 -> attacker:s[]

A.2. Modélisation du protocole de Waledac 63

1. We assume as hypothesis that

attacker:y_41.

2. The attacker initially knows c[].

attacker:c[].

3. We assume as hypothesis that

mess:c[],y_41.

4. The message y_41 that may be sent on channel c[] by 3 may be received at input {1}.

So the message sencrypt(s[],y_41) may be sent on channel c[] at output {3}.

mess:c[],sencrypt(s[],y_41).

5. By 2, the attacker may have the channel c[].

By 4, the message sencrypt(s[],y_41) may be sent on this channel.

So the attacker may obtain the message sencrypt(s[],y_41) by listening on this channel.

attacker:sencrypt(s[],y_41).

6. By 5, the attacker may know sencrypt(s[],y_41).

By 1, the attacker may know y_41.

Using the function sdecrypt the attacker may obtain s[].

attacker:s[].

Could not find a trace corresponding to this derivation.

RESULT not attacker:s[] cannot be proved.

Il nous dit qu'il n'est pas possible de déterminer si l'attaquant peut obtenir laclé de session :

RESULT not attacker:s[] cannot be proved.

Ainsi, il ne peut pas trouver d'attaque en disant : Could not �nd a trace corres-ponding to this derivation.

Annexe B

Algèbre de processus

Sommaire

B.1 Processus Séquentiels Communicants . . . . . . . . . . . . . 65

B.2 LOTOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

B.3 Pi-calcul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

Se situant dans le monde des algèbres de processus, il existe de nombreusesapproches ayant pour but de modéliser et de véri�er des protocoles cryptographiques.Nous considerons dans cette annexe quelques méthodes existantes.

B.1 Processus Séquentiels Communicants

Le processus séquentiels communicants CSP1 est un algèbre de processus, pro-posé la première fois par C. A. R Hoare[Hoare 1978]. En CSP, le processus estcaractérisé par une trace (une suite d'activités)[Hoare 1985, p.19]2. Cette trace estune abstraction mathématique des interactions entre ce processus et l'environementdans lequel il se fonctionne. Le CSP permet aussi de modéliser des interactions entredes processus en utilisant l'échange de messages sur des canaux[Hoare 1985, p.113].Le CSP est utilisé pour modéliser et véri�er des protocoles cryptographiques par denombreux chercheurs, ex[Schneider 1998]. Une explanation plus complète de la mo-délisation et dé la véri�cation des protocoles cryptographiques peut être consultéedans[Ryan 2001].

B.2 LOTOS

Le LOTOS [Bolognesi 1987]3 est un langage d'algèbre des processus. Il permetde spéci�er l'architecture et le fonctionnement de systèmes distribués[Fraikin 2001,p.1]. Le langage LOTOS peut être utilisé pour modéliser les protocoles de sécuritéet les opérations cryptographiques[Germeau 1997].

1Communicating Sequential Processes2Pour le cas général, le processus n'est pas tout à fait une suite d'activités déterministes, le CSP

permet de modéliser un processus par une notion indéterministe de trace[Hoare 1985, p.81]3Language of Temporal Ordering Speci�cation

66 Annexe B. Algèbre de processus

B.3 Pi-calcul

L'algèbre de processus π− calcul est proposé la première fois en 1993 par RobinMilner[Milner 1999], est un langage de programation simple mais très �exible. Leπ-calcul spéci�e le comportement de processus concurrents, et il joue le rôle dela fondation de la programmation concurente au même titre que le λ-calcul enprogrammation séquentielle. Un programme en π − calcul est un système dont lesprocessus se fonctionnent parallèlement en échangeant entre eux des messages viades canaux, un processus possède d'ensemble propre des canaux sur lesquels il peutenvoyer ou recevoir des messages[Abadi 1998].

La version originale du π − calcul ne possède pas des opérations cryptogra-phiques. Cependant, le π − calcul est très �exible et il permet donc toujoursd'y ajouter des notations modélisant les protocoles cryptographiques. En 1998,M. Abadi et C. Fournet ont étendu la première fois le π − calcul en proposantle spi-calcul [Abadi 1998]. En 2001, ils ont généralisé le spi − calcul en dé�nis-sant le π − calcul appliqué[Abadi 2001], leur nouveau modèle permet de repré-senter les propriétés des primitives cryptographiques (cf. 4.2.1) par des théorieséquationnelles[Baeten 2009, p.11].

Annexe C

Modèles des protocolescryptographiques

Sommaire

C.1 Modèle symbolique . . . . . . . . . . . . . . . . . . . . . . . . 67

C.2 Modèle calculatoire . . . . . . . . . . . . . . . . . . . . . . . . 68

Jusqu'à maintenant, les méthodes formelles de l'analyse des protocoles crypto-graphiques peuvent être classi�ées en deux approches. La première approche reposesur une modélisation symbolique (ou modèle de Dolev-Yao) des exécution duprotocole, les primitives cryptographiques dans cette modélisation sont considéréescomme des boites noires. La deuxième approche repose sur unmodèle calculatoire

qui prend en considération les probabilitées et la complexité algorithmique. Le mo-dèle symbolique présente l'avantage de permettre des preuves de sécurité beaucoupplus simples que dans le modèle calculatoire et souvent automatique. Cependant lemodèle calculatoire permet de dé�nir une notion très forte de sécurité, garantissantn'importe quelles attaques probabilistics et polynomiales[Cortier 2009, p.9].

C.1 Modèle symbolique

Le modèle symbolique1 a été proposé la première fois par D. Dolev et A.Yao[Dolev 1983]. Ce modèle traite les primitives cryptographiques comme des boitesnoires, les messages sont des termes sur les fonctions cryptographiques et l'attaquantest restreint à calculer à l'aide de ces fonctions. Le modèle symbolique propose doncla cryptographique parfaite dans laquelle l'adversaire sais la texte clair dans le mes-sage chi�ré si et seulement s'il possède la clé[Blanchet 2008, p.6].

Pour illustrer l'approche symbolique, on montre un exemple simple d'un pro-tocole cryptographique donné dans [Blanchet 2008, p.3]. Le protocole est unvariant simple du protocole de distribution de clés de Denning-Sacco à clépublique[Denning 1981]. Dans ce protocole, les fonctions cryptographiques asymé-

1Appelé aussi modèle de Dolev-Yao

68 Annexe C. Modèles des protocoles cryptographiques

triques sont dé�nies comme le suivant :

pencrypt(plain, pkey) : plain ∗ pkey → cipher

pdecrypt(cipher, skey) : cipher ∗ skey → plain

sign(plain, skey) : plain ∗ skey → signature

sencrypt(plain, key) : plain ∗ key → cipher

Le protocole se compose de deux participants A et B. Le participant A choisitune clé fraîche (clé de session) k à chaque exécution du protocole. Il signe cetteclé avec sa clé secrète skA, et chi�re le message obtenu avec la clé publique de doninterlocuteur B, et lui envoie le message. Quand il le reçoit, B le déchi�re en utilisantsa clé secrète skB, véri�e la signature de A et obtient la clé k.

A

{{k}skA}pkB //

Bskoo

Fig. C.1: Variant simple du protocole de Denning-Sacco

En utilisant les fonctions cryptographiques dé�nies ci-dessus, on peut représenterle protocole par les équations suivantes :

A→ B : pencrypt(sign(k, skA), pkB)

B → A : sencrypt(s, k)

C.2 Modèle calculatoire

Le modèle calculatoire est dévéloppé au début des années 1980 par Goldwasser,Micali[Goldwasser 1984]. Il permet de raisonner sur des questions de complexitéet de probabilité, car les primitives cryptographiques sont considérées comme desvrais algorithmes et l'intrus y est modélisé comme un algorithme qui peut s'exécutee�cacement[Hördegen 2007, p.10].

Annexe D

Simulateur du botnet Waledac

D.1 Conception du simulateur

A�n de visualiser des activités du botnet Waledac, nous avons développé surTMLinux deux version du simulateur en C++. L'une utilise un thread pour chaquebot du botnet et l'autre sans. Dans le premier cas cela permet le calcul en parallèle,rendant la simulation plus proche de la réalité, chaque bot fonctionnant de manièreindépendante, dans le deuxième cas, les actions des bots sont e�ectuées séquentiel-lement, le ou les actions du bot numeroté 2 sont e�ectuées après le ou les actions dubot 2, ce qui est moins réaliste. Cette deuxième version est utile cependant lorquenous souhaitons lancer la simulation sur un seul processeurs, puisqu'elle nécessitemoins de ressources1.

Le simulateur est impléménté de façon orienté objet. Il se compose de classesdécrits ci-dessous

Classe Bot : Tout les bots de Waledac (spammers, repeaters, attackers, protec-ters, server) dérivent de cette classe.

Classe Spammer : Cette classe implémente les fonctionnalitées d'un bot de typespammeur.

Classe Repeater : Cette classe implémente les fonctionnalitées d'un bot de typerepeateur.

Classe Attacker : Cette classe impléménte les fonctionnalitées d'un bot de typeattaquant. Elle dérive de la classe Repeater (la plupart des attaques sur Wa-ledac se font en introduisant des répéteurs).

Classe Protecter Cette classe implémente les fonctionnalitées d'un bot de typeprotecteur.

ServerCC : Cette classe implémente les fonctionnalitées d'un bot de type serveurde contrôle.

Nous utilisons également des bibliothèques Boost[Boost 2010], Qt[Nokia 2010]et VTK[VTK 2010] (avec support Qt).

La communication simple entre des bots est implémentée par un routage demessages décrit par le �gure D.1. Les bots utilisant la méthode send_message()

pour envoyer un type particulière de message. Les répéteurs et les protecteurs neretransmettent que des messages en utilisant aussi la méthode send_message(). Leserveur manipule ces messages par la méthode process_message().

1nous économisons le changement de contexte e�ectué par le système d'exploitation lorqu'il

bascule d'un thread à l'autre

70 Annexe D. Simulateur du botnet Waledac

Le résultat de chaque méthode est un code représentant l'ordre du serveur decontrôle.

Fig. D.1: Routage de messages

D.2 Expérimentation

Le programme a des paramètres entrés. Par défaut, le simulateur du botnet secompose de 20 répeateurs, 15 protecteurs, 100 spammeurs, et 5 attackers (cf. D.2).

Fig. D.2: Paramètres par défaut

L'architecture hiérarchique de Waledac est visualisée dans la �gure D.3. Lacouche plus haute se compose d'un seul serveur de contrôle. La couche plus basese compose de plusieurs spammeurs. Les activités de Waledac sont simulées par leprogramme. Le simulateur commence avec plusieurs spammeurs : ces spammeurssont représentés par les noeuds rouges, les connections entre les spammeurs sontreprésentées aussi par les lignes rouges, �gure D.4. Nous simulons l'attaque Sybil enajoutant des faux-répéteurs. Lorque la liste de répéteurs d'un spammeur est rempliepar les identités de faux-répéteurs, nous disons que ce répéteur est compromis, etnous le mettons en vert, �gure D.5.

D.2. Expérimentation 71

Fig. D.3: Simulateur de Waledac

Fig. D.4: Le début du simulateur

Fig. D.5: Tous les spammeurs sont compromis

Bibliographie

[Abadi 1998] M. Abadi et A.D. Gordon. A calculus for cryptographic protocols :The spi calculus. Rapport technique SRC-149, Digital Equipment Corpo-ration, System Research Center, Janvier 1998. http://www.hpl.hp.com/

techreports/Compaq-DEC/SRC-RR-149.pdf. 38, 47, 48, 66

[Abadi 1999] M. Abadi. Secrecy by typing in security protocols. Journal of the ACM(JACM), vol. 46, no. 5, pages 749�786, 1999. 56, 57

[Abadi 2000] M. Abadi. Security protocols and their properties. NATO ASI SERIESF COMPUTER AND SYSTEMS SCIENCES, vol. 175, pages 39�60, 2000.44, 47

[Abadi 2001] M. Abadi et C. Fournet. Mobile values, new names, and secure com-munication. ACM SIGPLAN Notices, vol. 36, no. 3, page 115, 2001. 32,66

[Abadi 2005] M. Abadi et B. Blanchet. Analyzing security protocols with secrecytypes and logic programs. Journal of the ACM (JACM), vol. 52, no. 1, page146, 2005. 44, 47, 57

[Allamigeon 2005] X. Allamigeon et B. Blanchet. Reconstruction of attacks againstcryptographic protocols. In 18th IEEE Workshop Computer Security Foun-dations, 2005. CSFW-18 2005, pages 140�154, 2005. 40, 47

[atrocity 2010] atrocity. Les botnets - Comment s'en protéger ?, Mer-credi 2010. http://atrocity.kazeo.com/Tutoriels-DDoS/

Les-botnets-Comment-s-en-proteger,a1883506.html. ix, 5

[Bacher 2005] P. Bacher, T. Holz, M. Kotter et G. Wicherski. Know your enemy :Tracking botnets. The Honeynet Project, 2005. http://www.honeynet.org/papers/bots/. 19

[Baeten 2009] JCM Baeten, T. Basten et MA Reniers. Process algebra : Equationaltheories of communicating processes. Cambridge University Press New York,NY, USA, 2009. 33, 66

[Barthélemy 2005] P. Barthélemy, R. Rolland et P. Véron. Cryptographie : Principeset mises en oeuvre. Hermes Science Publications, 2005. 16

[Blanchet 2001] B. Blanchet et I. Rocquencourt. An e�cient cryptographic protocolveri�er based on Prolog rules. In 14th IEEE Computer Security FoundationsWorkshop, 2001. Proceedings, pages 82�96, 2001. 32, 40, 41, 42, 57, 59

[Blanchet 2005] B. Blanchet. ProVerif automatic cryptographic protocol veri�er usermanual. CNRS, Département dInformatique, Ecole Normale Supérieure, Pa-ris, 2005. 40, 47, 48, 59

[Blanchet 2008] B. Blanchet. Véri�cation automatique de protocoles cryptogra-phiques : modèle formel et modèle calculatoire. Habilitation à Diriger des

http://www.hpl.hp.com/techreports/Compaq-DEC/SRC-RR-149.pdf


http://atrocity.kazeo.com/Tutoriels-DDoS/Les-botnets-Comment-s-en-proteger,a1883506.html

http://atrocity.kazeo.com/Tutoriels-DDoS/Les-botnets-Comment-s-en-proteger,a1883506.html

http://www.honeynet.org/papers/bots/

http://www.honeynet.org/papers/bots/

74 Bibliographie

Recherches. PhD thesis, Ecole Normale Supérieure, Novembre 2008. 27, 28,38, 39, 48, 67

[Bolognesi 1987] T. Bolognesi et E. Brinksma. Introduction to the ISO speci�cationlanguage LOTOS. Computer Networks and ISDN systems, vol. 14, no. 1,pages 25�59, 1987. 65

[Boneh 1999] D. Boneh. Twenty years of attacks on the RSA cryptosystem. Notices-American Mathematical Society, vol. 46, pages 203�213, 1999. 30

[Boost 2010] Boost. Boost C++ Libraries, 2010. http://www.boost.org/. 69

[Botezatu 2008] B. Botezatu. Anatomy of a Botnet, 2008. http://www.

malwarecity.com/blog/anatomy-of-a-botnet-196.html. ix, 4, 5

[Burrows 1990] M. Burrows, M. Abadi et R. Needham. A Logic of authentication.Rapport technique, Digital Systems Research Center, Février 1990. http:

//www.hpl.hp.com/techreports/Compaq-DEC/SRC-RR-39.pdf. 30

[Calvet 2009a] J. Calvet et P. M. Bureau. Analyse en profondeur de Waledac et deson réseau. MISC, vol. 45, Septembre 2009. 9, 12, 14, 18, 23

[Calvet 2009b] J. Calvet et P. M. Bureau. Malware Authors Don't Learn, and That'sGood ! Proceedings of the 4th International Conference on Malicious andUnwanted Software, Octobre 2009. 9

[Cervesato 1999] I. Cervesato, N.A. Durgin, P.D. Lincoln, J.C. Mitchell et A. Sce-drov. A meta-notation for protocol analysis. In Proceedings of the 12thIEEE Computer Security Foundations Workshop�CSFW, volume 99, pages55�69, 1999. 32

[CGI 2002] CGI. Étude technique. Cryptographie à clé publique et signature nu-mérique. Principes de fonctionnement, 2002. www.cgi.com/cgi/pdf/cgi_

whpr_35_pki_f.pdf. 30

[Chiang 2007] K. Chiang et L. Lloyd. A case study of the Rustock rootkit and spambot. In The First Workshop in Understanding Botnets, 2007. 20

[Comon 2002] H. Comon et V. Shmatikov. Is it possible to decide whether a cryp-tographic protocol is secure or not. Journal of Telecommunications and In-formation Technology, vol. 4, no. 2002, pages 5�15, 2002. 21

[Cortier 2003] V. Cortier. Véri�cation automatique des protocoles cryptographiques.PhD thesis, Ecole Normale Supérieure de Cachan, Mars 2003. 32

[Cortier 2005] V. Cortier. Véri�er les protocoles cryptographiques. Technique etScience Informatique, vol. 24, pages 115�140, 2005. 28, 29, 32

[Cortier 2009] V. Cortier. Analyse des protocoles cryptographiques : des modèlessymboliques aux modèles calculatoire. Habilitation à Diriger des Recherches,Novembre 2009. 27, 40, 41, 42, 44, 67

[Daemen 1999] J. Daemen et V. Rijmen. AES proposal : Rijndael. 1999. 15

[DeMillo 1982] R.A. DeMillo, N.A. Lynch et M.J. Merritt. Cryptographic proto-cols. In Proceedings of the fourteenth annual ACM symposium on Theoryof computing, pages 383�400. ACM, 1982. 28

http://www.boost.org/

http://www.malwarecity.com/blog/anatomy-of-a-botnet-196.html

http://www.malwarecity.com/blog/anatomy-of-a-botnet-196.html



www.cgi.com/cgi/pdf/cgi_whpr_35_pki_f.pdf

www.cgi.com/cgi/pdf/cgi_whpr_35_pki_f.pdf

Bibliographie 75

[Denning 1981] D.E. Denning et G.M. Sacco. Timestamps in key distribution pro-tocols. Communications of the ACM, vol. 24, no. 8, pages 533�536, 1981. 21,27, 42, 67

[Desnos 2009] A. Desnos. Implémentation de virus K-aires en Python. MISC,vol. 46, 2009. 20

[Dolev 1983] D. Dolev et A. Yao. On the security of public key protocols. IEEETransactions on information theory, vol. 29, no. 2, pages 198�208, 1983. 40,42, 67

[Douceur 2002] J. Douceur. The Sybil attack. Peer-to-Peer Systems, pages 251�260,2002. 18

[Ducrot 2007] F. Ducrot, M. Danho et X. Marronnier. Les botnets. Sécurité Infor-matique, vol. 61, Octobre 2007. 3

[EFnet 2010] EFnet. Eris Free Network, Octobre 2010. http://www.efnet.org/. 3

[Eggdrop 2008] Eggdrop. Eggdrop, Avril 2008. http://www.eggdrop.fr. 3

[EggHeads 2008] EggHeads. A quoi sert un robot IRC, Avril 2008. http://www.

eggdrop.fr/Introduction_aux_eggdrops. 3

[ENS 2004] ENS. Conception et preuves d'algorithmes cryptographiques, 2004.http://www.di.ens.fr/~wwwgrecc/Enseignement/CoursCryptoMMFAI.

pdf. 30

[Fabrega 1999] F.J.T. Fabrega, J.C. Herzog et J.D. Guttman. Strand spaces : Pro-ving security protocols correct. Journal of computer security, vol. 7, no. 2,pages 191�230, 1999. 32

[Fielding 1999] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leachet T. Berners-Lee. Hypertext Transfer Protocol � HTTP/1.1. RFC 2616(Draft Standard), Juin 1999. Updated by RFCs 2817, 5785. 11

[Filiol 2004] E. Filiol. Strong Cryptography Armoured Computer Viruses ForbiddingCode Analysis : the Bradley virus. Rapport technique RR-5250, INRIA, 2004.20

[Fortier 2005] H. Fortier. La sécurité par l'obsecurité : un concept dangereux, Sep-tembre 2005. 22

[Fraikin 2001] B. Fraikin et Tchoumtchoua J. Présentation de la boîte à outilsCADP : Application au protocole POTS, 2001. ftp://ftp.inrialpes.fr/

pub/vasy/publications/others/Fraikin-Tchoumtchoua-01.pdf. 65

[Garavel 2003] H. Garavel. Défense et illustration des algebres de processus. Actesde l'Ecole d'été Temps Réel, vol. 2003, 2003. 33

[Garey 1979] M.R. Garey et D.S. Johnson. Computers and intractability. a guide tothe theory of np-completeness. a series of books in the mathematical sciences.W. H. Freeman and Company, San Francisco, Calif, 1979. 20

[Germeau 1997] F. Germeau et G. Leduc. Model-based design and veri�cation ofsecurity protocols using LOTOS. Rutgers University, 1997. 65

http://www.efnet.org/

http://www.eggdrop.fr

http://www.eggdrop.fr/Introduction_aux_eggdrops

http://www.eggdrop.fr/Introduction_aux_eggdrops

http://www.di.ens.fr/~wwwgrecc/Enseignement/CoursCryptoMMFAI.pdf

http://www.di.ens.fr/~wwwgrecc/Enseignement/CoursCryptoMMFAI.pdf

ftp://ftp.inrialpes.fr/pub/vasy/publications/others/Fraikin-Tchoumtchoua-01.pdf

ftp://ftp.inrialpes.fr/pub/vasy/publications/others/Fraikin-Tchoumtchoua-01.pdf

76 Bibliographie

[Goldwasser 1984] S. Goldwasser et S. Micali. Probabilistic encryption. Journal ofcomputer and system sciences, vol. 28, no. 2, pages 270�299, 1984. 68

[Hoare 1978] C.A.R. Hoare. Communicating sequential processes. Communicationsof the ACM, vol. 21, no. 8, page 677, 1978. 65

[Hoare 1985] C.A.R. Hoare. Communicating sequential processes. Prentice Hall,1985. http://www.usingcsp.com/cspbook.pdf. 65

[Holz 2008] T. Holz. Other Aspects of Storm Worm, 2008. 20

[Honeynet 2010] Honeynet. The Honeynet Project, 2010. 19

[Hund 2008] R. Hund, M. Hamann et T. Holz. Towards Next-Generation Botnets.In European Conference on Computer Network Defense, 2008. EC2ND 2008,pages 33�40, 2008. 20

[Hördegen 2007] Heinrich Hördegen. Véri�cation des protocoles cryptographiques :Comparaison des modèles symboliques avec une application des résultats �Etude des protocoles récursifs. PhD thesis, Université Henri Poincaré - NancyI, Novembre 2007. 68

[InfectionVectors 2004] InfectionVectors. Agobot and the Kit-chen Sink, Juillet 2004.4

[INRIA 2010] INRIA. Le langage Caml, 2010. http://caml.inria.fr/. 32

[Keizer 2009] G. Keizer. Con�cker cashes in, installs spam bots and scareware,2009. http://www.computerworld.com/s/article/9131380/Conficker_

cashes_in_installs_spam_bots_and_scareware. 10

[Krawczyk 1997] H. Krawczyk, M. Bellare et R. Canetti. HMAC : Keyed-Hashingfor Message Authentication. RFC 2104 (Informational), Février 1997. 30

[Lions 1996] J. L. Lions. Ariane 5 : Flight 501 Failure Report. By the Inquiry Board.Rapport technique, European Space Agency (ESA) et Centre Nationald'Etudes Spatiales (CNES), 1996. http://sunnyday.mit.edu/accidents/

Ariane5accidentreport.html. 26

[Mao 2003] W. Mao. Modern cryptography : theory and practice. Prentice HallProfessional Technical Reference, 2003. 15, 20, 27

[Menezes 1997] A.J. Menezes, P.C. Van Oorschot et S.A. Vanstone. Handbook ofapplied cryptography. CRC, 1997. 15, 16, 29

[Millen 2001] J. Millen et V. Shmatikov. Constraint solving for bounded-processcryptographic protocol analysis. In Proceedings of the 8th ACM Conferenceon Computer and Communications Security, page 175. ACM, 2001. 32

[Milner 1991] R. Milner. The polyadic π-calculus : a tutorial. Logic and Algebra ofSpeci�cation, vol. 94, pages 91�180, 1991. 57

[Milner 1999] R. Milner. Communicating and mobile systems : the π-calculus. Cam-bridge University Press, 1999. 35, 37, 38, 47, 66

[Milner 2001] R. Milner. Bigraphical reactive system : basic theory. Rapport tech-nique 523, University of Cambridge, Computer Laboratory, 2001. 57

http://www.usingcsp.com/cspbook.pdf

http://caml.inria.fr/

http://www.computerworld.com/s/article/9131380/Conficker_cashes_in_installs_spam_bots_and_scareware

http://www.computerworld.com/s/article/9131380/Conficker_cashes_in_installs_spam_bots_and_scareware

http://sunnyday.mit.edu/accidents/Ariane5accidentreport.html

http://sunnyday.mit.edu/accidents/Ariane5accidentreport.html

Bibliographie 77

[Monniaux 2009] D. Monniaux. Analyse statique : de la théorie à la pratique. Ha-bilitation à Diriger des Recherches. PhD thesis, Université Joseph-Fourier -Grenoble I, Juin 2009. 26

[Nachreiner 2008] C. Nachreiner et S. Pinzon. Understanding and Blocking the NewBotnets, Avril 2008. http://www.watchguard.com/docs/whitepaper/wg_

botnet_wp.pdf. 3

[Naoufel 2002] C. Naoufel. Conception, modélisation et simulation de systèmesde production. Notes de cours, 2002. http://lgpp.epfl.ch/webdav/site/

lgpp/shared/Cours/MOSISP/MOSISP-Chap4.pdf. 33

[Needham 1978] R.M. Needham et M.D. Schroeder. Using encryption for authenti-cation in large networks of computers. Communications of the ACM, vol. 21,no. 12, page 999, 1978. 20, 56

[NIST 1999] NIST. Data Encryption Standard. Rapport technique, National Insti-tute of Standards and Technology, Octobre 1999. 15

[NIST 2001] NIST. Advanced Encryption Standard, Novembre 2001. 12, 15

[NIST 2007] NIST. Recommendation for Key Management - Part 1 : General. Rap-port technique, National Institute of Standards and Technology, Mars 2007.15, 30

[Nokia 2010] Nokia. Qt, 2010. http://qt.nokia.com/. 69

[Oikarinen 1993] J. Oikarinen et D. Reed. Internet Relay Chat Protocol. RFC 1459(Experimental), Mai 1993. Updated by RFCs 2810, 2811, 2812, 2813. 3

[O'Neil 2010] S. O'Neil. Skype's Biggest Secret Revealed, 2010. http://www.

enrupt.com/index.php/2010/07/07/skype-biggest-secret-revealed.23

[OpenSSL 2010] OpenSSL. Cryptography and SSL/TLS Toolkit, Janvier 2010.http://www.openssl.org/. 12

[Postel 1981] J. Postel. Transmission Control Protocol. RFC 793 (Standard), Sep-tembre 1981. Updated by RFCs 1122, 3168. 36

[Poulsen 2004] K. Poulsen. FBI busts alleged DDoS Ma�a, 2004. http://www.

securityfocus.com/news/9411. 6

[Rivest 1978] R.L. Rivest, A. Shamir et L. Adleman. A method for obtaining digi-tal signatures and public-key cryptosystems. Communications of the ACM,vol. 21, no. 2, page 126, 1978. 12, 15

[Rivest 1992] R.L. Rivest. The RC4 Encryption Algorithm. Inc., March, vol. 12,1992. 20

[Rusinowitch 2001] M. Rusinowitch et M. Turuani. Protocol insecurity with �nitenumber of sessions is NP-complete. In 14th IEEE Computer Security Foun-dations Workshop, 2001. Proceedings, pages 174�187, 2001. 57

[Ryan 2001] P. Ryan et S.A. Schneider. The modelling and analysis of securityprotocols : the csp approach. Addison-Wesley Professional, 2001. 65

http://www.watchguard.com/docs/whitepaper/wg_botnet_wp.pdf

http://www.watchguard.com/docs/whitepaper/wg_botnet_wp.pdf

http://lgpp.epfl.ch/webdav/site/lgpp/shared/Cours/MOSISP/MOSISP-Chap4.pdf

http://lgpp.epfl.ch/webdav/site/lgpp/shared/Cours/MOSISP/MOSISP-Chap4.pdf

http://qt.nokia.com/

http://www.enrupt.com/index.php/2010/07/07/skype-biggest-secret-revealed

http://www.enrupt.com/index.php/2010/07/07/skype-biggest-secret-revealed

http://www.openssl.org/

http://www.securityfocus.com/news/9411

http://www.securityfocus.com/news/9411

78 Bibliographie

[Salman 2010] A. B. Salman. Know something interesting about Skype ?, 2010.http://www1.cs.columbia.edu/~salman/skype/. 23

[Sarat 2008] S. Sarat et A. Terzis. Measuring the storm worm network, 2008. http://www.cs.jhu.edu/~sarat/storm.pdf. 10

[Schneider 1998] S. Schneider. Verifying authentication protocols in CSP. IEEETransactions on Software Engineering, vol. 24, no. 9, pages 741�758, 1998.32, 65

[Schneier 2001] B. Schneier. Cryptographie appliquée : algorithmes, protocoles etcodes source en c. Vuibert Informatique, 2001. 16

[Seward 2008] Julian Seward. bzip2 and libbzip2, 2008. http://bzip.org/. 14

[Skochinsky 2006] I. Skochinsky. Reversing Microsoft Visual C++ Part II : Classes,Methods and RTTI, 2006. http://www.openrce.org/articles/full_view/23. 11

[Skype 2010] Skype. Skype, 2010. http://www.skype.com/. 22

[Stamford 2002] S. Stamford, V. Paxson et N. Weaver. How to own the internet inyour spare time. In Proceedings of the 11th USENIX Security Symposium,2002. 20

[Stinson 2006] D.R. Stinson. Cryptography : theory and practice. CRC press, 2006.16

[Stock 2009] B. Stock, J. Gobel, M. Engelberth, F.C. Freiling et T. Holz. Walowdac�Analysis of a Peer-to-Peer Botnet. In European Conference on ComputerNetwork Defense, 2009. (EC2ND) 2009, Novembre 2009. ix, 11, 12

[Symantec 2007] Symantec. PrettyPark.Worm, 2007. http://www.symantec.com/

security_response/writeup.jsp?docid=2000-121508-3334-99. 4

[Sysoev 2010] Igor Sysoev. nginx [engine x] a HTTP and reverse proxy server, Août2010. http://nginx.org/. 13

[TechNet 2010] TechNet. Cracking Down on Botnets, Février 2010. 19

[Tenebro 2009] G. Tenebro. Waledac, Part 2 : Its Bootstraps andArmor, 2009. http://www.symantec.com/connect/fr/blogs/

waledac-part-2-its-bootstraps-and-armor. ix, 13

[Trackers 2010] Spam Trackers. Canadian Health and Care Mall, Mai 2010. http://spamtrackers.eu/wiki/index.php/Canadian_Health%26Care_Mall. 10

[UPX 2010] UPX. Ultimate Packer for eXecutables, 2010. http://upx.

sourceforge.net/. 11

[Vogt 2007] R. Vogt, J. Aycock et M. Jacobson. Army of botnets. In Network andDistributed System Security Symposium (NDSS), 2007. 20

[VTK 2010] VTK. VTK - The Visualization Toolkit, 2010. http://www.vtk.org/.69

http://www1.cs.columbia.edu/~salman/skype/

http://www.cs.jhu.edu/~sarat/storm.pdf

http://www.cs.jhu.edu/~sarat/storm.pdf

http://bzip.org/

http://www.openrce.org/articles/full_view/23

http://www.openrce.org/articles/full_view/23

http://www.skype.com/

http://www.symantec.com/security_response/writeup.jsp?docid=2000-121508-3334-99

http://www.symantec.com/security_response/writeup.jsp?docid=2000-121508-3334-99

http://nginx.org/

http://www.symantec.com/connect/fr/blogs/waledac-part-2-its-bootstraps-and-armor

http://www.symantec.com/connect/fr/blogs/waledac-part-2-its-bootstraps-and-armor

http://spamtrackers.eu/wiki/index.php/Canadian_Health%26Care_Mall

http://spamtrackers.eu/wiki/index.php/Canadian_Health%26Care_Mall

http://upx.sourceforge.net/

http://upx.sourceforge.net/

http://www.vtk.org/

Bibliographie 79

[Weidenbach 1999] C. Weidenbach. Towards an automatic analysis of security pro-tocols in �rst-order logic. Automated Deduction CADE-16, pages 70�70,1999. 41

[Wikipédia 2010] Wikipédia. Vol 501 d'Ariane 5, Juin 2010. http://fr.

wikipedia.org/wiki/Vol_501_d'Ariane_5. 26

[Wing 2002] J.M. Wing. FAQ on π-Calculus. Microsoft Research, Décembre 2002.34

[Ylonen 2006a] T. Ylonen et C. Lonvick. The Secure Shell (SSH) AuthenticationProtocol. RFC 4252 (Proposed Standard), Janvier 2006. 33

[Ylonen 2006b] T. Ylonen et C. Lonvick. The Secure Shell (SSH) Protocol Archi-tecture. RFC 4251 (Proposed Standard), Janvier 2006. 33

[Young 1996] A. Young et M. Yung. Cryptovirology : Extortion-based security threatsand countermeasures. In IEEE Symposium on Security and Privacy, pages129�141, 1996. 20

[Young 2004] A. Young et M. Yung. Malicious cryptography : Exposing cryptovi-rology. John Wiley & Sons, 2004. 20

http://fr.wikipedia.org/wiki/Vol_501_d'Ariane_5

http://fr.wikipedia.org/wiki/Vol_501_d'Ariane_5

Index

équivalence observationnelle, 44, 48

abstraction, 33AES, 15algèbre de processus, 32, 33architecture pair-à-pair, 4architecture traditionnelle, 4attaque de l'homme du milieu, 17, 28attaque par rejeu, 30attaque Sybil, 18autorité de certi�cation, 28

BSoD, 26

calcul de processus, 33certi�cate authority, 28chi�rement parfait, 28clé de session, 15clause de Horn, 41Communicating Sequential Processes, 65comportement, 33cryptocounter, 20cryptographie à clé publique, 30cryptographie à clé secrète, 29cryptographie asymétrique, 30cryptographie symétrique, 29cryptographique parfaite, 67cryptovirologie, 20CSP, 65

déductible en un pas, 42DDoS, 6Denning-Sacco, 39, 42discrete event system, 33

faux répéteur, 17

groupe, 34

idéalisation, 33

ingénierie sociale, 10

man-in-the-middle attack, 17modèles de traces, 32monoadic, 56

Needham-Schroeder, 20nginx, 13NP-complet, 20

observation, 33

pi-calcul, 35polyadic, 57primitive cryptographique, 27Processus Séquentiels Communicants, 65propriété de sécurité, 29protecteurs, 13ProVerif, 41

rélations de réaction, 37répéteurs, 12Rambot, 20reni�eur de paquets, 22replay attack, 30RList, 12, 14RSA, 16Rustock, 20

serveur de contrôle, 13signature numérique, 30Skype, 22spam, 6spammeur, 12spi-calcul, 38SSH, 33Storm, 10, 20super-répéteur, 18système à événements discrets, 33système de déduction, 42

Index 81

TCP, 36

virus Bradley, 20

Waledac, 10Walowdac, 11Wide-Mouthed-Frog, 30

Documents

Stage-Ta Thanh Dinh