analyse informatique post-mortem

Transcription

No ORDRE
de la thèse
Thèse
3319
présentée
DEVANT L’UNIVERSITÉ DE RENNES 1
pour obtenir
le grade de : DOCTEUR
DE L’UNIVERSITÉ DE RENNES 1
Mention : INFORMATIQUE
PAR
DUVAL Thomas
Équipe d’accueil (du doctorant)
SUPÉLEC
École Doctorale
Matisse
Composante universitaire (du directeur de thèse)
UFR
SUPÉLEC
avenue de la Boulaie
35511 CESSON-SÉVIGNÉ
TITRE DE LA THÈSE :
“ Analyse informatique post-mortem : mise en œuvre
et évaluation d’une approche bayésienne”
Soutenue le 16 décembre 2005 devant la commission d’examen
Composition du jury :
– Monsieur Ludovic Mé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Supélec
– Monsieur Bernard Jouga . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Supélec
– Monsieur Laurent Roger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . DGA / CELAR
– Madame Solange Ghernaouti-Hélie (rapporteur) . . . . . . . . . . . . . . . . . . . Université de Lausanne
– Monsieur Salem Benferhat (rapporteur) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Université d’Artois
– Monsieur David Billard (rapporteur) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Université de Genève
– Monsieur Bernard Cousin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Université de Rennes 1
ii
Table des matières
Résumé
ix
Remerciements
xi
Introduction
xiii
1 Etat de l’art
1.1 Formalisations du processus d’analyse . . . . . . . . . . . .
1.1.1 Modèle de McKemmish . . . . . . . . . . . . . . .
1.1.2 Formalisations sur l’ensemble du processus . . . . .
1.1.3 Formalisations sur une partie du procesus forensique
1.2 Techniques d’investigation . . . . . . . . . . . . . . . . . .
1.2.1 Techniques d’analyse forensique . . . . . . . . . . .
1.2.2 Outils pour l’analyse forensique . . . . . . . . . . .
1.3 Etat de l’art des systèmes d’aide à la décision . . . . . . . .
1.3.1 Systèmes experts . . . . . . . . . . . . . . . . . . .
1.3.2 Les différents types de moteurs d’inférence . . . . .
1.3.3 Motivations du choix retenu . . . . . . . . . . . . .
1.3.4 Mise en oeuvre des réseaux bayésiens . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
1
3
9
14
14
18
35
35
36
43
43
2 Présentation de notre approche
2.1 Premier exemple trivial . . . . . . . . . . . . . . . .
2.2 Introduction de la notion de plan d’investigation . . .
2.2.1 Modèle général d’une enquête . . . . . . . .
2.2.2 Définition d’un plan d’investigation . . . . .
2.3 Construction d’un plan d’investigation . . . . . . . .
2.3.1 Les variables . . . . . . . . . . . . . . . . .
2.3.2 Construction de la structure . . . . . . . . .
2.3.3 Initialisation des probabilités . . . . . . . . .
2.3.4 Bases de données . . . . . . . . . . . . . . .
2.4 Inférence et exploitation des plans d’investigation . .
2.4.1 Les algorithmes . . . . . . . . . . . . . . . .
2.4.2 Utilisation des résultats finaux de l’enquête .
2.5 Création et analyse de plusieurs plans d’investigation
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
51
51
53
53
55
61
61
61
62
62
65
65
65
66
iii
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
TABLE DES MATIÈRES
iv
2.5.1
2.5.2
2.5.3
Utilité de la variable adresse . . . . . . . . . . . . . . . . . .
Relation entre les plans d’investigation . . . . . . . . . . . .
Apport de la création de plusieurs plans d’investigation au niveau de l’analyse de l’attaquant . . . . . . . . . . . . . . . .
3 Expérimentations
3.1 Description de la plateforme de test . . . . . . . . . . . .
3.1.1 Base de connaissances . . . . . . . . . . . . . . .
3.1.2 Interface Homme-Machine . . . . . . . . . . . . .
3.1.3 Fonctionnalités de la plateforme . . . . . . . . . .
3.2 Exemple sur un cas concret : l’affaire Kevin Mitnick . . .
3.2.1 Introduction . . . . . . . . . . . . . . . . . . . . .
3.2.2 L’enquête assistée par la plateforme XMeta . . . .
3.2.3 Synthèse des résultats obtenus avec XMeta . . . .
3.2.4 Conclusions de l’enquête de Tsutomu Shimomura
3.3 Hacker’s Challenge 1 & 2 . . . . . . . . . . . . . . . . . .
3.3.1 Exemple du challenge numéro 8 . . . . . . . . . .
3.3.2 Exemple du challenge numéro 6 . . . . . . . . . .
3.3.3 Protocole d’expérimentation . . . . . . . . . . . .
3.3.4 Présentation des résultats . . . . . . . . . . . . . .
A La base de vulnérabilités ICAT
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
66
67
68
69
69
70
70
72
72
72
73
76
76
77
77
80
85
86
107
B Construction du réseau
111
B.1 Apprentissage de la structure . . . . . . . . . . . . . . . . . . . . . . 111
B.2 Apprentissage des paramètres . . . . . . . . . . . . . . . . . . . . . . 112
C Le logiciel XMeta
113
C.1 Enregistrement des données . . . . . . . . . . . . . . . . . . . . . . 113
Table des figures
1
Les domaines de l’analyse forensique . . . . . . . . . . . . . . . . .
xx
1.1
1.2
1.3
1.4
1.5
1.6
1.7
1.8
1.9
1.10
1.11
1.12
1.13
1.14
1.15
1.16
1.17
1.18
1.19
1.20
1.21
1.22
1.23
Le processsus forensique vu par Mandia et Procise . . . . . . . . . .
Le cycle de l’analyse selon le projet CTOSE . . . . . . . . . . . . . .
Le modèle de processus du projet CTOSE . . . . . . . . . . . . . . .
Un exemple du langage DFPL . . . . . . . . . . . . . . . . . . . . .
Un exemple de réseau de Petri dans le modèle de Stephenson . . . . .
Un exemple du modèle utilisé par Elsaesser et Tanner . . . . . . . . .
Le processus d’investigation de Kerf . . . . . . . . . . . . . . . . . .
L’arbre de décision de Stallard . . . . . . . . . . . . . . . . . . . . .
Hiérarchie des éléments dans la formalisation de Leigland et Krings .
Résultats produits par les programmes "w", "last" et "lastlog" sous Unix
Exemple d’alertes Snort . . . . . . . . . . . . . . . . . . . . . . . . .
Positionnement d’un pot de miel . . . . . . . . . . . . . . . . . . . .
L’outil Cheops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Envoi d’une copie d’un disque dur via un réseau . . . . . . . . . . . .
Lecture d’une image d’un disque dur sous Linux . . . . . . . . . . .
Autopsy - présentation des images disque analysées . . . . . . . . . .
Autopsy - pattern matching . . . . . . . . . . . . . . . . . . . . . . .
Exemple de réseau de neurones multi-couches . . . . . . . . . . . . .
Exemple de carte de Kohonen . . . . . . . . . . . . . . . . . . . . .
Exemple de réseau de Petri . . . . . . . . . . . . . . . . . . . . . . .
Exemple d’arbre de décision . . . . . . . . . . . . . . . . . . . . . .
Exemple de réseau bayésien . . . . . . . . . . . . . . . . . . . . . .
Sous-ensemble du réseau bayésien de Levitt et Laskey . . . . . . . .
4
5
6
10
11
12
13
15
17
20
25
27
30
33
33
34
34
36
38
38
39
40
49
2.1
2.2
2.3
2.4
2.5
2.6
Un exemple de réseau bayésien . . . . . . . . . . . .
Les quatre questions associées à une enquête . . . . .
La relation entre l’enquêteur et ses outils forensiques
Les flux d’information dans le moteur d’inférences .
L’algorithme de maximum de vraisemblance . . . . .
Un exemple d’arbre d’attaque . . . . . . . . . . . . .
.
.
.
.
.
.
52
54
55
60
63
66
3.1
Structure de l’interface homme-machine XMeta . . . . . . . . . . . .
71
v
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
TABLE DES FIGURES
vi
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
3.10
3.11
3.12
3.13
3.14
3.15
3.16
3.17
3.18
3.19
3.20
3.21
3.22
3.23
Les ordinateurs impliqués dans l’attaque . . . . . . . . . . . . . . . .
Les premiers fichiers d’audit de toad.com . . . . . . . . . . . . . . .
Les fichiers d’audit provenant d’Osiris [Shi95] . . . . . . . . . . . .
Les fichiers d’audit provenant de Rimmon [Shi95] . . . . . . . . . . .
Quelques variables système de Rimmon [Shi95] . . . . . . . . . . . .
L’attaque de Kevin Mitnick : première étape . . . . . . . . . . . . . .
L’attaque de Kevin Mitnick : deuxième étape . . . . . . . . . . . . .
L’attaque de Kevin Mitnick : troisième étape . . . . . . . . . . . . . .
Le premier système compromis de Financialco.net. Les enquêteurs ont
observé une atteinte à l’intégrité du système et une attaque de type
dégradation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Le deuxième système compromis de Financialco.net, les enquêteurs
découvrent que l’attaquant a eu accès à un compte administrateur . . .
Cheminement de l’attaquant en traits pleins et des enquêteurs en traits
pointillés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Challenge 6 : un extrait du code source du site web et SQL . . . . . .
Challenge 6 : requête SQL résultante . . . . . . . . . . . . . . . . . .
Challenge 6 : première analyse avec les observations : perte de confidentialité et perte d’intégrité . . . . . . . . . . . . . . . . . . . . . .
Challenge 6 : deuxième analyse avec l’ajout de l’action message : l’attaquant a envoyé un message à l’administrateur (l’action message n’est
pas visible sur cette figure, nous n’avons laissé que les attaques proposées) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Challenge 6 : troisième analyse après observation de l’attaque bypass
Scores de la plateforme avec contraintes . . . . . . . . . . . . . . . .
Scores de la plateforme avec contraintes . . . . . . . . . . . . . . . .
Temps de calcul (construction et inférence du réseau bayésien) pour
chaque expérience . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tome 1 : rang des attaques en utilisant la base ICAT puis la base ICAT
et la base des enquêtes . . . . . . . . . . . . . . . . . . . . . . . . .
Tome 2 : rang des attaques en utilisant la base ICAT puis la base des
enquêtes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tome 2 : rang des attaques en utilisant la base ICAT puis la base ICAT
et la base des enquêtes . . . . . . . . . . . . . . . . . . . . . . . . .
73
74
74
75
75
77
78
78
80
81
81
82
83
83
84
85
89
90
91
93
94
95
B.1 L’algorithme K2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
C.1 Les principaux objets de l’application XMeta . . . . . . . . . . . . . 114
Liste des tableaux
1
Le processus d’investigation selon le DFRWS . . . . . . . . . . . . .
xxi
1.1
1.2
1.3
1.4
1.5
1.6
1.7
Résumé des formalisations sur la globalité du processus
Résumé des formalisations sur une partie du processus
Synthèse des caractéristiques . . . . . . . . . . . . . .
Récupération des informations système . . . . . . . .
Table de probabilité associée aux nœuds B et D . . . .
Table de probabilité associée au nœud B . . . . . . . .
Synthèse sur les différents moteurs d’inférences . . . .
.
.
.
.
.
.
.
9
14
18
22
40
40
43
2.1
Table des probabilités conditionnelles pour la variable Exploit E et
Usurpation U . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Les variables dégâts loss . . . . . . . . . . . . . . . . . . . . . . . .
Les variables attaques attack . . . . . . . . . . . . . . . . . . . . . .
Les variables action action . . . . . . . . . . . . . . . . . . . . . . .
Les variables techniques d’investigation tech . . . . . . . . . . . . . .
Les différentes interprétations associées à nos types de variables . . .
53
56
58
59
59
64
2.2
2.3
2.4
2.5
2.6
3.1
3.2
3.3
3.4
3.5
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Les attaques analysées dand les tomes 1 et 2 de Hacker’s Challenge .
Quelques statistiques sur les expériences menées sur les contraintes du
réseau bayésien . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Quelques statistiques sur les expériences menées sur les différentes
bases de données . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Les résultats du tome 2 sur les techniques d’investigation . . . . . . .
Les techniques d’investigation utilisées pour le tome 2 . . . . . . . .
vii
87
87
92
96
96
viii
LISTE DES TABLEAUX
Résumé
L’analyse forensique (ou analyse post-mortem) aide les administrateurs système et
les enquêteurs en leur fournissant des outils et des techniques qui leur permettent de
comprendre une attaque informatique, de restaurer un système sain et de trouver le ou
les attaquants. Cette activité est aujourd’hui en grande partie empirique et repose sur
l’expérience des enquêteurs.
Les objectifs de nos travaux sont d’une part de modéliser une enquête informatique
et tout ce qui s’y rapporte (enquêteur, traces informatique, etc.) et d’autre part d’aider
l’enquêteur en mettant en valeur les attaques les plus probables et pour une configuration logicielle donnée, les logiciels les plus vulnérables et les techniques d’investigation
qui permettront de retrouver d’éventuels indices ou preuves.
Les résultats de ces travaux s’adressent dans un premier temps aux chercheurs en
Computer Forensics dont la préoccupation est l’analyse des attaques et la recherche de
la preuve. Ces résultats s’adressent ensuite aux enquêteurs et aux administrateurs qui
ont en charge l’analyse des attaques informatiques.
Nous proposons dans ce mémoire d’utiliser les réseaux bayésiens pour automatiser (sous certaines conditions) les investigations informatiques. Notre modèle, META,
est basé sur la connaissance de l’architecture et de la configuration des systèmes d’information, sur les indices accumulés tout au long de l’enquête et sur les résultats des
enquêtes précédentes. Ces informations sont enregistrées dans une base de données
mise à jour à chaque nouvelle enquête. Cette base de données permet de proposer des
hypothèses pour l’enquête en cours.
L’intérêt de notre méthode est ensuite illustré par la plateforme XMeta où nous
avons effectué l’étude de plusieurs exemples dont une affaire bien connue : l’attaque
du réseau de Tsutomu Shimomura par Kevin Mitnick et des affaires d’intrusions tirées
des ouvrages Hacker’s Challenge.
Ces travaux ont été réalisés dans le laboratoire SSIR de Supélec à Rennes pour
la mise en place du modèle et au CELAR (DGA) pour toutes les expériences sur la
plateforme.
ix
x
RÉSUMÉ
Remerciements
Je tiens à remercier dans un premier temps Laurent Roger et Bernard Jouga pour
m’avoir encadré tout au long de ces trois années de doctorat. Je tiens ensuite à remercier Ludovic Mé (et Gerardo Rubino) pour m’avoir accompagné en tant que directeur
de thèse. J’ai aussi effectué ce travail grâce aux équipes du CELAR/SSI/AMI et de
Supélec qui m’ont permis d’avancer plus rapidement dans mes travaux.
Je voudrais remercier aussi certaines personnes de la DST, de l’IRCGN et du SRPJ
de Rennes avec qui j’ai pu discuter de mes travaux et qui m’ont montré le déroulement
de véritables enquêtes informatiques.
Je tiens à remercier toutes les personnes qui ont lu et relu ce mémoire : en premier
mesdames et messieurs les rapporteurs, Solange Ghernaouti-Hélie, David Billard et Salem Benferhat, ensuite, Bernard Jouga et Laurent Roger pour leur travail de relecture
intense et enfin Éliane et les thésards pour les fautes d’orthographe.
Je finirais mes remerciements par les thésards avec qui j’ai passé de bons moments,
ma famille qui m’a toujours supporté pendant mes longues années d’étudiant et Agnès
pour son aide pour la soutenance.
31 mars 2006
xi
xii
REMERCIEMENTS
Introduction
Les délits informatiques en 2004
Le Clusif (Club de la sécurité des systèmes d’information français) [CLU04] publie un rapport annuel sur la criminalité informatique. Selon cette association, en 2004,
les faits marquants correspondent à 6 principaux types d’attaques. Le premier type
est le vol de données, avec notamment le vol de code source de certaines versions de
Microsoft Windows ou le vol de données client chez Wells Fargo. Le deuxième type
d’attaques correspond à l’utilisation de programmes malveillants ou indésirables. Ces
programmes, comme les adware, les spyware et les keylogger, se multiplient de façon grandissante. Ils s’appuient sur des vulnérabilités connues ou inconnues, comme
par exemple, la faille JPEG [MS04-028] permettant de faire exécuter sans l’accord
de l’utilisateur des programmes de type adware et spyware sur des systèmes Windows
vulnérables. Le troisième type d’attaques correspond aux chantages, extorsions et rackets sur Internet. Les modes opératoires habituellement utilisés sont les suivants :
– l’attaquant a eu accès à des données confidentielles et demande à l’entreprise une
rançon pour de pas divulguer ces informations,
– l’attaquant utilise un logiciel d’attaque pour passer outre certaines fonctionnalités d’un site web (comme pour l’affaire Google1 ),
– l’attaquant utilise des attaques de type DDoS (Distributed Denial of Service) en
utilisant des systèmes zombies.
Le quatrième type d’attaques vise la concurrence : certaines entreprises attaquent d’autres
entreprises soit en les espionnant, soit en portant atteinte à leurs marques, soit en diffusant de fausses informations pour, par exemple, faire chuter une valeur en Bourse
(affaire Belvédère2 ), soit en faisant des attaques par DDoS sur des sites Web. Le cinquième type d’attaques fait référence au terrorisme. Le Clusif souligne que la définition
du cyber terrorisme n’est pas bien établie et que beaucoup de personnes sont en désaccord sur celle-ci. Il y a beaucoup de critères qui peuvent entrer en compte lorsque l’on
parle de cyber terrorisme : en fonction du contexte politique, social, culturel, religieux,
etc., en fonction du but recherché : influence, revendication, répression, conversion,
extermination, nihilisme, etc. Enfin, le sixième type d’attaques vient du déploiement
massif des réseaux sans fil (notamment 802.11 et Bluetooth). Comme ces réseaux sont
de plus en plus présents et qu’ils reposent de plus en plus sur une couche réseau IP, il
est facile pour des attaquants d’accéder à des ressources jusqu’alors cachées au fond
1 http
2 http
://www.zdnet.fr/actualites/internet/0,39020774,39146324,00.htm
://legalis.net/breves-article.php3?id_article=1235
xiii
INTRODUCTION
xiv
d’un réseau. Le Clusif souligne aussi que l’on a vu apparaître en juin 2004 les premiers
virus / vers sur des systèmes de téléphones portables (sur Symbian via Bluetooth).
Selon l’étude de PricewaterhouseCoopers cité dans [Dun06], le fraudeur type serait un homme (à 85%) ayant en moyenne 41 ans et une fois sur deux, cet individu
travaille dans l’entreprise. Ces chiffres proviennent d’un constat des consultants de PricewaterhouseCoopers dans leur dernière analyse de la fraude au sein des entreprises
françaises. Cette étude montre aussi que même si le nombre de délits informatiques a
augmenté, c’est surtout dû à une augmentation de la capacité de détection des entreprises.
Le FBI (Federal Bureau of Investigation) émet lui aussi un rapport annuel sur la
sécurité informatique via le CSI (Computer Security Institute) [FBI04]. Ce rapport est
plus orienté sur les entreprises que celui du Clusif. Il montre que les organisations qui
dépensent le plus pour leur sécurité informatique sont les sociétés de transport, puis
le gouvernement fédéral, puis les sociétés de télécommunications. On peut noter aussi
que le nombre d’utilisations frauduleuses observées sur des systèmes informatiques est
en baisse depuis 2000, ce qui ne veut pas dire que les délits informatiques ont baissé.
Le nombre d’incidents est évalué à maximum 5 par entreprise sur l’année 2004 par la
majorité des personnes qui ont répondu au questionnaire. Les types d’incidents les plus
importants en nombre sont :
1. l’attaque par des virus,
2. l’abus de l’accès au Web3 par des personnes internes à l’entreprise,
3. le vol d’ordinateurs portables.
On peut cependant observer une forte chute des abus d’accès Web et des dénis de
service. Pourtant les dénis de service font perdre beaucoup d’argent aux entreprises
avec 26 millions de dollars pour l’année 2004. En matière de sécurisation, le FBI fait
remarquer que pratiquement la totalité des entreprises utilisent des anti-virus et des
pare-feux et que 82% effectuent des audits de sécurité sur leurs systèmes. Quand un
incident arrive, 91% des entreprises appliquent des patches de sécurité mais 48% ne
préviennent pas les autorités compétentes. La publicité négative qui pourrait en résulter
en est la raison principale.
Quelques exemples de délits informatiques
Voici quelques exemples de délits où l’informatique a eu un rôle prépondérant. Ces
exemples sont tirés d’un article paru dans Law Office Computing [NS02].
Colonel Oliver North
Le colonel Oliver North a été arrêté en 1989 pour avoir été impliqué dans l’affaire iranienne « Contra ». Bien qu’ayant effacé consciencieusement tous les courriers
électroniques pouvant l’accuser, les services de police chargés de l’enquête ont quand
3 utilisation
à des fins personnelles
xv
même pu récupérer ses messages via le système de sauvegarde du réseau, ce qui a
permis de confondre l’accusé.
Agent Robert Hanssen
L’agent Robert Hanssen était un agent du FBI et un espion américain. Il a été
condamné pour espionnage en juillet 2001 car il passait des informations confidentielles aux Russes. Les agents chargés de l’arrêter ont utilisé des techniques standards
comme l’écoute de ses communications téléphoniques personnelles et professionnelles.
Mais ils ont aussi utilisé des techniques propres à l’analyse forensique informatique
comme l’utilisation d’un keylogger sur son ordinateur ou l’analyse de fichiers C et binaires. En effet, Robert Hanssen connaissait la programmation et avait créé un logiciel
permettant l’envoi automatique de données vers ses contacts russes.
Wen Ho Lee
En 2000, le scientifique Wen Ho Lee a été arrêté car il était accusé d’avoir copié
entre 1993 et 1999 des données confidentielles concernant des armes nucléaires. Wen
Ho Lee aurait téléchargé près de 1,4 Go de données sensibles puis les aurait copiés
sur des cassettes pour ensuite les jeter en 1999 à la poubelle. Les cassettes ont été
retrouvées puis analysées plus d’un an plus tard par le FBI mais elles n’ont montré
aucune trace de documents confidentiels. Le 13 septembre 2000, 58 chefs d’accusation
sur 59 ont été supprimés et Wen Ho Lee n’a été condamné qu’aux 9 mois de prison
qu’il venait de faire.
Kevin Mitnick
Kevin Mitnick est l’un des pirates informatiques les plus connus. Il a commencé
ses activités de piratage informatique très jeune en attaquant la compagnie Pacific Bell
pour obtenir gratuitement des appels téléphoniques longue distance. Il a ensuite attaqué
en 1982 le NORAD (North American Aerospace Defense Command). Dans les années
80, il a pris le contrôle de plusieurs centraux téléphoniques à New York et en Californie
et il a ensuite attaqué une nouvelle fois la Pacific Bell en 1991. Mitnick devient alors un
fugitif recherché par le FBI. En 1994-1995, il vole des documents confidentiels à des
entreprises comme Motorola et Sun Microsystem et s’attaque à Tsutomu Shimomura.
Ce dernier entreprend de le traquer jusqu’à son arrestation le 14 février 1995 par le
FBI. Kevin Mitnick utilisait son téléphone portable pour se connecter sur Internet ; il
avait réussi à pirater des centraux téléphoniques de Netcom et de Sprint Cellular pour
utiliser un numéro de téléphone non répertorié dans les bases de données. Cela lui
permettait de rester caché. Ce qui fait de Kevin Mitnick l’un des pirates les plus doués
de sa génération.
INTRODUCTION
xvi
Analyse forensique et aspects légaux
En France
On observe l’augmentation du nombre de délits (et de crimes) où l’utilisation de
l’informatique devient indispensable :
– soit parce que l’équipement en est la cible, dans le cas d’un vol de données
confidentielles, d’utilisation des ressources pour cacher des données, etc.
– soit parce l’équipement permet d’effectuer des actions répréhensibles par la loi
plus facilement et plus discrètement, comme dans les affaires de vente de drogues
ou d’armes (les revendeurs utilisent de plus en plus leur téléphone portable ou
leur PDA pour enregistrer leurs contacts), ou dans les affaires de pédopornographie.
Ces délits, notamment dans les cas où les systèmes sont la cible directe des délinquants, sont répréhensibles au vue de la loi. On trouve dans le code pénal4 les articles
323-1 à 323-3 du 19 septembre 2000 :
Article 323-1
Le fait d’accéder ou de se maintenir, frauduleusement, dans tout ou partie
d’un système de traitement automatisé de données est puni de deux ans
d’emprisonnement et de 30 000 euros d’amende. Lorsqu’il en est résulté
soit la suppression ou la modification de données contenues dans le système, soit une altération du fonctionnement de ce système, la peine est de
trois ans d’emprisonnement et de 45 000 euros d’amende.
Article 323-2
Le fait d’entraver ou de fausser le fonctionnement d’un système de traitement automatisé de données est puni de cinq ans d’emprisonnement et de
75 000 euros d’amende.
Article 323-3
Le fait d’introduire frauduleusement des données dans un système de traitement automatisé ou de supprimer ou de modifier frauduleusement les
données qu’il contient est puni de cinq ans d’emprisonnement et de 75 000
euros d’amende.
La loi du 6 janvier 1978 modifiée le 6 août 2004 relative à l’informatique, aux
fichiers et aux libertés5 protège les personnes et les informations enregistrées sur les
systèmes informatiques. Cette loi contient 72 articles qui décrivent comment des informations personnelles, enregistrées par des entreprises ou des particuliers doivent être
collectées, traitées, conservées et supprimées. Les infractions à cette loi sont réprimées
par les articles 226-16 à 24 du code Pénal. Cette loi est à double tranchant. Elle protège
les citoyens contre l’utilisation illégale de leurs données, mais elle est aussi contraignante pour les enquêteurs et les administrateurs système. Les données personnelles
comme par exemple les courriers électroniques, les conversations par IRC (Internet
4 http://www.legifrance.gouv.fr/
5 http://www.cnil.fr/
xvii
Relay Chat), etc., ne peuvent être lus que par leur propriétaire ou des personnes assermentées. Un administrateur réseau a le droit d’enregistrer ces données, mais il doit en
informer la CNIL et les utilisateurs de son système ; une charte informatique, signée par
les deux partis, doit mentionner cet enregistrement. Du point de vue de la loi, si l’administrateur n’a pas respecté ces règles, non seulement les preuves seront irrecevables,
mais en plus il pourra être poursuivi.
D’autre part, en ce qui concerne la pédopornographie, les mineurs sont protégés
des abus et des violences sexuelles par la loi du 17 juin 1998 relative à la prévention
et à la répression des infractions sexuelles ainsi qu’à la protection des mineurs6 . Cette
loi stipule notamment que la corruption, le viol et la violence sur mineurs sont des
actes répréhensibles par la loi et que chaque individu qui réalise ces actes est passible
de la prison et d’une forte amende. Il fera aussi l’objet d’un suivi sociojudiciaire sous
le contrôle du juge de l’application des peines. Ce fléau est un problème important et
récurrent pour toutes les forces de police dans le monde. En France, cela représente
près de 80% des délits et crimes liés à l’informatique analysés par les forces de police
et de gendarmerie (source IRCGN).
Depuis le 13 mars 2000, l’écrit sous forme électronique est aussi recevable que
l’écrit sur support papier (Loi n◦ 2000-230) à la condition que ces informations soient
bien conservées et identifiées :
Article 1316-1 du Code Civil
L’écrit sous forme électronique est admis en preuve au même titre que
l’écrit sur support papier, sous réserve que puisse être dûment identifiée la
personne dont il émane et qu’il soit établi et conservé dans des conditions
de nature à en garantir l’intégrité.
Ceci signifie qu’un enquêteur peut utiliser des fichiers d’audit, des messages électroniques, etc., comme preuves devant une cour de justice si ces preuves ont été récupérées dans la forme qui convient (avec l’aide par exemple d’un huissier de justice ou
d’une personne assermentée).
En France, les organismes spécialisés dans la collecte et le traitement des données
numériques sont :
OCLCTIC : (Office Central de Lutte contre la Criminalité liée aux Technologies de
l’Information et de la Communication). Il appartient à la Direction Centrale de
la Police Judiciaire et travaille à l’analyse de délits informatiques, l’assistance
technique pour les forces de police, la formation d’autres services de police et la
communication internationale (Europol, Interpol, G8).
BEFTI : (Brigade d’Enquête sur les Fraudes aux Technologies de l’Information). Elle
travaille essentiellement sur Paris et la petite couronne et appartient à la police
judiciaire.
SRPJ : (Services Régionaux de Police Judiciaire). Il existe 19 services dans les grandes
villes de province qui possèdent chacun au moins un Enquêteur Spécialisé en
Criminalité Informatique (ESCI).
6 https://www.internet-mineurs.gouv.fr/
xviii
INTRODUCTION
DST : (Direction de la Surveillance du Territoire). La DST dépend du Ministère de
l’Intérieur, elle a pour objectif (au niveau des délits informatiques) d’analyser les
délits les plus importants, notamment ceux qui concernent les grandes entreprises
françaises.
CERTA : (Computer Emergencing Response Team Administration). Le CERTA dépend des services du Premier Ministre et analyse les nouvelles vulnérabilités
ainsi que les attaques informatiques sur les réseaux des administrations françaises.
IRCGN : (Institut de Recherche Criminelle de la Gendarmerie Nationale). L’IRCGN
a pour objectif principal d’analyser les crimes de type pédopornographie.
Aux Etats Unis
L’administration judiciaire américaine est très différente de son homologue française. Cela s’explique par le fait que les Etats Unis ont une étendue géographique très
importante par rapport à la France. L’appareil judiciaire est donc divisé en de nombreuses entités, d’une part l’appareil fédéral qui regroupe tous les états, divisé en de
multiples unités géographiques et d’autre part une organisation judiciaire propre à
chaque état. Chacun de ces appareils est structuré en forme de pyramide, avec à la
base les tribunaux d’instance fédéraux et locaux et au sommet la Cour suprême des
États-Unis au niveau fédéral et la Cour suprême de l’Etat au niveau local. Au niveau
des enquêtes sur le terrain, ce sont, la plupart du temps, les "sheriffs" qui enquêtent sur
les délits informatiques, aidés au besoin par des enquêteurs du FBI lorsque l’enquête
est trop importante où lorsque l’étendue géographique du délit dépasse les frontières de
l’état. Le FBI peut aussi être appelé directement, par exemple dans les cas où l’affaire
concerne une entreprise qui s’étend sur plusieurs états voire sur plusieurs pays.
Intercontinentalité
L’un des problèmes majeurs en forensic est que la plupart des affaires sont transfrontalières ou transcontinentales. Les polices de chaque pays doivent se coordonner
pour pouvoir retrouver et arrêter les délinquants. Mais chaque pays a ses propres lois,
plus ou moins incompatibles entre elles. C’est à partir de cette constatation qu’a été
signée la Convention Européenne contre la cybercriminalité7 , le 23 décembre 2001
à Budapest par 29 pays européens (dont la France) plus les Etats Unis d’Amérique, le
Japon, le Canada et l’Afrique du Sud. Cette convention veut créer un « droit international fondateur et respectueux des droits de l’homme »8 . Cette convention n’est pas
une directive européenne, ce n’est pas non plus un nouveau droit international, mais il
s’agit de permettre une collaboration entre les états pour retrouver et arrêter les délinquants informatiques plus facilement et plus rapidement. Malheureusement, bien que
cette convention ait été signée par tous les états présents, seuls 10 d’entre eux l’ont
7 http://conventions.coe.int/Treaty/Commun/QueVoulezVous.asp?NT=
185&CM=1&DF=&CL=FRE
8 http://nicolas.chazot.free.fr/main.php?page=.%2Fcybercon
xix
ratifiée (Albanie, Bulgarie, Chypre, Croatie, Estonie, Hongrie, l’ex-République Yougoslave de Macédoine, Lituanie, Roumanie, Slovénie).
Il existe aussi plusieurs organismes privés de dimension internationale dont le but
principal est le recouvrement de données, notamment :
IBAS : http://www.ibas.com. Ibas est une société privée initialement norvégienne, qui possèdent de nombreuses filiales de part le monde.
Ontrack : http://www.ontrack.fr/. Comme Ibas, Ontrack est une société privée dont l’activité essentielle est le recouvrement de données.
Définitions
Voici quelques définitions des termes que nous allons utiliser tout au long de ce
mémoire :
hacker (un) : un hacker9 est un spécialiste en informatique, généralement il crée des
programmes ou des scripts. Le hacker n’effectue pas forcément des actions qui
vont à l’encontre des lois. Ce terme est totalement différent des termes délinquant
et pirate informatique. Ici, le terme « hacker » n’a pas la connotation péjorative
que l’on trouve dans la presse.
délinquant informatique (un) : c’est une personne qui utilise un système informatique (via éventuellement le sien) pour commettre des actions répréhensibles par
la loi (intrusion, pédopornographie, etc.).
pirate informatique (un) : c’est une personne qui utilise un système informatique
(via éventuellement le sien) pour s’introduire illégalement dans des systèmes
informatiques. Ce système informatique peut être soit la cible de l’attaque soit
un moyen pour commettre le délit.
délit / crime informatique (un) : c’est un délit ou un crime où un ou plusieurs systèmes informatiques sont utilisés soit parce que ces systèmes étaient la cible
finale, soit parce que ces systèmes ont été utilisés pour atteindre un autre objectif
qui est lui-même répréhensible par la loi.
enquêteur (un) : un enquêteur est une personne assermentée, capable d’analyser des
attaques informatiques ou des systèmes informatiques ayant été utilisés pour un
crime ou un délit.
trace numérique (une) : dans tout ce mémoire, une trace numérique sera toute information sous forme électronique laissée par le délinquant : nouveau fichier, ajout
/ suppression d’information dans un fichier, etc. Il s’agit de données brute avant
toute transformation.
Enfin, nous proposons une définition de l’analyse criminelle informatique, terme que
nous utilisons pour traduire le terme anglais : forensic analysis. Cette définition s’inspire de celle du DFRWS (Digital Forensic Research Workshop) communauté d’experts
en analyse forensique. La communauté se réunit tous les ans (à la Nouvelle Orléans
9 en
anglais, le sens premier de to hack est taper (sur un clavier par exemple)
INTRODUCTION
xx
F IG . 1 – Les domaines de l’analyse forensique
en 2005). Les participants ont édité un rapport sur l’analyse forensique qui fait aujourd’hui référence [Pal01]. Ce rapport décrit les discussions qui ont eu lieu entre les
scientifiques et les utilisateurs, avec les objectifs de définir une méthodologie pour le
computer forensics, de définir ce qu’est une preuve numérique, de préciser les enjeux
de la détection et de la récupération des données cachées, et enfin de décrire l’analyse
forensique dans un environnement réseau.
Comme le montre la figure 1, la recherche en analyse forensique est à l’intersection
de trois domaines : le judiciaire, le militaire et le monde économique, ce qui en fait un
sujet très complexe avec de multiples extensions.
Le DFRWS propose la définition suivante du terme Forensic analysis :
The use of scientifically derived and proven methods toward the preservation, collection, validation, identification, analysis, interpretation, documentation and presentation of digital evidence derived from digital sources
for the purpose of facilitating or furthering the reconstruction of events
found to be criminal, or helping to anticipate unauthorized actions shown
to be disruptive to planned operations.
Le DFRWS propose donc une définition qui s’articule autour de trois points essentiels.
Il y a d’abord référence à l’utilisation de méthodes à la fois scientifiques et prouvées,
xxi
Identification
Event/Crime
Detection
Resolve Signature
Preservation
Case Management
Imaging
Technologies
Chain of
Custody
Time
Synch
Collection
Examination Analysis
Presentation
Decision
Preservation Preservation Preservation Documentation
Approved
Methods
Traceability
Traceability Expert Testimony
Approved
Software
Approved
Hardware
Validation
Techniques
Filtering
Techniques
Statistical
Clarification
Protocols
Complaints
Legal Authority
Pattern
Matching
Data
Mining
System
Monitoring
Lossless
Compression
Sampling
Hidden
Data Discovery
Hidden
Data Extraction
Timeline
Mission
Impact Statement
Recommended
Countermeasure
Statistical Interpretation
Profile Detection
Anomalous
Detection
Audit Analysis
Etc.
Data
Reduction
Recovery
Techniques
Link
Spacial
TAB . 1 – Le processus d’investigation selon le DFRWS
ce qui implique notamment que les enquêteurs pourront faire confiance à ces méthodes
s’ils les appliquent correctement. La définition mentionne aussi les huit étapes qui permettent l’analyse des traces numériques, de la préservation des données jusqu’à la présentation des résultats de l’enquête. Enfin, le DFRWS présente les objectifs de l’analyse
forensique : la compréhension des faits délictueux et la prévention contre des actions
malicieuses.
D’autre part, les participants ont construit un tableau représentant le processus d’investigation (cf TAB. 1). Ce tableau donne les principales étapes du processus : Identification, Preservation, Collection, Examination, Analysis, Presentation, Decision et
les mots-clé associés à ces étapes. Nous allons retrouver ces étapes dans la plupart des
travaux décrits dans la suite de ce mémoire.
Enfin, le DFRWS liste les 9 compétences, qui doivent être mobilisées :
– l’analyse de données,
– les langages et la linguistique,
– la logique,
– les statistiques,
INTRODUCTION
xxii
–
–
–
–
–
le traitement du signal (Signal processing),
l’analyse des images de disque (Image Analysis),
la cryptographie,
la conservation des preuves,
les technologies réseau.
Les problèmes de l’analyse criminelle informatique
Les spécialistes doivent faire face à de nombreux problèmes pour retrouver des
éléments de preuves et les délinquants. Dans un premier temps, l’enquêteur ne peut
pas connaître tous les systèmes d’exploitation existants. De nombreux systèmes hétéroclites ont été créés, souvent sur des bases communes pour les stations de travail et
les serveurs (Unix/Linux, BSD, Windows, etc.) mais ces systèmes restent néanmoins
très différents. Il existe aussi d’autres systèmes d’exploitation tout aussi hétéroclites
pour les routeurs, les assistants personnels numériques et pour les téléphones. Certains
systèmes d’exploitation (comme Windows et Linux) sont plus utilisés que d’autres ,
les enquêteurs doivent alors faire face à la diversité des versions et / ou des patches
appliqués à chacun de ces systèmes. De même, un certain nombre de logiciels sont
installés sur ces systèmes, la diversité de ces logiciels (et de leurs versions) est encore
plus importante que celle des systèmes d’exploitation. Un enquêteur ne peut donc pas
connaître tous ces logiciels, cela influe sur la connaissance des attaques utilisables sur
chaque logiciel et sur les moyens de trouver des informations capitales concernant l’enquête. Les vulnérabilités jamais publiées font aussi partie du problème puisque seul le
ou les attaquants connaissent ces vulnérabilités.
Aujourd’hui dans les enquêtes informatiques, la description des investigations est
faite de façon personnelle par chaque enquêteur, c’est-à-dire que les enquêteurs n’utilisent pas de nomenclature précise et systématique des attaques et des techniques d’investigation utilisées au cours de l’enquête.
Puisque cette nomenclature n’existe pas, il ne peut pas y avoir de transmission
systématique et précise du dossier de l’enquête et du savoir des enquêteurs à d’autres
personnes. Les nouvelles informations apprises par l’enquêteur ne sont pas systématiquement communiquées et réutilisées.
Le cadre et les objectifs de la thèse
Nos travaux ont comme objectif de fournir une assistance à l’analyse des attaques
informatiques perpétrées par des humains ou des automates (vers informatiques) quand
il y a atteinte à la confidentialité (vol de données), à l’intégrité (par exemple défigurement de site Web), disponibilité (déni de service) ou pénétration illégale dans un système d’information. Nous n’analyserons pas les délits où le système d’information n’a
pas joué un rôle prépondérant dans le délit10 ou si le système d’information a permis
d’obtenir une preuve indirect11 , sauf si il y a eu effectivement intrusion non autorisée
10 dans le cas, par exemple, où un trafiquant de drogue a enregistré ses contacts sur son ordinateur ou son
PDA ou dans les cas de pédopornographie
11 par exemple l’utilisation d’un système informatique qui permet de montrer que l’accusé était effectivement chez lui au moment d’un meurtre
xxiii
dans le système.
Nos travaux ont pour objectifs de répondre aux problèmes énoncés ci-dessus, c’està-dire aider l’enquêteur sur :
– la diversité des systèmes d’exploitation et de leurs logiciels,
– la diversité et la complexité des attaques possible pour chaque logiciel,
– la présentation de techniques d’investigation utilisable permettant de retrouver
des éléments de preuves sur l’attaque.
La plateforme logicielle résultante sera capable de proposer des solutions pour des vulnérabilités inconnues et de conserver les résultats pour des utilisations futures (rapports,
étude de nouvelles attaques similaires, etc.).
Nous proposons donc de construire un système d’aide à la décision. Ce système
va reposer sur le formalisme des systèmes expert. Le système utilisera une base de
connaissance qui représentera la connaissance des enquêteurs et un moteur d’inférences
qui permettra d’une part l’analyse de la base de connaissance et d’autre part la présentation de pistes éventuelles aux enquêteurs. Nous proposons un modèle du processus
d’investigation basé sur la description de la configuration des systèmes et la liste des
attaques potentielles et des techniques d’investigation.
Les contributions de ces travaux sont les suivantes :
– l’application de l’inférences bayésienne à des enquêtes criminelles informatiques,
– la semi-automatisation du processus d’enquête,
– la création, l’analyse et le re-formatage de base de données spécialisées dans les
enquêtes informatiques,
– la nomenclature systématique des attaques et des techniques d’investigation,
– l’apprentissage des résultats d’enquêtes précédentes,
– la conception et le développement d’un démonstrateur.
Organisation de ce mémoire
Ce mémoire est organisé en trois parties :
Dans la première partie, nous exposons un état de l’art de l’analyse forensique au
niveau théorique et au niveau pratique. Nous analysons pour commencer différents
formalismes proposés dans la littérature. Puis nous continuons par la description d’un
certain nombre de techniques et d’outils utiles aux enquêtes informatiques. Enfin, nous
analysons les différents types de moteurs d’inférences envisageables et nous décrivons
plus précisément celui que nous avons choisi.
Dans la deuxième partie, nous exposons notre contribution en commençant par
montrer pourquoi le moteur que nous avons retenu répond à nos besoins. Ensuite, nous
décrivons notre modèle du processus d’investigation, en introduisant notamment la notion de plan d’investigation, puis nous présentons comment ce modèle est construit et
exploité.
Dans la dernière partie, nous décrirons la plateforme logicielle et les expérimentations que nous avons menées pour évaluer notre modèle.
xxiv
INTRODUCTION
Chapitre 1
Etat de l’art de l’analyse
forensique informatique
Ce chapitre a pour objectif de présenter l’analyse forensique informatique, aussi
bien au niveau théorique que pratique. Pour cela, nous avons divisé ce chapitre en
trois parties, la première (1.1) est un état de l’art des formalisations et des méthodes
pour l’analyse forensique. La deuxième partie (1.2) présente les principales techniques
utilisables par les enquêteurs informatiques. Enfin, la troisième partie (1.3) est une
analyse des systèmes d’aide à la décision et des moteurs d’inférences potentiellement
utilisables pour nos travaux.
1.1 Formalisations du processus d’analyse
1.1.1 Modèle de McKemmish
Il existe plusieurs modèles associés à l’analyse forensique. L’un des premiers, le
modèle de McKemmish [McK99], est intéressant car il est assez complet et général et
de plus beaucoup de modèles postérieurs lui font référence.
McKemmish propose de décomposer l’étude de l’attaque d’un système informatique en 4 étapes simples :
1. Identification : la première démarche est d’identifier les éléments qui peuvent potentiellement contenir des indices et des preuves. Cela permet de déterminer les
outils qui devront être utilisés pendant la phase d’analyse. McKemmish insiste
sur le fait que ce sont non seulement les ordinateurs qui doivent être analysés,
mais aussi tous les équipements qui ont des capacités de stockage, comme les
assistants personnels (PDA), les téléphones portables et les supports amovibles.
2. Préservation : McKemmish décrit cette phase comme étant une phase critique
du processus. C’est cette phase qui ; lors d’un procès, rend le processus valide
ou non. En effet, si l’une des pièces à conviction présentée par l’une des parties a été altérée d’une manière ou d’une d’autre, elle devient irrecevable devant
1
2
CHAPITRE 1. ETAT DE L’ART
une cour de justice. McKemmish souligne cependant que certaines modifications sont inévitables. Dans ce cas, les enquêteurs doivent expliquer quels sont
les changements et pourquoi ils ont lieu.
3. Analyse : c’est la phase principale du processus. Son objectif est de transformer
les données brutes dans une forme compréhensible par toute personne impliquée
dans l’enquête (enquêteur, juriste, etc.).
4. Présentation : après l’enquête, il faut être capable de présenter les résultats à des
personnes pas forcément spécialistes du domaine.
McKemmish liste ensuite les trois disciplines essentielles de l’analyse forensique.
Cela débute par l’analyse des média et des systèmes. Les média peuvent être de plusieurs sortes : les média ré-inscriptibles comme les disquettes, les mémoires flash,
etc., et les média non-ré-inscriptibles comme les CD-Rom. Les systèmes informatiques
peuvent être non seulement des ordinateurs mais aussi d’autres équipements, comme
les téléphones portables ou les assistants personnels (PDA). La discipline est très large
et fait appel à des compétences en ingénierie logicielle, en électronique, en cryptographie et en réseaux. La deuxième discipline est l’analyse des communications, qui
regroupe les activités d’analyse des flux réseaux, des intrusions, et l’interception de
données. La dernière discipline est la recherche et le développement, essentiel pour ne
pas être dépassé par les avancées de la technologie et les progrès des délinquants.
McKemmish décrit aussi les quatre règles principales qui doivent être respectées
par un logiciel d’analyse forensique pour que les résultats produits puissent être recevables.
Règle 1 : Une modification minimale des données originales ; il faut donc faire une (ou
plusieurs) copie(s) du contenu des média concernés avant de les analyser. Cela
permet aussi de travailler à plusieurs sur le même support et de garder l’original
intact comme pièce à conviction.
Règle 2 : La documentation de tout changement intervenu pendant l’analyse. Si la
modification du médium original ou de la copie est inévitable, l’analyste doit
être capable d’expliquer pourquoi cette modification est inévitable et quelles en
sont les conséquences sur le médium du point de vue logiciel ou physique.
Règle 3 : Le respect des règles de bon usage des outils pour ne pas corrompre l’ensemble de l’analyse et pour ne pas modifier la signification des données.
Règle 4 : Ne pas surestimer ses connaissances et ses capacités. Si l’analyse est au delà
des compétences de l’enquêteur, il faudra alors soit qu’il se mette à niveau, soit
qu’il se fasse assister.
Enfin, McKemmish souligne quelques problèmes émergeants (en 1999) qui doivent
être résolus. Selon lui, il y en a quatre. Le premier est la diversité des systèmes d’exploitation et leur taille grandissante. Un enquêteur ne peut connaître tous les environnements. De plus, la propriété "plug-and-play" de certains systèmes rend la règle
numéro 1 énoncée ci-dessus très difficile à respecter. Le deuxième problème vient du
volume de plus en plus important de données à conserver puis à traiter. Le troisième
problème vient de la multiplication des équipements ayant des capacités de stockage
et qui peuvent servir à sauvegarder des données sensibles. Le dernier problème vient
du chiffrement des données, aussi bien pour leur stockage que pour leur transport, qui
1.1. FORMALISATIONS DU PROCESSUS D’ANALYSE
3
oblige les enquêteurs à utiliser des techniques de décryptage (attaque par dictionnaire,
attaque par force brute, etc.).
Notre contribution se situe au niveau des phases 3 et 4 du modèle de McKemmish,
en assistant les enquêteurs dans leurs analyses et en leur proposant des hypothèses pour
trouver des indices et des preuves. Notre proposition est aussi capable de modéliser
l’enquête en cours, en sauvegardant le mode opératoire de l’attaque ainsi que celui de
l’enquête.
Notre approche respecte la règle numéro deux de McKemmish en obligeant l’enquêteur à documenter ses investigations de manière détaillée puisque toutes les actions
de l’enquêteurs seront enregistrées par notre approche.
Enfin, notre solution pourra aider les enquêteurs dans deux des problèmes évoqués par McKemmish, la diversité des systèmes d’exploitation et la multiplication des
équipements, en intégrant des données sur les vulnérabilités d’un grand nombre de
plateformes et de configurations.
1.1.2 Formalisations sur l’ensemble du processus
Dans cette partie, nous présentons les modèles qui couvrent toutes les étapes du
processus, en commençant par les travaux les plus anciens.
1.1.2.1 Le processus de Mandia et Procise
Dans [MP01], Mandia et Procise proposent une méthodologie reposant sur l’arbre
de décision reproduit en figure 1.1. Cet arbre se compose des éléments suivants :
1. Pre-incident preparation : cela correspond à l’entraînement et à la vérification
du matériel ;
2. Detection of incident : l’alerte initiale ;
3. Initial response : étude des données volatiles pour confirmer ou non l’incident ;
4. Response strategy formulation : utiliser les données déjà collectées pour élaborer
une stratégie d’investigation ;
5. Duplication (forensic backup) : faire une copie de tous les média pour des analyses ultérieures ;
6. Investigation : l’enquête en elle-même sur le ou les systèmes compromis ;
7. Security measure implementation : l’application de mesures de sécurité pour que
l’incident ne se reproduise pas pendant l’enquête ;
8. Network monitoring : l’investigation sur le réseau ;
9. Recovery : la restauration des systèmes compromis à leur état initial en les sécurisant ;
10. Reporting : la documentation de toutes les étapes de l’enquête ;
11. Follow-up : le debriefing des enquêteurs.
Sur la figure 1.1, on peut observer que le processus de Mandia et Procise est très linéaire, notamment en ce qui concerne les investigations sur les systèmes puis sur le
4
F IG . 1.1 – Le processsus forensique vu par Mandia et Procise
5
F IG . 1.2 – Le cycle de l’analyse selon le projet CTOSE
réseau, ce qui n’est pas forcément conforme à la réalité de la chronologie des opérations.
Notre proposition s’inspire cependant en partie des travaux présentés ci-dessus.
Dans le processus de Mandia et Procise, notre solution pourrait être utilisée dans les
phases 4, 5, 6, 8 et 10, car elle permet à la fois d’analyser les traces et le système
compromis mais aussi de documenter cette analyse.
1.1.2.2 CTOSE
Le projet CTOSE (Cyber Tools On-line Search for Evidence) [Con03] a pour but
de développer une méthodologie, une architecture, un modèle et une suite d’outils pour
aider les enquêteurs dans leurs investigations informatiques. C’est un projet européen,
avec des partenaires dans le monde entier. Il a pour objectif de permettre l’échange
d’informations cruciales entre les personnes qui doivent analyser des délits impliquant
des équipements informatiques et électroniques. Le projet CTOSE permet de récolter,
analyser, sécuriser, sauvegarder et présenter des pièces à conviction qui peuvent être
recevables devant une cour de justice. Les principaux résultats produits sont :
– CTOSE methodology model : Un cycle en 5 étapes a été défini (cf. F IG . 1.2) :
→ Forensic Readiness phase : c’est la phase de préparation des enquêteurs ;
→ Running phase : c’est la phase d’attente d’incidents ;
→ Awareness phase : c’est le moment où une personne (administrateur, utilisateur, enquêteur, etc.) a detecté un incident ;
→ Investigation phase : c’est l’enquête en elle-même ;
6
F IG . 1.3 – Le modèle de processus du projet CTOSE
→ Learning phase : c’est le debriefing de l’incident.
– Legal Advisor : c’est un outil qui donne des conseils à l’enquêteur sur la recevabilité des preuves ainsi que sur leur légalité.
– Process Model : ce modèle (cf. F IG . 1.3) décrit les actions que les enquêteurs
doivent effectuer en cas d’incident.
– C*CAT - Cyber Crime Advisory Tool : c’est un outil constitué d’une base de
données. Il permet aux utilisateurs de questionner le modèle de processus sur les
actions à effectuer.
– Forensic Readiness Guidelines : c’est un guide permettant aux entreprises de se
préparer pour les attaques futures. Ce guide décrit notamment comment récupérer et conserver des fichiers d’audit.
– Forensic Autopsy Tool with XML bindings : c’est un outil qui permet de sauvegarder des résultats d’enquête.
– CTOSE Demonstrator : c’est une plateforme de démonstration qui permet de
montrer l’utilité des outils cités ci-dessus.
– Project Story board : c’est un scénario qui présente tous les aspects du projet
CTOSE.
1.1.2.3 The Enhanced Digital Investigation Process Model
Dans [BT04], Baryamureeba et Tushabe proposent un modèle pour les investigations informatiques, inspiré du modèle de Brian Carrier et Eugene Spafford décrit dans
[ES03]. Le modèle de Carrier et Spafford, IDIP (Integrated Digital Investigation Process), contient 17 phases regroupées dans les étapes suivantes :
1. Readiness Phases : ce sont les phases où l’enquêteur vérifie qu’il est prêt à effectuer une enquête, cela inclue la vérification des équipements ainsi que l’entrainement de l’enquêteur ;
7
2. Deployment Phases : cela correspond à l’arrivée sur les lieux de l’incident et aux
premières observations faites par les enquêteurs ;
3. Physical Crime Scene Investigation Phases : les objectifs de ces phases sont
de récolter toutes les preuves physiques potentielles (disques durs, disquettes,
etc.) pour les analyser ensuite, l’objectif étant aussi de préserver ces pièces à
conviction ;
4. Digital Crime Scene Investigation Phases : l’objectif de ces phases est d’analyser
les éléments récoltés pour tenter de comprendre ce qui s’est passé ;
5. Review Phase : cette phase correspond au debriefing.
Baryamureeba et Tushabe pensent que ce modèle n’est pas utilisable en pratique. Premièrement, les phases Physical Crime Scene Investigation et Digital Crime Scene Investigation sont trop indépendantes. Lorsque des enquêteurs arrivent sur les lieux d’un
crime, ils ne peuvent pas savoir si leurs investigations vont débuter par des observations
d’éléments physiques ou numériques. Deuxièmement, le modèle IDIP n’est pas assez
précis. Notamment il ne distingue pas l’enquête sur le système cible de l’enquête sur le
système attaquant.
Baryamureeba et Tushabe proposent un nouveau modèle, EDIP (Enhanced Digital
Investigation Process), modifiant 2 des 5 étapes du modèle IDIP : Physical Crime Scene
Investigation et Digital Crime Scene Investigation.
Physical Crime Scene Investigation devient Traceback. Les sous-phases de Traceback correspondent à la recherche du ou des attaquants, ainsi qu’à la recherche
du chemin de l’attaque. Elles comportent la recherche de la source de l’attaque
et une étape d’autorisation venant d’entités judiciaires et/ou administratives pour
continuer l’enquête au-delà du réseau cible.
Digital Crime Scene Investigation devient Dynamite. Les sous-phases de Dynamite
comportent les étapes Physical Crime Scene Investigation et Digital Crime Scene
Investigation du modèle IDIP, ainsi que les étapes Reconstruction et Communication.
Grâce à cette méthode, Baryamureeba et Tushabe ont séparé l’enquête sur l’attaquant
de l’enquête sur le réseau compromis et traitent conjointement les investigations sur les
éléments physiques et numériques.
1.1.2.4 Formalisation de Beebe et Clark
Dans [BC04], Beebe et Clark proposent une formalisation des enquêtes informatiques basée sur les objectifs à atteindre (Objectives-based). Le terme Objectives-based
signifie que le processus d’investigation ne sera pas conduit par les actions à entreprendre pour réaliser l’enquête (Task-based, par exemple : Examiner la base de registres) mais sur l’objectif de cette action (qui serait pour cet exemple : Déterminer si
un logiciel a été installé de façon illégale). La proposition repose sur quatre concepts :
les Phases et Sous-Phases représentent des étapes distinctes du processus forensique,
elles sont généralement fonction du temps et séquentielles.
8
les Principes et Objectifs sont des procédures, des guides ou des méthodes qui caractérisent les phases et les sous-phases. Ils sont non discrets et représentent le but
du processus.
Par ailleurs, les phases et les sous-phases peuvent s’appliquer à différents niveaux
d’abstraction, qui sont ceux décrits par Carrier dans [Car03], comme par exemple :
Physical Media, Media Management, File System, Application et Network. Les phases
se décomposent en 6 étapes :
Preparation : c’est la création de toutes les procédures qui permetteront d’effectuer
des analyses forensiques ainsi que l’entraînement du personnel ;
Incident Response : c’est la détection de l’incident ainsi que le début de l’investigation, qui aura pour objectifs de qualifier l’incident et de préparer une stratégie
d’investigation ;
Data Collection : c’est la récupération des données utiles pour l’enquête (fichiers d’audit, IDS, etc.) ;
Data Analysis : c’est l’analyse des données précédemment récupérées ;
Presentation of Findings : c’est la présentation des résultats des investigations ;
Incident Closure : c’est la conclusion de l’enquête et les suites à donner à celle-ci.
Ces phases sont ensuite décomposées en sous-phases. Beebe et Clark proposent un
exemple de sous-phase pour la phase Data Analysis qui contiendrait : Survey, Extract
et Examine. Ce formalisme est en cours de finalisation, et ne couvre pas encore tous
les aspects de l’analyse forensique (Data Collection, Incident Response, etc.). Les différences entre les plateformes (systèmes d’exploitation) et entre les équipements (ordinateurs, PDA, etc.) ne sont pas non plus prises en compte.
Différences avec notre proposition
Contrairement aux modèles présentés ci-dessus, notre proposition ne s’intéresse
qu’à une partie du processus forensique. Nous nous focalisons sur l’analyse des pièces
récoltées et la présentation des résultats, l’objectif étant d’aider les enquêteurs dans
leurs investigations, en leur proposant des indices. Les résultats d’enquête pourront
être sauvegardés pour être ensuite présentés. Enfin, contrairement au formalisme de
Beebe et Clark, notre démarche permet de mettre en valeur non seulement les objectifs
à atteindre mais aussi les actions à entreprendre pour atteindre ces objectifs.
1.1.2.5 Conclusion
Le tableau 1.1 résume les modèles présentés. Ils sont comparés suivant 5 critères
choisis par rapport aux objectifs de notre projet. Nous voulions que notre approche
prenne en compte aussi bien les éléments de preuves numériques que les éléments
de preuves matériels. La ré-utilisation des connaissances est un autre point sur lequel
notre approche se base, cette propriété nous permet notamment de prendre en compte
l’évolution des technologies et des savoir-faire ainsi que la formation des enquêteurs.
Comme nous l’avons montré en introduction, le travail d’un enquêteur est itératif et non
Eléments
numériques /
matériels
Ré-utilisation
des connaissances
Formation
McKemmish, Mandia
1999
Procise,
2001
et
9
CTOSE,
2003
EDIP,
2004
Beebe
Clark,
2004
oui
oui
non
oui
oui
non
oui
oui
oui
oui
non
oui
oui
non
oui
Démonstrateur non
non
oui
non
non
TAB . 1.1 – Résumé des formalisations sur la globalité du processus
séquentiel, notre approche aura donc un comportement itératif. Enfin nous voulions que
l’approche soit finalisée par la construction d’un démonstrateur.
Le tableau 1.1 montre que tous les travaux que nous venons de décrire ont un comportement séquentiel et qu’un seul possède un démonstrateur, le projet CTOSE. Il faudra noter néanmoins que ce démonstrateur n’est pas accessible au public. Le tableau
montre aussi que la plupart des travaux prennent en compte à la fois les éléments numériques et matériels.
1.1.3 Formalisations sur une partie du procesus forensique
Dans cette partie, nous allons analyser des travaux qui ne traitent que d’une partie
du processus. Comme dans la partie précédente, les travaux seront présentés par ordre
d’ancienneté.
1.1.3.1 Formalisation de Peter Stephenson
Peter Stephenson est un chercheur américain qui a effectué de nombreux travaux
sur l’analyse forensique. Il est notamment l’auteur de l’ouvrage de « Investigating
Computer-Related Crime » [Ste00].
Le langage de description d’enquête DFPL Dans [Ste03b], Stephenson décrit une
approche formelle pour la récupération, l’administration et l’analyse de preuves numériques. Cette approche repose sur 2 concepts :
la notion d’analyse forensique point-à-point. Elle permet de décrire une analyse en
sachant qu’une attaque commence au poste informatique de l’attaquant et finit au
poste de la victime, en passant par une série de systèmes qui peuvent en conserver
la trace ;
et
10
(OpenApplicationSession
(When
(Time 14:57:36 24 Feb 1998)
)
(Initiator
(HostName ‘big.evil.com’)
)
(Account
(UserName ‘joe’)
(RealName ‘Joe Cool’)
(HostName ‘ten.ada.net’)
)
(Receiver
(standardTCPPort 23)
)
)
F IG . 1.4 – Un exemple du langage DFPL
le deuxième concept repose sur la compréhension des méthodes d’attaque et de détection, modélisés par le langage DFPL (Digital Forensics Process Language)
dérivé d’un langage dédié à la détection d’intrusion, CISL (Common Intrusion
Specification Language) [FKP+ 99].
L’objectif est de décrire avec précision le processus de l’enquête et le processus de l’attaque, de manière à pouvoir les rejouer. On ne cherche pas à donner des conclusions
sur l’enquête, mais cette description doit montrer que l’enquête a été effectuée correctement. DFPL, qui s’inspire aussi du langage LISP et du langage S, est illustré par la
figure 1.4. Dans cet exemple, un seul fait (un évènement réseau) a été représenté : une
personne venant de big.evil.com a initié une connexion à la date 14 :57 :36 24 Feb 1998
sur le port 23.
Analyse des causes primaires (Root Cause Analysis) Dans [Ste03a, Ste04], Stephenson propose une technique pour analyser les causes d’une attaque informatique.
Cette technique est basée sur la formalisation précédente et sur les réseaux de Petri
colorés.
Les réseaux de Petri sont des graphes qui comportent deux sortes de nœuds : les
places et les transitions, reliées par des arcs orientés. Chaque place contient un certain
nombre de jetons (0 · · · n) qui peuvent se déplacer de place en place en suivant les
règles de tirage des transitions qu’ils traversent. Les réseaux de Petri colorés [Jen98]
sont de réseaux de Petri dont les jetons sont typés. Le franchissement d’une transition
est alors conditionné par la présence dans les places en entrée du nombre de jetons
nécessaire, qui, de plus doivent satisfaire aux conditions de couleurs qui étiquettent les
arcs.
La proposition de Stephenson repose sur plusieurs processus qui permettent de
modéliser :
11
F IG . 1.5 – Un exemple de réseau de Petri dans le modèle de Stephenson
– l’attaque (détection, résultats, etc.) ;
– la politique de sécurité du réseau ;
– les contre-mesures en cas d’attaque.
Grâce aux réseaux de Petri (F IG . 1.5), Stephenson peut simuler ces trois processus. Les
places du réseau décrivent l’état du système, les transitions décrivent les actions et les
changements de ce système, les jetons permettent de marquer les changements d’état
et les arcs décrivent les liens entre les places (état du système) et les transitions (actions
et changements).
Par exemple, Stephenson modélise l’action d’un ver informatique qui se propage
sur le réseau d’une entreprise (F IG . 1.5). Les résultats obtenus sont de plusieurs ordres :
– trouver le(s) vecteur(s) de l’attaque ;
– comprendre comment l’attaque s’est déroulée ;
– obtenir une description formelle de l’analyse de l’attaque (pour la présenter devant une cour de justice par exemple) ;
– recommander des contre-mesures potentielles pour éviter de futures attaques.
Notre proposition diffère de celle de Stephenson dans le sens où elle repose sur
l’analyse des systèmes compromis un à un, en tentant de remonter jusqu’au système de
l’attaquant. Nos objectifs sont aussi différents, puisque l’on ne propose pas de contremesures, mais des techniques d’investigation à utiliser pour retrouver d’éventuels indices.
12
(define (domain network)
(:extends computer)
(:types network domain - simulation-object
router - host
firewall - router)
(:predicates
(connected-to ?node - object
?net - simulated-object
)
(part-of ?net - network
?domain - domain)
...
)
)
F IG . 1.6 – Un exemple du modèle utilisé par Elsaesser et Tanner
1.1.3.2 Diagnostic automatique de Elsaesser et Tanner
Elsaesser et Tanner proposent dans [ET01] un système de diagnostic automatique
pour l’analyse des attaques informatiques et la récupération de preuves. Leur système
prend en entrée la configuration logicielle de la victime ainsi que la liste des vulnérabilités associées au système compromis. Le système génère alors des séquences d’attaques possibles qui sont simulées sur un modèle représentant le système compromis.
Les effets des attaques simulées sont comparés aux effets de l’attaque observée, ceci
permettant aux enquêteurs de trouver l’attaque qui a réellement eu lieu.
Ce système de diagnostic est testé sur un prototype qui se compose :
1. d’une interface qui convertit la configuration du système compromis en un modèle pour la simulation ;
2. d’un système qui génère des explications plausibles pour les symptômes observés ;
3. d’un simulateur qui génère des attaques sur le modèle ;
4. d’un système de recherche de chaînes de caractères (pattern matching) qui recherche sur le système compromis les effets de l’attaque par rapport aux attaques
simulées.
Le modèle utilisé repose sur PDDL (Planning Domain Description Language) de
Gallab et al. [GHK+ 98]. Un exemple de ce langage est donné en figure 1.6. Il permet
de modéliser :
– la configuration du système compromis (:types) ainsi que ses connexions avec
d’autres systèmes (connected-to, part-of) ;
– la description du problème posé : les effets de l’attaque ;
– la description des actions possibles de l’attaquant (paramètres, pré-conditions,
effets, etc.) ;
13
F IG . 1.7 – Le processus d’investigation de Kerf
– les suites d’actions possibles.
Ce système est de type "mono-passe", c’est-à-dire que l’enquêteur entre la configuration puis demande au système d’analyser l’attaque. Il peut ensuite utiliser les résultats
produits pour rechercher la véritable cause de l’attaque. Dans notre approche, le système serait plutôt de type "multi-passes" (comportement itératif). Après avoir effectué
la configuration initiale (logiciels installés et observations préalables), l’introduction
de nouvelles informations (attaques et actions de l’attaquant) dans le modèle permet
d’affiner les résultats produits.
1.1.3.3 Le projet Kerf
Kerf [KER] est un projet de l’ISTS (Institute for Security Technology Studies)
[IST]. Ses objectifs sont d’identifier les caractéristiques des attaques, de développer
des hypothèses à propos de celles-ci, de partager les connaissances avec d’autres organisations et d’archiver les données pour pouvoir les réexploiter ultérieurement. Le
processus (F IG . 1.7) est itératif et possède un moteur d’hypothèses. Une interface graphique présente à l’utilisateur les résultats du moteur ainsi qu’une visualisation des
fichiers d’audit.
Kerf se base essentiellement sur les fichiers d’audit des systèmes d’exploitation.
Nous proposons d’aller plus loin dans la recherche de preuve en prenant en compte
d’autres informations : la topologie du réseau attaqué, les variables du système, la récupération de données cachées et les indices matériels, comme les entrées-sorties d’un
bâtiment.
14
Eléments
numériques /
matériels
Ré-utilisation
des connaissances
Formation
Comportement
Démonstrateur
Stephenson,
2000
Elsaesser
et Tanner,
2001
Kerf,
2002
non
non
non
non
non
oui
non
non
oui
itératif
séquentiel
itératif
oui
oui
oui
TAB . 1.2 – Résumé des formalisations sur une partie du processus
1.1.3.4 Conclusion
Le tableau 1.2 résume les caractéristiques des travaux qui viennent d’être présentés.
Nous avons utilisé les mêmes critères que pour le tableau 1.1.
On peut noter que ces travaux ne prennent en compte que les éléments numériques
et aucun élément matériel. Par contre, un démonstrateur a été développé pour chacun
de ces travaux.
1.2 Techniques d’investigation
Après avoir décrit des approches formelles de l’analyse forensique, nous allons
présenter maintenant quelques techniques applicables à certaines parties du processus.
Dans la première partie, nous analyserons des techniques de la littérature et dans la
seconde partie, nous ferons une liste non-exhaustive des outils disponibles.
1.2.1 Techniques d’analyse forensique
1.2.1.1 Automated Analysis for Digital Forensic Science
Dans [Sta02, SL03] Tye Stallard et Karl Levitt propose une méthodologie pour
récupérer et analyser de façon sûre les données numériques. L’auteur récupère automatiquement certaines informations (fichiers d’audit), normalise ces dernières puis les
envoie vers un système expert qui produit des déductions sur les suspects potentiels
d’une attaque informatique.
Ce système expert est basé sur un arbre de décision (F IG . 1.8) qui prend en entrée
les fichiers du système compromis et qui donne en sortie quel(s) est (sont) les comptes
1.2. TECHNIQUES D’INVESTIGATION
F IG . 1.8 – L’arbre de décision de Stallard
15
16
utilisateurs qui ont pu être compromis par l’attaquant.
Le prototype de Stallard utilise l’outil TCT (The Coroner’s Toolkit) [FV] pour analyser les images de média. Le résultat de ces analyses est transformé en XML (grâce
au langage PERL), puis utilisé par l’arbre de décision.
1.2.1.2 Formalisation de Leigland et Krings
Dans [LK04], Leigland et Krings proposent une méthode pour la récupération des
données d’enquête. Leur proposition s’appuie sur un modèle en 4 parties :
– l’attaque ;
– la procédure de l’enquête ;
– les primitives de cette procédure (forensic primitives) ;
– le système d’exploitation et ses composants logiciels.
Le système d’exploitation est modélisé par la formule suivante :
C = {c1 , · · · , cn }
où les ci décrivent un composant logiciel particulier et dépendant du système d’exploitation étudié. Chacune des 4 parties citées ci-dessus peut être décomposée de la
même manière. Par exemple, la primitive forensique (fp ) associée au composant logiciel (l) s’écrit : fpl . Si le composant logiciel est le "fichier de mots de passe" clp , alors la
primitive sous Linux s’écrit :
fpl
cat /etc/passwd
ls -l /etc/passwd
La figure 1.9 montre les relations qui peuvent exister entre les différents éléments du
modèle (attaque, composant logiciel, procédure forensique et primitive forensique) en
prenant en compte 2 systèmes d’exploitation différents. Ce modèle permet de mettre
à jour les procédures forensiques, et autorise la création de nouvelles procédures, les
liens seront descendants depuis les attaques vers les procédures puis vers les primitives.
Le modèle décrit l’utilisation des procédures, les flux de données partant alors des
primitives pour aller vers les attaques. Le modèle permet aussi la mise à jour d’une
procédure, le flux ira dans le même sens que la création. Enfin, le modèle permet la
translation d’un ensemble de procédures pour un système d’exploitation donné vers un
autre système d’exploitation : dans ce cas les flux de données partiront des primitives
du premier pour finir aux primitives du second.
Ce modèle a pour but d’administrer les procédures forensiques pour chaque attaque
et pour chaque système d’exploitation. L’objectif n’est donc pas d’aider l’administrateur système à détecter les attaques, ni d’aider les enquêteurs dans leurs investigations
en leur donnant des conclusions sur l’enquête en cours.
1.2.1.3 Analyse forensique des processus de Foster et Wilson
La technique décrite par Foster et Wilson dans [FW04] consiste à récupérer certaines informations volatiles dans la mémoire des systèmes informatiques compromis
17
F IG . 1.9 – Hiérarchie des éléments dans la formalisation de Leigland et Krings
avant que ceux-ci ne soient arrêtés. Dès qu’une intrusion potentielle est détectée, un
IDS enregistre sur le disque dur des informations sur les processus en cours d’exécution, notamment :
– PID (Process IDentification) ;
– le propriétaire ;
– les processus parent et enfant ;
– la pile mémoire ;
– les fichiers / sockets / pipes ouverts ;
– etc.
Les trois derniers travaux présentés ci-dessus ([FW04, Sta02, SL03, LK04]) sont
complémentaires de notre proposition. En effet, ils décrivent des techniques particulières pour analyser certaines parties d’une attaque : Leigland et Krings mettent en
place des processus forensiques (paragraphe 1.2.1.2), Stallard et Levitt analysent des
fichiers d’audit avec un arbre de décision (paragraphe 1.2.1.1), enfin Foster et Wilson
utilisent les variables du système (paragraphe 1.2.1.3).
1.2.1.4 Reconstruction d’événement de Gladyshev et Patel
Gladyshev et Patel proposent dans [GP04, Gla04] une méthode pour reconstruire
un scénario d’attaque, basée sur une machine à états finis. Les fonctionnalités du système d’information (serveurs, imprimantes, etc.) sont modélisées par une machine à
états finis, les hypothèses par les états de cette machine et les événements extérieurs
au système par les événements de la machine à états finis. La machine s’utilise en
back-tracing (retour-arrière), c’est-à-dire qu’elle part d’un fait avéré, par exemple, une
possible utilisation frauduleuse d’une imprimante, et elle décrit tous les événements
qui ont pu conduire à ce résultat.
18
Démonstrateur
Eléments
numériques /
matériels
Ré-utilisation
des connaissances
Formation
Comportement
AADFS,
2002
Leigland et
Krings,
2004
Foster
Wilson,
2004
oui
non
oui
non
non
oui
non
non
non
-
non
oui
non
oui
non
non
-
-
séquentiel
et
Gladyshev
et
Patel,
2004
itératif
TAB . 1.3 – Synthèse des caractéristiques
Notre proposition est très similaire à celle de Gladyshev et Patel, à certaines différences près. D’abord notre approche n’est pas orientée back-tracing, pour chaque
système et chaque attaque analysés, l’analyse est effectuée en prenant uniquement en
compte ce qui a été observé, ce qui peut être vu comme une analyse « à plat » ; le moteur
d’inférence donne à l’enquêteur toutes les possibilités en les ordonnant. D’autre part,
nous n’analysons pas qu’un seul système mais nous prenons en compte tous les systèmes qui ont été compromis. L’analyse de système en système et d’attaque en attaque
se fait non seulement vers l’arrière mais aussi vers l’avant. L’objectif est de retrouver
tous les systèmes qui ont été attaqués. Enfin, nous n’utilisons pas une machine à états
finis mais des réseaux bayésiens.
1.2.1.5 Conclusion
Le tableau 1.3 fait la synthèse des techniques qui viennent d’être présentées. Nous
avons utilisé les mêmes critères que pour le tableau 1.1. La proposition qui se rapproche
la plus de la nôtre est celle de Gladyshev et Patel. Notre proposition propose aussi de
reconstruire les évènements qui ont permis à l’attaquant de perpétrer son forfait. La
proposition de Gladyshev et Patel a un comportement itératif comme notre approche et
permet aussi l’apprentissage des cas précédents.
1.2.2 Outils pour l’analyse forensique
Un système informatique peut recéler de nombreuses données intéressantes pour un
enquêteur. Dans cette section, nous allons lister, de manière non-exhaustive, les types
d’informations qui peuvent aider les enquêteurs et quelques logiciels qui permettent de
trouver ces informations. Les techniques d’investigation sont présentées dans l’ordre
19
des étapes décrites par McKemmish (section 1.1.1) et se limite aux systèmes informatiques dont le système d’exploitation se base sur un noyau Linux ou Windows.
1.2.2.1 Identification
L’identification se fait d’une part par l’analyse des fichiers d’audit et d’autre part
par l’analyse des variables du système.
Fichiers d’audit du système
Unix Dans le monde Unix / Linux, l’audit est géré habituellement par le démon1
syslog. Dans la plupart des distributions, il envoie ses messages dans le répertoire /var/log/ et sous le nom messages. On peut remarquer que les messages des journées précédentes sont compressés et qu’il peut exister de nombreux autres fichiers suivant la
configuration du démon Syslog (dans /etc/syslog.conf). Tous les évènements
significatifs sont enregistrés, tant au niveau matériel qu’au niveau logiciel (connexion
ou augmentation de privilèges par exemple).
Il existe de plus trois autres fichiers (au format binaire) qui donnent des renseignements sur l’utilisation du système (figure 1.10) :
/var/run/utmp accessible par la commande w, donne la liste des utilisateurs actuellement connectés et leur dernière commande.
/var/log/wtmp accessible par la commande last, donne les dernières
connexions réussies au système.
/var/log/lastlog accessible par la commande lastlog, donne la liste de
tous les utilisateurs et la date de leur dernière connexion.
D’autres fichiers doivent aussi être étudiés pour voir s’ils n’ont pas été modifiés :
/etc/passwd pour trouver des comptes utilisateurs non autorisés ou ayant des privilèges trop importants
/etc/shadow pour s’assurer que chaque compte est protégé
par un mot de passe
/etc/groups pour voir les privilèges de chaque compte
/etc/hosts pour lister les entrées DNS locales
/etc/hosts.equiv pour analyser les relations de confiance
˜/.rhost pour analyser les relations de confiance au niveau utilisateur
/etc/hosts.{allow,deny} pour voir les règles du "TCPWrappers"
/etc/rc* pour lister les processus lancés au démarrage
/etc/syslog.conf pour déterminer la localisation des fichiers
d’audit
fichiers crontab pour lister les événements programmés
/etc/inetd.conf pour lister les services gérés par inetd
1 en anglais : DAEMON (Disk And Execution MONitor), programme qui effectue des tâches de fond sous
Unix
20
domtom@domtom:~/papier/etat_de_l_art/ps$ w
16:33:54 up 7:04, 4 users, load average: 0.34, 0.37, 0.40
USER
TTY
FROM
LOGIN@
IDLE
JCPU
PCPU
domtom
:0
09:30
?xdm?
0.00s
?
domtom
pts/0
:0.0
09:30
37.00s 1.36s 1.36s
domtom
pts/1
:0.0
09:30
0.00s 1.43s 0.03s
domtom
pts/2
:0.0
09:30
30.00s 21.60s 0.03s
domtom@domtom:~/papier/etat_de_l_art/ps$
domtom
pts/3
:0.0
domtom
:0
reboot
system boot 2.4.20-686
cmichel pts/2
cmichel
domtom
:0
reboot
domtom
pts/1
:0.0
domtom
pts/4
:0.0
domtom
:0
domtom
pts/2
192.168.0.109
domtom
pts/2
192.168.0.109
domtom
pts/2
192.168.0.109
domtom
:0
reboot
last
Tue Feb
Tue Feb
Tue Feb
Fri Feb
Mon Feb
Mon Feb
Fri Feb
Fri Feb
Fri Feb
Thu Feb
Thu Feb
Thu Feb
Tue Feb
Mon Feb
18
18
18
14
10
10
7
7
7
6
6
6
4
3
09:31
09:30
09:29
15:07
11:22
11:21
15:12
14:24
14:23
16:02
10:48
10:00
08:58
17:20
WHAT
bash
w
make edit
- 09:33 (00:01)
still logged in
(07:05)
- 15:11 (00:03)
- down (7+22:05)
(7+22:06)
- 15:37 (00:25)
- 14:25 (00:01)
- down (2+20:56)
- 16:03 (00:00)
- 10:48 (00:00)
- 10:20 (00:19)
- 13:47 (3+04:49)
(6+17:58)
domtom@domtom:~/papier/etat_de_l_art/ps$ lastlog
Username
Port
From
Latest
root
NODEVssh cmichel
mer fév 12 16:44:13 +0100 2003
daemon
**Never logged in**
bin
**Never logged in**
domtom
:0
mar fév 18 09:30:29 +0100 2003
sshd
**Never logged in**
etotel
**Never logged in**
lheye
**Never logged in**
cmichel
pts/2
cmichel
ven fév 14 15:07:44 +0100 2003
jzimm
**Never logged in**
valanou
**Never logged in**
bjouga
**Never logged in**
nprigent
**Never logged in**
F IG . 1.10 – Résultats produits par les programmes "w", "last" et "lastlog" sous Unix
21
Pour trouver des traces d’exécution d’applications, il faut en général rechercher
dans les répertoires /tmp/ et /var/. Enfin, il est possible de connaître les dates et
horaires de création des fichiers. On aurait pu aussi obtenir les dates de dernier accès
et de dernière modification en tapant respectivement les commandes "ls -lu" et "ls -lc".
En ce qui concerne les dates et horaires, il faut faire attention aux fuseaux horaires
ainsi qu’au fait que l’horodatage du système en cours d’analyse peut être légèrement
différent à cause d’un problème de synchronisation ou à cause d’une manipulation
intentionnelle de l’attaquant.
Windows Si dans le cas de Linux l’audit du système est automatique, la situation
est différente pour Windows. L’audit au niveau applicatif est automatique mais l’audit
du système ne l’est pas, et nécessite l’activation du programme Paramètres de
sécurité locale. D’autre part, si la plupart des fichiers temporaires se trouvent
dans le répertoire C:\temp\, certaines applications mettent leurs fichiers temporaires
dans le répertoire de travail, notamment Microsoft Word.
Analyse L’analyse des fichiers d’audit est très longue de part le nombre et la
taille des fichiers à traiter. En règle générale, cette analyse se fait par des techniques de
pattern matching, en recherchant des chaînes de caractères connues dans les noms de
fichiers ou dans leur contenu.
Variables système Les données volatiles doivent être récupérées grâce à un interpréteur de commandes dans lequel on a confiance (trusted shell). Les principaux éléments
à récupérer sont :
– la date2 ;
– les utilisateurs connectés ;
– les applications en cours d’exécution ;
– les sessions réseaux ouvertes.
La date du système est demandée deux fois (cf. TAB 1.4) : cela permet aux enquêteurs de prouver à quelle date et à quelle heure ils ont analysé le système. Cette façon
de travailler permet aussi de prouver face à la justice que les actions effectuées à telle
date et à telle heure peuvent être ou non imputées aux enquêteurs.
Chaque programme en cours d’exécution utilise des ressources et est référencé par
un numéro de processus. Pour Unix / Linux, les commandes ps ou top permettent d’obtenir la liste des processus. Pour Windows, on peut utiliser la combinaison de touches
[crtl alt sup].
La connaissance du nombre de processus, de leur nom et de la date à laquelle ils ont
été lancés va permettre de détecter des programmes illicites lancés par des utilisateurs
non-autorisés. Il faut aussi déterminer quels sont les liens réseaux établis, quels sont
ceux qui sont connectés pour pouvoir trouver les sondes réseaux, les "portes dérobées"
et tout autre logiciel qui pourrait s’avérer nuisible au bon fonctionnement du système.
Le programme netstat permet de lister ces liens.
2 il
faudra noter aussi le fuseau horaire correspondant et un éventuel décalage avec la véritable valeur
22
Actions
Établissement d’un nouvel interpréteur de commande
Enregistrement de la date du
système
Détermination des personnes
connectées
Enregistrement des sockets ouvertes
Liste des processus qui ont ouverts des sockets
Liste des processus en cours
d’exécution
Liste des systèmes récemment
connectés
Enregistrement de la date du
système
Enregistrement des commandes
exécutées et de leur réponse
Windows 2000/NT
Linux/Unix
cmd.exe
bash
date, time
w
loggedon
w
netstat
netstat -anp
fport
lsof
pslist
ps
nbstat
netstat
date, time
w
doskey
script, vi, history
TAB . 1.4 – Commandes Windows et Linux de récupération des informations système
à utiliser dans cet ordre [MP01]
23
1.2.2.2 Préservation
La phase suivante est la phase de préservation des traces. Pour pouvoir ensuite être
exploitables et présentables, ces traces doivent avoir été conservées intactes et cette
conservation doit être vérifiable.
Préservation physique Dans un premier temps, l’enquêteur doit préserver les éléments matériels qu’il analyse. L’enquêteur doit photographier tout élément qui constitue le dossier à traiter pour permettre par la suite un certain nombre de vérification
une fois que ces éléments auront été enlevés. Cette préservation se fait d’autre part par
pastillage du matériel informatique, c’est-à-dire que l’enquêteur doit marquer tous les
éléments que les enquêteurs vont être amenés à emporter.
Duplication de média La duplication consiste en une copie "bit à bit" des media physiques (disques durs ou amovibles) en prenant la précaution d’utiliser un write-bloquer3
ou toute technique permettant de ne pas altérer les données initiales. La manière de procéder la plus sûre consiste à redémarrer4 les machines sur un autre système (LinuxCare
[LC], Trinux [TRI] ou Knoppix [KNO]). On obtient alors un système "sûr", qui ne
contient ni cheval de Troie ni autre logiciel pouvant perturber l’opération.
La duplication peut être plus compliquée quand les enquêteurs doivent analyser
des assistants personnels ou des téléphones portables, qui possèdent peu d’interfaces
d’entrée / sortie. Notamment, en ce qui concerne les téléphones portables, il est nécessaire de démonter l’appareil pour accéder directement à la carte électronique, comme
le montre les travaux de Svein Willassen [Wil03] et James Clark5 .
La duplication de média est toujours accompagnée d’une signature numérique, réalisée par un algorithme de hachage du type MD5 ou SHA, permettant de prouver que
la copie est identique (au bit près) à l’original.
1.2.2.3 Analyse
La phase d’analyse est la phase la plus longue de la procédure. Outre les fichiers
d’audit du système (1.2.2.1), il y a d’autres informations à analyser : les fichiers d’audit
du réseau, les informations contenues dans certains fichiers (notamment dans les documents bureautiques) les fichiers cachés ou supprimés, le trafic réseau, la topologie des
réseaux, les communications personnelles et des indices physiques.
Vérification des signatures des fichiers système Cette technique permet de vérifier l’intégrité des fichiers système et des programmes indispensables au système
d‘exploitation. En effet, un attaquant peut avoir remplacé certains fichiers par des fichiers légérement différents et qui lui permettent de se cacher ou d’obtenir des accès
administrateurs sans connaître le mot de passe administrateur.
3 outil
permettant de dupliquer un média en interdisant physiquement la ré-écriture sur le média source
un CD ou une disquette de démarrage
5 http://www.forensicts.co.uk/
4 via
24
Analyse des fichiers de données Un grand nombre de fichiers peuvent recéler des
informations précieuses pour les enquêteurs. Il s’agit des fichiers d’audit du système
mais aussi de tout fichier que l’attaquant a pu utiliser comme les fichiers de compilation
et de configuration des outils qu’il a utilisés ou les fichiers bureautiques ou autres qu’il
a manipulés à la recherche d’informations.
Fichiers d’audit réseau
Le cas particulier des pare-feux Un pare-feu est un dispositif qui filtre les paquets réseaux qui le traversent. Il est placé en général entre le réseau interne de l’entreprise et l’internet, de manière à ne transmettre que les paquets autorisés vers les
machines appropriées.
Il existe différents types de pare-feu [Jeu02] :
– Filtrage simple de paquets : Le filtrage est fait sur les adresses IP et sur les
numéros de ports (source et destination). Ce type de filtrage offre une défense
simple et efficace, mais la mise en place manque de souplesse et peut être bloquante pour le bon fonctionnement de certaines applications.
– Firewall stateful : Un tel pare-feu utilise le filtrage précédent, en gardant en
plus une trace de l’état de tout échange de données soumis à approbation. Ce
type de filtrage permet une analyse et un filtrage plus fin des paquets réseaux car
il est capable de reconnaître et comprendre les flux réseaux, mais il ne permet
pas d’arrêter les attaques sur des vulnérabilités de logiciels6 car il est incapable
d’analyser la sémantique du flux.
– Proxying applicatif : Le proxying applicatif a pour but de se substituer au
serveur ou au client qu’il doit défendre en traitant les demandes à leur place,
pour ensuite les retransmettre dans une forme la plus conventionnelle possible.
L’inconvénient majeur de ce type de filtrage vient du fait que le pare-feu doit
connaître les protocoles et les applications, ce qui pose problème pour ceux qui
sont peu utilisés ou les applications "maison".
Tous les pare-feux permettent aux administrateurs de récupérer des fichiers d’audit.
On y trouve de nombreuses informations sur les connexions refusées (en fonction de
la politique de sécurité qui a été spécifiée). Sachant que le pare-feu intercepte tout
le trafic avec l’extérieur, ces fichiers peuvent être très précieux dans le cadre d’une
enquête, en permettant d’identifier les connexions du réseaux qui ont été interdites et
leur provenance.
Le cas particulier des IDS Il existe deux types d’IDS [Mic02] : les IDS dits à
approche comportementale et ceux dits à approche par scénarios.
Dans la première approche, on commence par apprendre le comportement normal
des entités présentes dans le système, puis on émet une alerte dès que l’entité dévie de
son comportement. Dans la seconde approche, on recherche dans les données d’audit
les signatures de scénarios d’attaque enregistrés dans une base.
Les IDS ne permettent pas de découvrir toutes les attaques. En règle générale, une
intrusion est détectée soit parce que le pirate l’a intentionnellement voulu (destruction
6 par
exemple la faille du "double decode" sur les serveurs IIS
25
[**] [111:16:1] spp_stream4: TCP CHECKSUM CHANGED ON RETRANSMISSION
(possible fragroute) detection [**]
02/17-13:31:32.958932 192.168.X1.X2:4417 -> 192.168.Y1.Y2:80
TCP TTL:64 TOS:0x0 ID:1689 IpLen:20 DgmLen:652 DF
***AP*** Seq: 0xC6DCDF7 Ack: 0xC684D652 Win: 0x16D0 TcpLen: 32
TCP Options (3) => NOP NOP TS: 61265382 87935966
[**] [100:1:1] spp_portscan: PORTSCAN DETECTED from 192.168.X1.X3
(THRESHOLD 4 connections exceeded in 0 seconds) [**]
02/18-09:32:09.475879
[**] [100:2:1] spp_portscan: portscan status from 192.168.X1.X3:
1042 connections across 1 hosts: TCP(1042), UDP(0) [**]
02/18-09:32:13.126532
[**] [100:2:1] spp_portscan: portscan status from 192.168.X1.X3:
311 connections across 1 hosts: TCP(311), UDP(0) [**]
02/18-09:32:51.619002
[**] [111:2:1] spp_stream4: possible EVASIVE RST detection [**]
02/18-09:32:51.658904 192.168.X1.X3:40311 -> 192.168.X1.X2:25
***A*R** Seq: 0xAD65643D Ack: 0xC628431A Win: 0x16D0 TcpLen: 32
[**] [111:2:1] spp_stream4: possible EVASIVE RST detection [**]
02/18-09:32:51.667612 192.168.X1.X3:40394 -> 192.168.X1.X2:1003
***A*R** Seq: 0xADB90385 Ack: 0xC6399D97 Win: 0x16D0 TcpLen: 32
F IG . 1.11 – Exemple d’alertes Snort
de données, défigurement de sites Web, etc.), soit parce que l’on est en présence d’une
attaque "bruyante" (typiquement un déni de service), soit enfin parce l’administrateur
a détecté une anomalie. Dans les entreprises ayant un haut degré d’exigence en sécurité (par exemple les banques), plusieurs IDS en parallèle et de types différents sont
exploités et font l’objet d’une surveillance permanente. Dans la plupart des cas, un IDS
génère un gros volume d’alertes, qui masque les véritables attaques au milieu des faux
positifs (les fausses alertes). Les fichiers générés doivent cependant être vérifiés. Ils
permettent, en cas d’attaque, de donner une première approximation sur son étendue :
combien de machines sont compromises, depuis combien de temps, etc.
La figure 1.11 montre une alerte SNORT quand un scan de type "EVASIVE RST"
a été effectué. On remarquera notamment l’adresse IP source 192.168.X1.X3, ce
qui donne un très bon indice sur la source de l’attaque. Mais cet exemple montre
aussi que l’on peut avoir aussi beaucoup de faux positifs, comme la première alerte
"TCP CHECKSUM CHANGED ON RETRANSMISSION".
Après avoir analysé cette première alerte, il faut vérifier dans les messages précédents si d’autres alertes ne sont pas passées inaperçues. Ces alertes peuvent n’avoir
aucun sens prises séparément mais peuvent constituer un très bon début de piste pour
les investigateurs. De plus, certaines alertes peuvent être des "faux positifs" (fausses
26
alertes). Il faut donc à chaque fois vérifier si l’attaque peut avoir lieu sur la machine
concernée. Par exemple, une vulnérabilité Windows sera inopérante sur une machine
Linux.
Le cas particulier des pots de miel (Honeypot) Un pot de miel est un système
dont l’objectif est d’attirer les cybercriminels. Sa configuration comporte volontairement des failles de sécurité, ainsi que des moyens permettant d’enregistrer le comportement des utilisateurs. Les premiers travaux ont été effectués en 1990 par Clifford
Stoll et Bill Cheswick. Les premiers produits opérationnels sont proposés en 1998 (CyberCop Sting, NetFacade et BackOfficer) ; le projet HoneyNet [HNT] est créé en 1999.
Il y a deux types de pots de miel :
– en production (production Honeypots) ; Ils sont utilisés pour sécuriser un réseau
opérationnel. Non seulement il est possible de détecter des attaques grâce à leurs
fichiers d’audit, mais on peut aussi utiliser les résultats fournis pour corriger les
vulnérabilités, grâce aux attaques observées.
– en recherche (research Honeypots) ; Ils sont utilisés pour étudier comment la
communauté Black Hat évolue, quelles sont les techniques que cette communauté utilise et qui appartient à cette communauté. Les pots de miel de recherche
sont plus complets que les pots de miel de production. C’est en général le système en entier qui peut être attaqué (et non pas seulement un seul service), ce qui
en fait des systèmes sensibles dans leur gestion et complexes pour l’analyse de
leur résultats.
La localisation du pot de miel est importante. Il peut être placé :
– avant ou après le pare-feu ;
– dans la DMZ ou sur le réseau interne ;
– dans un sous-réseau spécifique ;
– à proximité ou non d’un IDS.
– en prévention (dans la DMZ ou en interne) : pour permettre de parer des attaques
ou pour découvrir un attaquant ;
– en détection (à l’extérieur) : pour détecter les attaques comme un IDS ;
– en réponse (dans la DMZ) : pour donner un maximum d’informations sur une
attaque qui a été réussie ;
– en recherche (à l’extérieur ou dans la DMZ, sur le routeur d‘entrée et en interne) :
pour obtenir des informations sur toutes les attaques (réussies ou non).
Comme le propose Lance Spitzner dans [Spi02], les pots de miel peuvent aussi
servir de poubelle (Garbage Collector) pour capturer tous les flux réseau non
autorisés.
L’analyse des données collectées par un pot de miel repose sur l’étude de :
1. l’adresse IP source ;
2. l’adresse IP destination ;
3. le port TCP/UDP destination ;
4. la date et l’heure de l’attaque ;
5. les commandes effectuées.
27
Internet
P2
P1
WWW
Mail
P4
Réseau Interne
P3
F IG . 1.12 – Positionnement d’un pot de miel
28
L’adresse IP source permet de connaître la provenance de l’attaque, en faisant une recherche DNS avec des outils comme Whois ou dig. L’adresse IP destination identifie
le système attaqué. Le port TCP/UDP permet de connaître le logiciel visé. Enfin, les
premières commandes fournissent un aperçu sur les capacités du pirate et ses objectifs.
L’analyse doit être faite en décomposant la totalité du processus de l’attaque :
1. l’alerte ; elle est en général donnée par l’IDS en charge de surveiller le pot de
miel ;
2. la prise d’empreinte par le pirate ; avant qu’il puisse se connecter, il doit savoir
quels sont les services offerts par la machine ; des premières indications sur le
mode opératoire du pirate et sur sa base d’attaques peuvent être enregistrées à ce
moment ;
3. l’exploit ; il peut renseigner sur l’habileté de l’attaquant ;
4. l’installation ; après l’exploit, le pirate va généralement vouloir garder un accès
permanent à la machine. Pour cela, il va installer une porte dérobée (rootkit) et
s’arranger pour que toutes ses actions passées, présentes et futures soient masquées ;
5. l’utilisation ; une fois installé, le pirate peut revenir pour effectuer des actions
diverses et variées (comme l’installation d’un sniffer, l’attaque vers d’autres machines ; etc.).
Récupération de données cachées ou supprimées
La corbeille (Recycle bin) Sous Windows, et maintenant aussi sous Linux, il
existe un répertoire où les fichiers supprimés sont copiés avant d’être détruits définitivement par l’utilisateur. Il est donc possible de retrouver des données intéressantes
dans les corbeilles (mais cela est vrai seulement pour des pirates peu expérimentés et
ayant un accès physique à la machine).
Effacement définitif Quand un fichier est effacé définitivement, le système d’exploitation marque l’emplacement sur le disque dur comme étant libre mais le fichier
n’est pas physiquement détruit. Il sera effectivement effacé quand le système aura réécrit d’autres données sur cet emplacement.
On peut donc retrouver des données sur un disque même si elles ont été effacées. Il
y a deux méthodes de récupération : la première consiste à rechercher sur les disques
des mots clés ou des entêtes caractéristiques de certains fichiers (images, sons, documents bureautiques, etc.). On peut aussi parcourir la table du média qui liste tous les
fichiers du média (supprimés ou non).
Des outils comme EnCase [EC] peuvent effectuer ce genre de recherche sur des
systèmes Windows. Pour Linux, Sleuthkit [SLE] permet de lister et récupérer des fichiers en connaissant leurs numéros d’inode.
Effacement par écrasement Un autre moyen d’effacer des données consiste à
utiliser des outils qui vont dans un premier temps écraser le contenu des fichiers à
29
supprimer par des données aléatoires, puis supprimer le lien entre le fichier et le système d’exploitation. Dans ce cas, la récupération des données devient impossible de
façon logicielle, il faut alors utiliser des moyens physiques pour récupérer des traces
(microscope électronique).
Écoute du réseau L’écoute du réseau juste après une attaque peut être intéressante
pour plusieurs raisons :
– si l’attaquant est toujours en action, on va pouvoir observer la suite de son comportement ;
– si l’attaquant a installé une trappe logicielle (back-door) ou tout autre logiciel
capable de communiquer avec l’extérieur (ordinateur zombie), on peut identifier
les systèmes qui ont été compromis par l’attaquant.
Topologie du réseau Il faut dans un premier temps identifier les systèmes et cartographier le ou les réseaux qui doivent être analysés. Il faut ensuite construire la topologie
du réseau, en mettant en évidence les serveurs (HTTP, NIS, FTP, etc.), les systèmes
d’exploitation utilisés avec leurs versions et les mises à jour.
Un graphique représentant le réseau peut permettre aux enquêteurs de progresser
plus rapidement. Ce graphique doit être réalisé en collaboration avec les administrateurs du ou des sites concernés. Il est possible d’utiliser des outils tels que Cheops
[CHE] (FIG. 1.13), OPNET [OPN] ou LanGuard [LGD]. Une fois la topologie connue,
il reste à interroger les administrateurs système sur la criticité des serveurs et des applications.
Évaluer cette criticité permet aux enquêteurs de savoir si des systèmes peuvent être
arrêtés, pendant combien de temps et quelles sont les modifications qu’il est possible
d’apporter, avec le minimum de perturbation, lorsque par exemple une porte cachée
(back-door), a été découverte.
Cela permet aussi d’établir un planning pour la remise en marche des systèmes
concernés.
Connexions internet Nous allons maintenant présenter les méthodes pour remonter la piste d’une attaque sur internet. Ces méthodes sont pour la plupart théoriques
car pour l’instant difficiles à implémenter sur la totalité de l’internet. Elles pourraient
non seulement servir à sécuriser l’internet, mais aussi générer des traces pour les enquêteurs. Certaines, comme l’Ingress Filtering, commencent à être utilisées par les
fournisseurs d’accès (par exemple AAPT http://www.aapt.com.au/ en février
2005).
Ingress Filtering (Filtrage entrant) Il s’agit de configurer les routeurs de façon
à ce qu’ils bloquent les paquets venant d’adresses IP non légitimes [SWKA01], certains paquets pouvant avoir été fabriqués avec une adresse IP source différente de celle
d’origine.
Cette méthode permet de bloquer ces paquets ou de les enregistrer pour étude ultérieure. Elle ne peut cependant être utilisée que dans certains cas : le routeur qui filtre
30
F IG . 1.13 – L’outil Cheops
31
doit pouvoir déterminer si une adresse IP est "légitime" et le trafic réseau ne doit pas
être trop dense pour avoir le temps de réaliser le filtrage.
Link testing (Test des liens) Le routeur placé juste avant le réseau de la victime
doit chercher d’où vient le flux incriminé [SWKA01] (i.e. sur quelle interface le flux
de données illégitimes arrive). L’idéal serait que chaque routeur en amont exécute la
même opération jusqu’à remonter à la source de l’attaque.
Dans ce cas, il faut que l’attaquant reste actif tout le temps de la recherche et que
chaque routeur sache effectuer cette recherche.
Input debugging (Correction d’entrée) Cette méthode est un cas particulier du
"Link testing". Il s’agit pour l’opérateur de filtrer des paquets particuliers en sortie et de
déterminer à quels paquets en entrée ils correspondent [SWKA01]. Pour implémenter
une telle méthode, il faut que l’exploitant du réseau attaqué puisse communiquer à
l’opérateur la signature de l’attaque, afin que ce dernier puisse interroger les routeurs
pour savoir à quoi correspond le flux recherché.
La limitation pratique vient de la nécessité d’une bonne communication et coordination entre opérateurs.
Controlled flooding (Inondation contrôlée) Cette méthode est un autre cas particulier du "Link testing", consistant à inonder (saturer en trafic) certains routeurs prédéterminés, pour voir si cela a un effet sur l’attaque en cours [SWKA01] [BC99].
Cette technique est intéressante puisqu’elle n’a besoin d’être implantée que sur
quelques routeurs, malheureusement cette technique impose de faire un déni de service !
Logging (Enregistrement) Le but est d’enregistrer les paquets qui passent au
travers de "routeurs-clé" [SWKA01]. Une analyse post-mortem est ainsi possible. L’inconvénient majeur vient du fait que les routeurs qui l’implémentent doivent avoir beaucoup de ressources.
Packet Marking (Marquage des paquets) Il est possible de remonter à la source
d’une attaque en marquant les paquets qui traversent les routeurs [Goo02]. Chaque paquet est marqué aléatoirement par chaque routeur avec un label propre à celui-ci. Ainsi,
quand on reçoit des paquets suspects, on peut savoir par quels routeurs ces paquets sont
passés. Après avoir reçu un certain nombre de paquets, on peut alors reconstruire le
chemin.
Étude des communications On entend ici par communication soit des messages
laissés intentionnellement par l’attaquant sur le système compromis, comme lors du
défigurement d’un site Web7 , soit des messages privés (mail, IRC, etc.) qui ont été
retrouvés par les enquêteurs sur des systèmes compromis ou sur les systèmes de suspects. Les défigurements de sites Web sont généralement des actions sans but précis,
7 http
://attrition.org/security/commentary/
32
fait par des "script kiddies", même si certains messages peuvent avoir une portée plus
grande que "I 0wn yOu" et critiquer par exemple l’activité d’une entreprise. Les messages privés apportent en général plus d’informations aux enquêteurs, mais posent un
problème de droit et d’éthique concernant le fait de lire une correspondance sans en
avoir l’autorisation du propriétaire ou l’accréditation adéquate.
Analyse des preuves physiques Les preuves physiques peuvent jouer un rôle très
important dans une enquête. L’analyse des entrées et sorties d’un bâtiment peuvent
permettre de démasquer le véritable coupable, même s’il a utilisé le compte informatique d’un tiers pour perpétrer son forfait. Cela peut aussi permettre de disculper une
personne qui n’avait rien à voir avec le délit, ou de démontrer que l’attaquant est à
l’extérieur de l’entreprise et utilise une connexion sans fil pour accéder aux serveurs
internes.
De même la nature de l’organisation attaquée peut donner des informations importantes : une attaque par déni de service sur un serveur Microsoft n’a pas la même
signification qu’un déni de service sur le site Web d’une petite entreprise familiale dans
le Larzac.
Enfin, toutes les techniques habituellement utilisées par les forces de police pour
des délits non informatiques peuvent être utilisées, comme par exemple les empreintes
digitales, les empreintes ADN, etc.
1.2.2.4 Etapes de présentation
Il n’y a pas de solution logicielle qui permette à ce jour de présenter des résultats d’enquêtes, mais voici quelques logiciels communément utilisés par les enquêteurs
pour analyser des média et pour sauvegarder les résultats des analyses.
1.2.2.5 Outils
Outils libres (GPL)
Linux Les environnements Linux proposent plusieurs outils standards qui permettent d’effectuer des analyses forensiques, la plupart disponibles en ligne de commande. Ils ne sont donc pas user-friendly, mais ils permettent par contre d’effectuer des
tâches très précises sur les systèmes compromis. Il existe d’autre part des CD bootables
qui permettent d’utiliser un système Linux sur n’importe quel machine (par exemple
Knoppix [KNO] ou Helix [HEL]).
dd (Data Duplicator) est un logiciel qui vient du monde Unix. Il permet de dupliquer "bit à bit" un disque dur ou un disque amovible vers un fichier. Son utilisation
standard est : dd if=[source] of=[destination] et on peut ajouter quelques
options : "copie à partir de", "copie de . . . à . . . ", etc. Par défaut (sans if et of), dd
prend en entrée l’entrée standard et en sortie la sortie standard. Ainsi, il peut être utilisé
en conjonction avec nc (NetCat) pour envoyer via un réseau une copie du support (FIG.
1.14).
33
victime@reseau$ dd if=/dev/hda1 | des -e -c -f passe | nc -w 3 192.168.0.1 2222
enquêteur@reseau$ nc -l -p 2222 | des -d -c -f passe | dd of=victime.hda1.vfat
F IG . 1.14 – Envoi d’une copie d’un disque dur via un réseau
enquêteur@reseau$ mount victime.hda1.vfat /mnt/victime -o ro,loop=/dev/loop0
F IG . 1.15 – Lecture d’une image d’un disque dur sous Linux
Dans cet exemple, on copie tout le contenu du premier disque dur de
victime@reseau et on l’envoie via le réseau sur la machine
enquêteur@reseau. De plus, la communication est chiffrée par DES. Le fichier
victime.hda1.vfat est une image fidèle du disque dur hda1. Pour le lire, il suffit de
"monter" ce fichier comme si c’était un disque normal via le périphérique virtuel /dev/loop, comme le montre la figure 1.15. L’option ro oblige mount à monter le système
de fichiers en lecture seule ("read-only"). On peut aussi utiliser dcfldd [DCF] qui est
une version améliorée de dd. Il permet notamment le calcul à la volée des sommes de
contrôle.
Sleuthkit et Autopsy Ces deux outils ([SLE]) permettent de lire facilement des
images de disque. Ils sont libres et OpenSource (FIG. 1.16 et 1.17). Voici quelquesunes de leurs caractéristiques :
– recherche sur des fichiers et répertoires supprimés ou non ;
– accès à la structure bas-niveau des systèmes de fichiers ;
– recherche de mots clé (Pattern matching) ;
– chronologie de l’activité du suspect sur les fichiers ;
– tri des fichiers par catégorie et vérification des extensions ;
– identification des images et affichage des imagettes ;
– consultations de bases de données d’informations de "hash" ;
– notes des enquêteurs ;
– génération de rapports.
PyFlag L’outil PyFLAG [PYF] se base sur Sleuthkit et offre une interface graphique qui permet notamment d’analyser les fichiers d’audit.
Outils commerciaux
Encase Le logiciel EnCase de Guidance Software [EC] a été créé en 1998 [Cas01].
Il permet de lire facilement les images de disque. Il reconnaît un grand nombre de systèmes de fichiers (FAT12, FAT16, FAT32, NTFS, Linux, Macintosh, etc.) et permet
d’effectuer des recherches (recherche de fichiers, dossiers, chaînes de caractères) avec
une interface graphique de type Windows.
34
F IG . 1.16 – Autopsy - présentation des images disque analysées
F IG . 1.17 – Autopsy - pattern matching
1.3. ETAT DE L’ART DES SYSTÈMES D’AIDE À LA DÉCISION
35
Ilook Le logiciel ILook [IL] a les mêmes objectifs que EnCase. Il permet d’effectuer des recherches sur des images de média. Cependant, il faut appartenir à une
agence gouvernementale pour pouvoir l’utiliser.
FTK Forensic Toolkit est un produit de la société AccessData8 . FTK est, comme
Encase, un logiciel propriétaire. Il intègre beaucoup d’outils comme : l’acquisition,
l’analyse de fichiers, l’analyse d’email et de fichiers ZIP, des filtres sur les systèmes de
fichiers, un récupérateur de mots de passe, etc.
1.2.2.6 Conclusion
Cette section a présenté un certain nombre d’outils utilisables sur les plateformes
les plus standards (Linux et Windows). Cette énumération n’est pas exhaustive mais
elle permet de montrer que les enquêteurs n’ont pas les mêmes outils suivant la plateforme. Il y a beaucoup plus d’outils propriétaires sous Windows que sous Linux. Le
système Linux comprend par contre beaucoup d’outils en ligne de commandes qui ne
sont accessibles qu’à des enquêteurs initiés.
1.3 Etat de l’art des systèmes d’aide à la décision
Le début de ce chapitre présente succinctement les systèmes experts puis les différents types de moteur d’inférences et celui (réseaux bayésiens) que nous avons retenu.
Nous présentons ensuite plus précisément ce formalisme et montrons comment l’utiliser pour atteindre nos objectifs.
1.3.1 Systèmes experts
Les systèmes experts ont comme objectif de reproduire le travail d’un expert. Ils
ont été construits pour permettre l’exploitation des connaissances d’experts dans un
domaine précis et délimité, pour assister l’utilisateur de manière efficace. Les systèmes
experts se basent sur des faits (base de connaissances) qui représentent la connaissance
de l’expert. On exploite ces faits avec des règles de production de la forme :
si conditions alors conclusion
(il peut y avoir plusieurs conditions mais une seule conclusion). Les règles peuvent être
utilisées soit :
en chaînage avant, le raisonnement se déroule dans le sens habituel, les faits apportent
des conclusions ;
en chaînage arrière, le raisonnement se déroule à l’envers, les conclusions permettent
de déduire les conditions initiales qui ont permis d’observer cet état.
Ce type de système est très intéressant dans le sens où il permet d’exploiter des résultats précédents pour produire de nouveaux résultats. Par contre, l’utilisation d’une
8 http://www.accessdata.com/
36
F IG . 1.18 – Exemple de réseau de neurones multi-couches
base de règles standard est trop restrictive. Une base de règles standard ne peut être
utilisée que dans un unique sens : des conditions vers les conclusions, le comportement est donc séquentiel, alors que nous cherchons à avoir un comportement itératif.
D’autre part, les résultats fournis par la base de règles sont binaires, notre objectif est
plutôt de donner aux enquêteurs des réponses probabilistes. Enfin, les faits et conclusions sont séparés, alors que nous voudrions que, dans certains cas, on puisse avoir des
éléments qui soient à la fois faits et conclusions. C’est pour ces raisons que nous avons
choisi de changer le moteur d’inférences. Nous allons maintenant décrire les moteurs
d’inférences possibles.
1.3.2 Les différents types de moteurs d’inférence
Il existe différents formalismes permettant de créer un moteur d’inférences, en voici
une liste non exhaustive :
– les réseaux de neurones
– les réseaux de Petri
– les arbres de décision
– les réseaux bayésiens
– les diagrammes d’influence
1.3.2.1 Réseaux de neurones
Les réseaux de neurones sont des graphes pondérés orientés dont les nœuds sont
des approximations des neurones biologiques (FIG.1.18). Les réseaux de neurones ont
été introduits par Warren Sturgis McCulloch et Walter Pitts dans [LMMP59] : ils ont
37
montré que ces neurones formels peuvent être utilisés pour effectuer des opérations
logiques, arithmétiques et symboliques complexes. Il existe plusieurs types de réseau :
– les mono-couches, où il y a qu’un seul ensemble de neurones d’entrée et qu’un
seul ensemble de neurones de sortie ;
– les multi-couches, où il y a en plus des deux ensembles précédents une ou plusieurs couches de neurones cachés. qui font l’interface entre les neurones d’entrée et ceux de sortie.
Les synapses désignent les zones de contact entre les neurones et permettent de propager l’information entre les neurones. Les réseaux de neurones théoriques ont eux aussi
besoin de propager l’information entre les neurones. Pour cela, ils utilisent des paramètres pour propager l’information. Ces paramètres sont les coefficients synaptiques
qui commandent la valeur de chacun des neurones. Ces paramètres sont calculés par
des règles, la première utilisée a été celle de Donald Hebb [Heb49] qui permet de modifier la valeur des coefficients synaptiques en fonction de la valeur des neurones qui y
sont reliés. Chaque neurone reçoit des informations des neurones qui lui sont connectés. Il produit une valeur grâce à des fonctions de combinaison qui peuvent être de deux
types : MLP (Multi Layer Perceptron), où la valeur est calculée à partir de la combinaison linéaire entre les différentes valeurs en entrée, et RLP (Radial Layer Perceptron),
où la valeur est calculée à partir de la distance entre les entrées. Il existe un deuxième
type de fonction : les fonctions d’activation (ou fonction de seuillage). Elles permettent
de positionner un neurone aux états actif et non-actif. Plusieurs fonctions peuvent être
utilisées dans ce but, notamment la fonction sigmoïde, la fonction tangente hyperbolique et la fonction discriminante de Kronecker. La phase d’apprentissage, permettant
de s’adapter aux données à traiter, peut être réalisée suivant différentes stratégies : le
mode supervisé ou non (on force ou pas le réseau à converger vers un état final précis)
et le sur-apprentissage (spécialisation du réseau). Les réseaux de neurones sont bien
adaptés à des problèmes dans lesquels le vecteur d’entrée est de taille fixe.
1.3.2.2 Cartes de Kohonen
Les cartes de Kohonen [Koh89] (ou cartes auto-organisatrices de Kohonen) sont
aussi inspirées du vivant. Dans de nombreuses zones du cortex cérébral, certains neurones activés ont tendance à faire réagir les neurones voisins. L’idée de Kohonen consiste à coder des motifs d’une image présentés en entrée tout en conservant la topologie de l’espace d’entrée (Figure 1.19). L’apprentissage utilise une base d’exemples.
Chaque exemple est présenté au réseau, on recherche quel neurone a la sortie la plus
élevée, puis les vecteurs de poids de certains neurones sont mis à jour : celui du neurone gagnant et ceux des neurones voisins. La reconnaissance se fait par la présentation
d’un nouveau vecteur d’entrée, qui fait réagir un neurone particulier, le résultat correspondant à l’étiquette associée au neurone vainqueur. Le résultat final est calculé par
comptage de toutes les étiquettes du réseau après la présentation de tous les vecteurs
d’entrée.
38
Carte
de
Kohonen
Entrées
F IG . 1.19 – Exemple de carte de Kohonen
F IG . 1.20 – Exemple de réseau de Petri
1.3.2.3 Réseau de Petri
Un réseau de Petri N = (P, T, L) est un graphe orienté biparti et alterné [Pet62].
Il est défini sur deux ensembles finis et distincts de sommets : les places P et les transitions T . Les liens, ou flèches L, relient les places aux transitions et les transitions
aux places en suivant la relation L ⊂ (P × T ) ∪ (T × P ) (FIG. 1.20). Chaque place
peut contenir de 0 à n jeton(s), ce nombre variant à chaque état du graphe. Les jetons
se déplacent de place en place par tirage des transitions. De base, une transition est
franchissable si et seulement si toutes les places en amont possèdent au moins un jeton. Il existe de nombreuses variantes des réseaux de Petri : les réseaux autonomes qui
décrivent des systèmes où l’on ne connaît pas les instants de franchissements des transitions ; les réseaux non-autonomes qui décrivent des systèmes où les franchissements
sont conditionnés par des événements externes ou par le temps ; les réseaux de Petri
continus pour lesquels le marquage des places peut avoir une valeur réelle ; les réseaux
de Pétri colorés, etc.
39
Température < 37,5
oui
Gorge irritée
oui
non
malade
non
malade
bien portant
F IG . 1.21 – Exemple d’arbre de décision
1.3.2.4 Arbres de décision
Les arbres de décision sont des graphes où chacun des nœuds représente une observation ou un test à effectuer (par exemple [Température < 37,5] ou [Gorge
irritée]) et où chacune des feuilles représente une conclusion (la classe) au problème posé (cf. FIG. 1.21). Même si les arbres de décision sont utilisés pour faire de
la classification, les résultats peuvent être interprétés comme des déductions. Leur exploitation se fait en deux étapes :
1. construction d’un modèle sur les données dont la classe est connue (training data
set) ;
2. classification des données suivantes.
Il existe plusieurs algorithmes d’apprentissage, chacun d’eux ayant deux phases : la
phase d’expansion, où l’on construit l’arbre proprement dit, et la phase d’élagage où
l’on supprime les branches pour essayer de diminuer et simplifier les grands arbres.
Les deux algorithmes les plus connus sont :
CART de Breiman, Friedman, Olshen et Stone [BFOS84] : il permet d’inférer sur des
arbres binaires (qui ne possèdent que deux classes, par exemple : oui et non).
C4.5 de Quinlan et Rivest [QR89] : c’est une amélioration de l’algorithme ID3 développé par Quinlan en 1983 ; qui permet d’inférer n’importe quel type de classe
(binaire, qualitative ou continue).
Le problème des arbres de décision est que lorsqu’il manque des observations on se
retrouve dans une situation bloquante, c’est-à-dire que l’on ne peut plus progresser
dans l’arbre tant que l’on n’a pas observé le phénomène. Ceci peut être un handicap
pour l’analyse forensique puisque l’on ne possède pas toujours toutes les données.
40
C
A
B
D
F IG . 1.22 – Exemple de réseau bayésien
D = V rai
D = F aux
B = V rai
X1 %
X3 %
B = F aux
X2 %
X4 %
TAB . 1.5 – Table de probabilité associée aux nœuds B et D
1.3.2.5 Réseaux bayésiens
Les réseaux bayésiens sont des graphes acycliques composés de nœuds (appelés
aussi variables) et d’arcs orientés [NWL+ 04]. Les nœuds représentent des variables
aléatoires qui modélisent des paramètres du système étudié et les arcs des relations de
causalité entre ces paramètres. Dans la figure 1.22, l’arc entre les nœuds A et B signifie : « La connaissance que j’ai de A détermine la connaissance que j’ai de B ». Cette
détermination peut être stricte si l’un des nœuds a une valeur fixée ou n’être qu’influente si aucune des valeurs n’est fixe. Bien que les arcs soient orientés, le transfert
d’information existe dans les deux sens : la connaissance de A influe sur la valeur de
B, mais si on connaît B, alors on peut connaître la valeur de A sous forme de probabilité. Chaque arc s’associe à une table de probabilité reliant les différents nœuds. Si
les nœuds de la figure 1.22 peuvent avoir comme valeur Vrai ou Faux, alors la table de
probabilité pour la relation entre les nœuds B et D est représentée par le tableau 1.5 et
la table de probabilité pour la relation entre les nœuds A, B et C est représentée par le
tableau 1.6.
Un réseau bayésien est défini formellement par :
– un graphe acyclique orienté G tel que G = (V, E), (V étant l’ensemble des nœuds
B = V rai
B = F aux
A = V rai
C = V rai C = F aux
X5 %
X6 %
X9 %
X10 %
A = F aux
C = V rai C = F aux
X7 %
X8 %
X11 %
X12 %
TAB . 1.6 – Table de probabilité associée au nœud B
41
de G et E l’ensemble des arcs de G) ;
– un espace probabilisé fini (Ω, Z, p) (avec Ω un ensemble fini non vide, Z un
ensemble d’événements et p la probabilité) ;
– un ensemble de variables aléatoires V associées aux nœuds du graphe et définies
sur (Ω, Z, p) tel que :
p(V1 , V2 , · · · , Vn ) =
n
Y
i=1
p(Vi | C(Vi ))
où p(V1 , V2 , · · · , Vn ) représente les probabilités jointes de V1 et V2 et · · · et Vn
et où C(Vi ) sont les causes (parents) de Vi dans G.
Dans le cas de 2 variables aléatoires A et B définies sur un même ensemble Ω, ces
probabilités jointes peuvent se définir ainsi :
PAB : DA × DB 7−→ [0, 1]
(a, b)
7−→ PAB (a, b) = P(A = a ∩ B = b)
= P(ω ∈ Ω | A(ω) = a ∧ B(ω) = b)
avec DA le domaine de définition de la variable aléatoire A. Cette définition peut se
généraliser à tout ensemble fini U = X1 , . . . , Xn de variables aléatoires défini sur le
même ensemble Ω :
⊗
PU : i∈1,...,n
D Xi
7−→ [0, 1]
u = (x1 , . . . , xn ) 7−→ PU (u) = P(∩i∈1,...,n Xi = xi )
∧
= P(ω ∈ Ω | i∈1,...,n
Xi (ω) = xi )
Les probabilités jointes permettent de caractériser un système en décrivant chacune des
variables aléatoires du réseau.
Les probabilités conditionnelles permettent de caractériser un réseau bayésien en
fonction des différentes variables aléatoires appartenant à ce réseau. Une probabilité
conditionnelle permet de définir la probabilité d’une variable aléatoire sachant la valeur
d’une autre variable. Par exemple, soient A et B deux variables aléatoires appartenant
à l’ensemble Ω : pour tout a ∈ DA et b ∈ DB la probabilité conditionnelle associée
p(A | B) s’écrit P (A | B) = P (A = a | B = b) = x et se lit : la probabilité que
la variable A soit égale à a sachant que la variable B est égale à b est égale à x. Ceci
implique la loi fondamentale des réseaux bayésiens :
P (a, b) = P (a | b) ∗ P (b)
c’est-à-dire qu’en généralisant, si B = b :
P (A, b) = P (A | b) ∗ P (b)
Ceci peut se généraliser à plusieurs variables. Soit un ensemble de variables aléatoires
(Ai )i∈1,...,n sur le même ensemble :
P (a1 , . . . , an ) = P (a1 ).P (a2 , . . . , an | a1 )
=P
Q(a1 ).P (a2 | a1 ).P (a3 , . . . , an | a1 , a2 )
= ni=1 P (ai | a1 , . . . , ai−1 )
On obtient alors le théorème de Bayes si p(b) est strictement positif :
P (a | b) =
P (b | a).P (a)
P (b)
42
et plus généralement :
P (a | b, c) =
P (b | a, c).P (a | c)
P (b | c)
Cette définition peut se résumer de la façon suivante :
loi a priori
P (A | B, C)
∝
∝
loi a priori
P (A | C)
×
×
vraisemblance
p(B | A, C)
Le sigle ∝ signifie "proportionnelle à".
La difficulté principale est que le calcul d’un réseau bayésien est en général un
problème NP-complet [Coo90]. Cette complexité est fortement dépendante du type de
réseau calculé. Si le réseau est simplement connecté (maximum un seul arc montant et
un seul arc descendant par nœud), alors l’inférence exacte pourra être possible même si
le réseau est grand. Par contre, si le réseau est quelconque, l’inférence exacte ne pourra
pas être envisagée. Ce problème peut être résolu avec l’indépendance conditionnelle.
Elle a été étudiée en 1979 par Dawid [Daw79], qui donne la définition suivante :
Soient un univers Ω et un ensemble V de variables aléatoires sur Ω. Soient X, Y, Z ⊂
V 3 . X est indépendant de Y conditionnellement à Z (noté X ⊥ Y | Z) si et seulement
si ces ensembles vérifient :
X ⊥ Y | Z ⇐⇒ P (X | Y, Z) = P (X | Z)
Si Z = ∅, on obtient alors l’indépendance marginale :
X ⊥ Y ⇐⇒ ∀x ∈ Dx , P (Y | X = x) = P (Y )
Cela signifie que si l’on connaît l’indépendance conditionnelle entre une variable X
(respectivement Y ) et Z, alors la connaissance sur Y (respectivement X) n’est pas nécessaire si l’on connaît la valeur de Z. Cela peut réduire grandement les calculs : la
représentation en taille mémoire de P (X | Y, Z) est 2|X| .2|Y | .2|Z| alors que la représentation en taille mémoire de P (X | Z) est 2|X| .2|Z| .
1.3.2.6 Diagrammes d’influence
Les diagrammes d’influence ont été créés par John Diffenbach en 1982 [Dif82]
et sont des réseaux bayésiens augmentés. Ces diagrammes comportent trois types de
nœuds. Les nœuds aléatoires représentent des variables de la modélisation qui peuvent
prendre une valeur dépendante de la situation examinée, mais indépendante de l’utilisateur : ce sont les entrées du système. Les nœuds de décision représentent des variables de la modélisation qui sont, contrairement aux nœuds aléatoires, dépendants des
décisions de l’utilisateur. Enfin, les nœuds de gain représentent les résultats de la décision. Les flèches reliant les nœuds ont un rôle différent selon les nœuds qu’ils relient.
Lorsqu’une flèche pointe vers un nœud aléatoire ou un nœud de gain, elle est appelée
relevance (ou pertinence). Cette flèche indique que la valeur du nœud pointé (le nœud
successeur) dépend de la valeur du nœud origine (le nœud prédécesseur). Lorsqu’une
flèche pointe d’un nœud de décision (ou d’un nœud aléatoire) vers un autre nœud de
décision, cela forme une séquence : le nœud prédécesseur doit avoir une valeur fixée
pour passer au calcul du nœud suivant.
base
règles
de
43
réseau
de
neurones
réseau de
Petri (standard)
arbre de
décision
réseau
bayésien
diagramme
d’influence
apprentissage
oui
oui
non
non
oui
oui
comportement
séquentiel
séquentiel
séquentiel
séquentiel
itératif
itératif
sortie
binaire
binaire
entière
binaire
continu
continu
variable
fixe
fixe
fixe
variable
fixe
variable
fixe
fixe
fixe
variable
fixe
nombre
d’entrées
nombre
sorties
de
TAB . 1.7 – Synthèse sur les différents moteurs d’inférences
1.3.3 Motivations du choix retenu
Le tableau 1.7 fait la synthèse des différents types de moteurs d’inférence de la
littérature. Notre choix a été fait suivant plusieurs critères. Comme nous l’avons dit en
introduction, nous souhaitons pouvoir exploiter les résultats des enquêtes précédentes.
Un enquêteur a un comportement que l’on peut qualifier d’itératif, le moteur d’inférences doit donc avoir le même comportement. Pour que l’utilisateur puisse avoir une
vue assez précise de la situation, il est intéressant que les résultats soient présentés classés selon leur niveau de vraisemblance. Enfin un certain nombre de données peuvent
être vues comme des entrées du système ou comme des sorties. C’est par exemple le
cas des logiciels saisis en entrée dans la description de la configuration et dont la valeur
en sortie est calculée en fonction de leur niveau de vulnérabilité.
1.3.4 Mise en oeuvre des réseaux bayésiens
1.3.4.1 Construction
Avant de pouvoir exploiter un réseau bayésien, il faut définir ses variables, sa structure et les tables de probabilités. Cette structure peut être construite de deux manières :
– soit on fait appel à des experts du domaine, qui définissent à la main les relations
entre les nœuds et les tables de probabilités associées.
– soit on utilise des techniques mathématiques qui permettent de créer de façon
automatique le réseau à partir d’une base de cas.
Nous décrivons dans ce paragraphe la deuxième solution. La construction s’effectue en
deux étapes : la mise en place de la structure et la recherche des paramètres.
Apprentissage de la structure Il existe trois grands types d’apprentissage : apprentissage de la causalité, apprentissage basé sur un score et incorporation de connaissances.
44
Apprentissage de la causalité Ces algorithmes sont basés sur le principe suivant :
1. construction d’un graphe non orienté décrivant les relations entre les variables
(par des tests d’indépendance conditionnelle) ;
2. détection des structures en V (V-structures9 ) ;
3. propagation de l’orientation de certains arcs.
Les algorithmes basés sur ce principe sont notamment IC et IC* de Pearl et Verma
[PV91], SGS et PC de Spirtes, Glymour et Scheines [SGS91] et l’algorithme BN-PC de
Chang et al. [CBL97a, CBL97b, CGK+ 02]. Dans SGS, les auteurs créent un réseau non
orienté et complètement relié. Ils testent alors toutes les dépendances conditionnelles
pour supprimer des arêtes puis examinent les V-structures et propagent l’orientation des
arètes. L’algorithme PC des mêmes auteurs essaye d’améliorer l’algorithme précédent,
en ne calculant pas toutes les dépendances conditionnelles pour limiter les calculs. Les
algorithmes IC et IC* de Pearl et Verma construisent d’abord un graphe non orienté et
non relié. L’objectif de ces algorithmes est de relier ce graphe pas à pas par des tests
d’indépendance conditionnelle. En ce qui concerne l’algorithme BN-PC de Chang et
al., la construction d’un réseau s’effectue en trois étapes : 1) recherche de l’arbre de
recouvrement maximal (MSWT10 ) qui permet d’obtenir un graphe non orienté mais
relié, 2) recherche des arêtes par un minimum de tests d’indépendance conditionnelle
et 3) recherche des arêtes inutiles par une deuxième série de tests.
Apprentissage basé sur un score Ces algorithmes se basent soit sur le calcul
d’une structure de réseau qui va maximiser un score soit sur le calcul de plusieurs structures pour trouver ensuite la meilleure. Ces algorithmes doivent en principe effectuer
leur recherche sur toutes les structures possibles, mais, pour limiter le nombre de structures recherchées, on peut utiliser les algorithmes suivants : restriction de l’espace des
arbres (par exemple MSWT, Chow et Liu [CL68], Heckerman [HGC94]), ordonnancement de variables (par exemple : K2, Cooper et Herskovits, [CH92]), recherche gloutonne par Chickering, Geiger et Heckerman [CGH95]. L’algorithme MSWT recherche
un arbre qui inclut tous les nœuds et qui maximise un score. Il y a différentes méthodes
pour calculer le score. Chow et Liu utilisent un score basé sur un critère d’information
mutuelle, alors qu’Heckerman utilise un score quelconque, localement décomposable.
L’avantage d’un tel algorithme est que la solution trouvée est proche de l’arbre original. Par contre la recherche peut être longue puisque l’on va parcourir tous les arbres
jusqu’à maximiser le score. De plus, l’algorithme va forcer certaines variables à appartenir au graphe, même si celles-ci ne sont pas vraiment utiles au problème posé.
L’algorithme par ordonnancement de variables permet de rechercher seulement les arcs
intéressants en ajoutant une relation d’ordre sur les nœuds : si A est avant B, alors il ne
peut pas y avoir d’arc de B vers A. Ceci réduit considérablement le nombre de structures possibles (par exemple, si l’on a 5 nœuds, il y a alors 1024 structures possibles
contre 29.281 dans le cas habituel). La recherche gloutonne recherche toutes les combinaisons possibles pour une variable, puis supprime les combinaisons qui ont le score
9 relation
entre une variable qui possède 2 parents
Weight Spanning Tree
10 Maximum
45
le plus faible. La recherche gloutonne demande cependant à ce que le réseau ait une
structure définie à l’avance (donnée par un expert ou calculée par MSWT). En résumé,
l’apprentissage de la causalité permet d’obtenir des structures très proches des structures originales, permettant le calcul d’une structure qui se rapproche plus rapidement
d’une structure convenable (qui peut être exploitée). Malheureusement, le temps de
calcul est plus long que l’apprentissage basé sur un score.
Incorporation de connaissances Cette technique permet d’apporter un à-priori
sur la structure du réseau. Le réseau peut avoir été construit partiellement par un expert
puis calculé automatiquement grâce à la base de cas par les algorithmes cités précédemment.
Apprentissage des paramètres Après avoir construit la structure du réseau, il faut
calculer les tables de probabilités. Il y a trois situations différentes : soit la base de cas
est complète (c’est-à-dire que pour chaque cas, toutes les variables ont une valeur), soit
la base de cas est incomplète (sur certains cas de la base, il manque quelques données),
soit la base est très incomplète.
Base de cas complète Il y a deux techniques possibles. On peut soit utiliser un
algorithme statistique (maximum de vraisemblance) où la probabilité d’un événement
est calculée par rapport à sa fréquence d’apparition dans la base de cas, soit utiliser une
estimation bayésienne, qui se base sur le fait que les variables ont été observées ou pas.
Base de cas incomplète Dans le cas d’une base de cas incomplète, les deux techniques précédentes peuvent être utilisées avec quelques modifications. Pour l’apprentissage statistique et pour l’apprentissage bayésien, il faut rajouter une étape au départ :
l’estimation des paramètres manquants par calcul de leur moyenne.
Base de cas très incomplète Dans ce cas, il faut impérativement faire appel à un
expert qui va fixer la valeur de certains des paramètres. Il se pose alors le problème du
choix de l’expert, de sa familiarité avec les outils probabilistes, etc.
1.3.4.2 Exploitation
Après avoir construit la structure (soit à la main, soit par une base de cas), le réseau
est exploitable.
Les réseaux bayésiens sont a priori mieux adaptés à notre problématique, car plus
robustes lorsqu’il manque des données ou lorsqu’elles sont incertaines, ce qui est le
cas dans la plupart des enquêtes. Les avantages des réseaux bayésiens sont multiples :
– acquisition, rassemblement et fusion des connaissances ;
– représentation et utilisation des connaissances ;
– représentation graphique intuitive, explicite et compréhensible ;
– polyvalence : un réseau bayésien permet d’évaluer, de prévoir, de diagnostiquer
ou d’optimiser des décisions.
46
Dans la suite de cette section, nous allons décrire les deux types d’inférence qui existent,
l’inférence exacte et l’inférence approximative.
Inférence exacte Il y a deux techniques d’inférence exacte. Premièrement, les méthodes de propagation de messages étendues par des algorithmes de coupe [Pea88] qui
utilisent, comme leur nom l’indique, la propagation de messages le long des arcs du
réseau. En faisant des calculs locaux, chaque nœud communique à ses voisins son état
actuel et celui de ses parents. Quand un nœud a toutes les informations nécessaires,
il peut alors calculer sa probabilité marginale. La deuxième technique d’inférence utilise le regroupement de nœuds [LS90]. En modifiant plus ou moins profondément le
graphe (moralisation et triangulation), on peut obtenir plusieurs réseaux simplifiés
(sans cycle) et ainsi utiliser le premier type de méthode (propagation) pour calculer
le réseau global. Ces méthodes dépendent fortement de la structure des graphes.
Inférence approximative L’inférence approximative permet de calculer une valeur
approchée des probabilités d’un réseau bayésien dans un temps raisonnable (le temps
de calcul de la totalité d’un réseau bayésien quelconque est inférieur à quelques minutes
pour un système informatique courant). Il y a deux types de méthodes pour effectuer
une inférence approximative : les méthodes où le calcul est exact mais sur une topologie approchée [Kjæ94] et les méthodes stochastiques (simulations). Les premières
utilisent le fait que soit certains nœuds ne sont que faiblement dépendants (on peut donc
raisonnablement supprimer l’arc entre ces deux nœuds), soit que certains arcs ne propagent pas une information suffisante pour être prise en compte. La deuxième méthode
(méthode stochastique) utilise la simulation pour calculer la valeur des probabilités.
Dans cette méthode, le principe de calcul est le même pour tous les algorithmes :
Pour chacune des passes :
Pour chacun des noeuds :
si on connaît l’état a priori :
ne rien faire
si il n’a pas de parent :
effectuer un tirage conforme à ses probabilités marginales
si tous les parents de ce noeud ont un état déterminé :
effectuer un tirage conforme à la table de probabilité qui le
conditionne
ranger chacune des valeurs aléatoires dans une table
à la fin de toutes les passes, on normalise les valeurs de chaque noeud
Si on connaît la loi à simuler (on est capable de définir l’ordre logique des nœuds),
alors on peut utiliser les algorithmes suivants :
Probabilistic Logic sampling d’Henrion [Hen88]. C’est la première méthode stochastique proposée. Quand des nœuds sont observées, les tirages qui ne sont pas
conformes aux observations sont écartés. Cela réduit grandement les capacités
de cette méthode.
47
Forward sampling d’Henrion [Hen88]. Les tirages se font ici dans l’ordre des nœuds,
les ancêtres en premier. Comme l’algorithme précédent, les tirages non conformes
sont écartés.
Likelihood weighting de Fung et Chang ou Shachter et Peot [FC89, SP89]. Contrairement aux algorithmes ci-dessus, aucun tirage n’est écarté. Par contre, les tirages
qui sont conformes aux observations voient leur importance (score) augmenter,
ce qui permet d’obtenir un algorithme simple qui peut accroître sa précision en
augmentant le nombre de tirages. Cet algorithme est l’un des plus utilisé.
self-importance sampling de Shachter et Peot [SP89]. Cet algorithme révise à chaque
tirage la fonction qui permet d’augmenter l’importance d’un tirage. Cela apporte
une plus grande précision, mais aussi un temps de calcul plus important.
Par contre, si on ne connaît pas la loi à simuler, on peut utiliser des méthodes de type
MCMC (Markov Chain Monte Carlo).
Différences entre ces algorithmes L’inférence exacte permet, comme son nom l’indique, un calcul exact du réseau. Ce calcul ne peut être fait que si la taille réseau n’est
pas trop grande (inférieure à une vingtaine de nœuds) et si la structure du réseau est
simple. Ce type d’inférence ne s’applique donc qu’à des cas bien particuliers.
Par contre, l’inférence approximative impose moins de contraintes sur la taille et la
complexité du réseau. Dans un grand nombre d’algorithmes, il est possible de diminuer
la précision pour augmenter la vitesse de calcul. Les méthodes approximatives sur les
dépendances faibles ont pour objectifs de supprimer les informations non pertinentes et
de se concentrer sur les informations qui ont le plus de poids. Par contre, les méthodes
approximatives stochastiques ont pour objectifs de garder toutes les informations disponibles et de les traiter sur un même pied d’égalité.
1.3.4.3 Exemples d’utilisation
Voici quelques exemples d’utilisation des réseaux bayésiens dans les domaines de
la sécurité, de la sureté des systèmes d’information et de l’analyse forensique.
Système anti-fraude chez AT&T La société AT&T a mis au point un système permettant de détecter la fraude sur son réseau téléphonique [ES95]. Ce système a pour
objectif de détecter les risques élevés de non recouvrement, puis de décider des actions
à entreprendre pour résoudre le problème. Les chercheurs d’AT&T ont utilisé des méthodes différentes pour chaque objectif. Un réseau bayésien est utilisé pour le premier
objectif et des diagrammes d’influence pour le deuxième. La spécificité du réseau bayésien mise en oeuvre est que toutes les variables ne sont pas discrètes. Certaines ont des
valeurs continues, ce qui a amené les chercheurs d’AT&T à créer un algorithme d’apprentissage spécifique.
Système d’aide à la décision de la NASA Lors du lancement d’une fusée, les ingénieurs de la NASA doivent prendre en compte un grand nombre d’informations lorsqu’ils doivent prendre des décisions. Plus le nombre d’informations est grand, plus la
48
réponse est longue à trouver, ce qui peut être dangereux lors de décisions critiques, notamment pour les vies humaines. La NASA a donc mis au point, en collaboration avec
la société californienne Knowledge Industries, un système d’aide à la décision [HB95]
basé sur trois réseaux bayésiens11 . Ce système permet l’affichage de données sur le vol
de la fusée ou la navette selon leur degré de pertinence. L’objectif est de montrer à l’utilisateur le moins de données possible, pour qu’il puisse prendre une décision rapide et
en toute connaissance de cause.
Travaux de Levitt et Laskey Dans [LL00], Tod Levitt et Kathryn Laskey proposent
d’utiliser les réseaux bayésiens pour modéliser le raisonnement d’enquêteurs ou de juristes sur des crimes de sang, et testent cette modélisation sur une affaire bien connue
en France, l’affaire Omar Raddad qui a défrayée la chronique en 1994. L’objectif est de
représenter le raisonnement dans une forme interprétable par un système informatique.
Pour cela, les auteurs ont découpé les phases d’un raisonnement en trois classes : les
hypothèses, les preuves et le contexte. Les hypothèses représentent certains éléments
de l’enquête qui ne sont pas encore prouvés. Par exemple, au début du procès : « Omar
Raddad a tuée Ghislaine Marchal », ou « Marchal a écrit sa phrase avant de mourir ».
Les preuves sont des hypothèses dont la véracité a été démontrée. Par exemple : « la
phrase a été écrite dans un français approximatif » ou « un témoin a parlé avec une
femme autre que Marchal le lundi matin ». Enfin, le contexte représente des conclusions obtenues par analyse ou raisonnement sur une série d’hypothèses. Par exemple :
« il y a d’autres suspects que Omar Raddad » ou « Marchal a été tué dans la cave
de sa maison, dimanche en fin de matinée, par un individu seul qui a utilisé un objet
coupant en métal ». Chaque élément de ces trois classes peut avoir un ou plusieurs
attributs caractéristiques : l’acteur, son rôle, son activité (ce qu’il a fait), la localisation spatiale et temporelle, etc. Après avoir analysé le raisonnement, Levitt et Laskey
proposent d’utiliser les réseaux bayésiens pour effectuer des inférences sur les hypothèses. Chaque hypothèse est représentée par une variable bayésienne et les relations
entre ces variables représentent les relations entre les hypothèses (cf. figure 1.23). Ce
type de réseau permet aux auteurs de représenter graphiquement le poid de différentes
hypothèses les unes par rapport aux autres.
11 les trois réseaux modélisent respectivement le système physique (notamment les capteurs), l’impact
d’une action sur le système et l’opérateur (affichage).
F IG . 1.23 – Sous-ensemble du réseau bayésien de Levitt et Laskey
49
50
Chapitre 2
Présentation de notre approche
2.1 Premier exemple trivial
L’analyse forensique est une discipline où de nombreuses informations sont cachées ou indisponibles selon l’avancée de l’enquête. Par exemple, même si l’on connaît
la configuration d’un système, on ne connaît pas forcément tous les dégâts occasionnés
par l’attaque, ni quelle méthode l’attaquant a utilisée, etc. De plus, lorsque les enquêteurs découvrent de nouveaux indices, cela peut influer sur l’analyse de l’attaque. Les
réseaux bayésiens permettent de répondre à ce type de besoin. On peut créer un réseau
avec les connaissances que l’on a au début de l’enquête (logiciels, vulnérabilités, etc.),
puis faire évoluer les connaissances de ce réseau. A mesure que les connaissances augmentent, le réseau est capable de donner des informations de plus en plus précises sur
le mode opératoire de l’attaquant.
De plus, en informatique, et notamment en analyse forensique, tout n’est pas binaire. La plupart des indices découverts par les enquêteurs amène à des conclusions
qui ne sont pas sures tant que l’on n’a pas de preuve. Par exemple, la découverte d’un
changement de configuration dans un fichier standard du système d’exploitation permet
de penser que l’attaquant avait peut-être les droits administrateur sur cette machine.
Mais il a pu aussi utiliser une faille dans le système d’exploitation pour transformer ce
fichier (utilisation d’un exploit). Les réseaux bayésiens peuvent apporter des réponses
probabilistes à ce type de questions. Un réseau bien configuré va pouvoir présenter aux
enquêteurs un classement des attaques les plus probables, un classement des logiciels
les plus vulnérables, etc. La suite de cette section décrit un exemple trivial des résultats
que peut produire un réseau bayésien.
On suppose que les possibilités d’attaque sont peu nombreuses (2 attaques possibles, soit 2 variables) et que le nombre de logiciels installés est aussi réduit (Serveur
Web Apache, une suite Office et le noyau du système d’exploitation, soit 3 variables).
Le réseau bayésien est décrit sur la figure 2.1. On suppose qu’un administrateur système constate que le serveur Web Apache (A) a été défiguré (D). Il y a deux causes
possibles à cet incident :
– l’attaquant a utilisé un exploit (E) sur l’un des logiciels ;
51
CHAPITRE 2. PRÉSENTATION DE NOTRE APPROCHE
52
F IG . 2.1 – Un exemple de réseau bayésien
– l’attaquant a volé le mot de passe administrateur (U ) (usurpation d’identité).
Un réseau bayésien bien formé va proposer des hypothèses sous forme de probabilités :
il y a X% de chance que l’attaquant ait utilisé l’exploit (E) sur le serveur (A), la
probabilité étant donnée par le théorème de Bayes :
P (E | A) =
P (E, A)
P (A)
avec :
– P (E | A) la probabilité que l’attaquant ait utilisé l’exploit (E) sachant que l’attaquant a utilisé le serveur Web (A)1 ;
– P (E, A) la probabilité d’avoir un exploit (E) et un serveur Web (A) ;
– P (A) la probabilité de l’exploit (A).
Dans notre exemple, ayant observé un défigurement D = vrai, on en déduit (Tableau 2.1) que la probabilité que l’attaquant ait utilisé un exploit via le serveur Web A
est
P (E = vrai | A = vrai, D = vrai) = 70%
alors que la probabilité de l’usurpation via le serveur Web A est
P (U = vrai | A = vrai, D = vrai) = 35%
On en conclut que l’enquêteur doit vérifier dans un premier temps si il y a eu une attaque de type exploit sur la machine et sur le serveur Web. S’il ne trouve pas cette
1 les
valeurs de cette variable sont vrai = attaqué ou faux = pas attaqué
2.2. INTRODUCTION DE LA NOTION DE PLAN D’INVESTIGATION
P (E | A, D)
E = vrai
E = f aux
P (U | A, D)
U = vrai
U = f aux
D = vrai
A = vrai A = f aux
70%
20%
30%
80%
D = vrai
A = vrai A = f aux
35%
10%
65%
90%
53
D = f aux
A = vrai A = f aux
50%
10%
50%
90%
D = f aux
A = vrai A = f aux
60%
50%
40%
50%
TAB . 2.1 – Table des probabilités conditionnelles pour la variable Exploit E et Usurpation U
attaque, alors il devra vérifier s’il y a eu une attaque par usurpation d’identité sur le
serveur Web. On pourrait effectuer le même raisonnement pour chacun des logiciels
installés sur le système. Grâce à ce réseau bayésien, l’enquêteur peut mettre des priorités sur ses investigations.
2.2 Introduction de la notion de plan d’investigation
2.2.1 Modèle général d’une enquête
Lors d’une enquête informatique, les enquêteurs doivent répondre à un certain
nombre de questions. On peut les représenter sous la forme d’une pyramide à 4 sommets (FIG. 2.2). A la base, on trouve les questions où, quoi et comment et au sommet,
l’objectif final, qui. Une enquête commence à la base de cette pyramide : les enquêteurs tentent de répondre aux questions « Où a eu lieu le délit ? », « Qu’est-ce qui a
été observé sur les systèmes compromis ? (quoi) » et « Comment cela a-t-il pu avoir
lieu ? ». Au fur et à mesure des avancées de l’enquête, des éléments (informations,
indices ou preuves) permettent d’ajouter des briques à la pyramide décrite ci-dessus.
Cette progression est schématisée par le chemin qui parcourt les faces de la pyramide
(FIG. 2.2). Il reste une dernière question pourquoi, que nous ne traiterons pas pour
les raisons suivantes. Premièrement, cette question fait référence à la logique de l’attaquant et non à la logique de l’attaque. La logique de l’attaquant n’est pas toujours
facile à appréhender par des caractéristiques numériques ou physiques. D’autre part, le
rôle d’un enquêteur est de répondre aux trois premières questions et non à la question
pourquoi ; c’est au tribunal de répondre à cette question.
Les trois questions de base (où, quoi et comment) impliquent chacune des types
d’investigation différents. La question où correspond au domaine physique : où sont
et quels sont les systèmes compromis, comment sont-ils interconnectés ou quels sont
leurs relations, etc. La question quoi correspond au domaine logique : quels sont les
fichiers qui peuvent contenir des indices ou des preuves et quels sont les logiciels attaqués. Enfin, la question comment correspond au domaine humain : comment l’attaquant a pû réaliser cette ou ces attaques. Chacun de ces domaines a ses propres outils
pour retrouver des éléments de preuves. Dans le domaine physique, les enquêteurs vont
54
QUI
COMMENT
QUOI
OU
F IG . 2.2 – Les quatre questions associées à une enquête
analyser le type de système utilisé ainsi que les interconnexions ou les relations entre
systèmes. Cela permet, entre autres, de retrouver le chemin emprunté par l’attaquant,
ou, au moins, les points d’entrée éventuellement accessibles par cet attaquant. Dans le
domaine logique, les enquêteurs vont devoir analyser des données numériques (fichiers
d’audit, variables système, etc.). C’est la partie la plus longue de l’enquête, car un système informatique génère énormément de traces et les indices éventuels sont noyés
dans cette masse d’information. Le domaine humain est le plus complexe puisque l’on
touche à la manière de procéder des attaquants. Pour expliquer le modus operandi,
il faut bien connaître les systèmes et leurs vulnérabilités et comprendre ce qui a été
observé sur le système compromis.
Notre approche tente de prendre en compte ces différentes dimensions. Lorsqu’un
enquêteur arrive sur les lieux d’un délit informatique, il collecte des faits sur lesquels
il va s’appuyer pour débuter son enquête. Ces faits peuvent être du type :
– défigurement d’un site Web ;
– message à caractère raciste, calomnieux, etc. ;
– suppression de données (mails, fichiers, etc.) ;
– déni de service (serveur de mail, serveur Web, etc.) ;
– activités inhabituelles sur le réseau ;
– scans réseaux ;
– alertes d’IDS ;
– etc.
Des outils sont ensuite utilisés pour analyser ces faits et obtenir de nouvelles informations qui permettront d’avancer la compréhension du délit. Comme le montre la figure
2.3, l’enquêteur doit effectuer ces analyses en boucle, chaque résultat permettant d’effectuer de nouvelles investigations.
Ces analyses en boucle vont pouvoir être effectuées par un système expert. Un sys-
55
F IG . 2.3 – La relation entre l’enquêteur et ses outils forensiques
tème expert est composé d’une base de connaissances et d’un moteur d’inférences. La
base de connaissances contient les faits observés par les enquêteurs et leurs connaissances. Celles-ci concernent ici les attaques connues et les vulnérabilités des systèmes,
venant des résultats d’enquêtes précédentes. Le moteur d’inférences modélise le raisonnement de l’enquêteur : il est chargé d’analyser les connaissances ainsi que les
résultats des outils pour proposer des pistes à suivre. Ce moteur d’inférences utilise les
réseaux bayésiens décrits au paragraphe 1.3.2.5 et fournit des résultats sous forme de
probabilités.
2.2.2 Définition d’un plan d’investigation
Nous définissons comme plan d’investigation le réseau bayésien modélisant un système informatique pour une attaque particulière (le système compromis peut avoir été
attaqué plusieurs fois, il y aura autant de plans d’investigation que d’attaques). La figure 2.3 montre la superposition de ces plans d’investigation par une superposition
de rectangles autour du moteur d’inférences. Le réseau bayésien décrit la configuration du système et son état (dégâts observés, attaques subies, etc.). Comme le montre
la figure 2.4 (page 60), nous organisons ces variables (encadrées en pointillés) en 6
classes : l’adresse source, les observations, les logiciels, les attaques, les actions et les
techniques d’investigation.
Les dégâts constatés (loss) : correspondent aux types de dégâts constatés par les enquêteurs en arrivant sur les lieux du délit. Ces variables sont binaires : vrai,
56
les dégâts sont observés ou faux, les dégâts ne sont pas observés. Ces dégâts2
sont au nombre de 6 et correspondent aux Loss Types de la base de vulnérabilités
ICAT (cf. Annexe A).
On peut noter que chacune de ces variables est indépendante : chacune défiSecurity protection
,→
,→
Obtain_all_priv
Obtain_some_priv
,→
Sec_Prot_Other
Confidentiality
Integrity
Availability
Dégradation de la protection (obtention de privilèges)
Obtention des droits administrateur
Obtention des droits d’un utilisateur
standard
Obtention des droits système (autre
qu’utilisateur et administrateur)
Perte de confidentialité (vol d’informations)
Perte d’intégrité (changement, réécriture de données)
Déni de service
TAB . 2.2 – Les variables dégâts loss
nit une observation qui ne peut être décrite par aucune des autres observations.
Cependant, nous pouvons noter que certaines variables peuvent en influencer
d’autres. Par exemple, l’obtention des privilèges administrateur peut impliquer
une perte de confidentialité.
La configuration du système (soft) : correspond aux logiciels installés sur le système
compromis. Ces variables ont deux états possibles : vrai lorsque l’attaquant a
effectivement utilisé le logiciel pour pénétrer le système et faux sinon. Chaque
logiciel est caractérisé par le nom de l’éditeur, le nom du logiciel et son numéro
de version.
L’adresse (address) : correspond à la provenance de l’attaque. Cette classe ne contient
qu’une seule variable qui a trois valeurs possibles : local, la provenance de l’attaque est locale, l’attaquant était soit connecté physiquement à la machine, soit
connecté via un accès distant ; interne, l’attaquant agit depuis le réseau interne
de l’entreprise (DMZ3 comprise) ; externe, l’attaquant agit depuis l’extérieur du
réseau de l’entreprise. Par exemple, un attaquant qui utiliserait son propre PC
portable qui attaquerait un entreprise via son réseau Wifi viendrait de l’extérieur
(externe). Par contre, un attaquant qui attaquerait la même entreprise via son
serveur Web (en l’ayant préalablement compromis) viendrait de l’intérieur du
réseau (interne).
Les attaques (attack) : correspondent aux actions nécessaires pour réaliser une intrusion dans un système, pour l’endommager ou pour commettre tout acte répréhensible (une liste est donnée dans le tableau 2.3). Ces variables ont deux états
possibles : vrai lorsque l’attaquant a effectivement utilisé cette attaque pour
2 en
gras dans le tableau 2.2
Zone
3 DeMilitarized
57
pénétrer le système et faux sinon. La nomenclature présentée est celle utilisée
par le CELAR pour plusieurs projets.
Les actions complémentaires (action) : correspondent aux actions qui ne sont pas
nécessaires à l’attaque ; mais qui sont d’une certaine utilité pour l’attaquant,
comme par exemple pour se cacher (une liste est donnée dans le tableau 2.4).
Ces variables ont deux états possibles : vrai lorsque l’attaquant a effectivement utilisé cette action sur le système et faux sinon.
Toutes ces variables (attaques et actions) sont des éléments génériques et atomiques. Toute attaque complexe peut être représentée par ces variables. Elles
ne sont pas non plus décomposables à notre niveau d’abstraction. Par exemple,
l’utilisation d’un mot de passe volé en utilisant une sonde réseau (sniffer) peut
se représenter par la séquence suivante :
[ net_listen → usurp → attribute ]
De même, la diffusion d’un virus ou d’un cheval de troie par une série de sondes
réseau peut se définir ainsi :
[
broadcast → scan_use → exploit → parasit ]
On peut considérer que les variables attaque et action sont dépendantes les unes
des autres car, comme dit ci-dessus, elles sont atomiques et génériques et donc
pour représenter une attaque réelle, nous avons besoin de mettre en séquence
plusieurs variables.
Les techniques d’investigation (tech) : correspondent aux types de techniques ou méthodes utilisables par les enquêteurs pour trouver des indices ou des preuves (une
liste est donnée dans le tableau 2.5). Ces variables ont deux états possibles :
vrai lorsque le moteur recommande l’utilisation de cette technique et faux
lorsque cette technique n’apporte rien à l’enquête. Ces variables couvrent a priori
l’ensemble des techniques utilisables et utilisées par des enquêteurs professionnels, incluant l’analyse des supports, les recherches physiques (sections 1.1.1 et
1.2.2).
La figure 2.4 décrit les liens entre ces 5 classes. La figure ne représente pas un réseau
bayésien mais juste les relations entre les différents types de variables. La réunion (dans
les losanges de la figure 2.4) des relations de certaines variables permet d’obtenir de
nouvelles hypothèses sur d’autres variables du moteur. Même s’il n’y a pas de notion de
nœud d’entrée ou de sortie dans les réseaux bayésiens, nous caractérisons quand même
les nœuds comme étant en entrée ou en sortie, pour montrer les flux d’information dans
le réseau. Les nœuds loss (partie observation) ne seront vus que comme des entrées du
système, d’où la présence des trois flèches dirigées vers le bas. Par contre, les nœuds
soft (partie configuration) seront à la fois des nœuds d’entrée et des nœuds de sortie.
En effet, dans un premier temps, il est nécessaire de savoir quelle est la configuration
du système attaqué pour connaître ses vulnérabilités donc la configuration est intégrée
dynamiquement au moteur. Ensuite, l’objectif étant de trouver quel est le logiciel qui
a été utilisé pour l’attaque (via la vulnérabilité utilisée), ces nœuds deviennent alors
58
Nom de la variable
listing
net_listen
decrypt
exploit
bypass
broadcast
chaff
embezzlement
listen
parasit
degrade
diversion
intercept
usurp
bounce
troyen
repeat
blocking
overrun
brut_force
control
Description
obtenir des informations par des moyens directs ou indirects (lister par exemple des entrées DNS)
écouter le réseau
utiliser une attaque par dictionnaire ou par force brute
pour déchiffrer un message
utiliser un exploit (Buffer Overflow)
contourner un élément de sécurité
trouver un système en envoyant des paquets en diffusion
utiliser un faux serveur pour voler des données
détourner un flux d’information de façon furtive
(exemple : Man In the Middle)
écouter les événements d’un système
transformer les fonctionnalités d’un logiciel
dégrader le service d’un système (exemple : défigurement
d’une page web)
utiliser une diversion
intercepter des données
usurper l’identité de quelqu’un sans son accord
rebondir sur plusieurs systèmes avant d’attaquer
utiliser un cheval de troie
répéter des paquets réseaux (exemple : scanning sweeping)
bloquer les fonctionnalités d’un service réseau
saturation comme par exemple : DoS, DDoS
attaquer par force brute
intercepter et bloquer les communications d’un système
TAB . 2.3 – Les variables attaques attack
Nom de la variable
msg
attribute
scan_use
encrypt
hidden_channel
infection
cnx_illic
trap
invert_trap
inhib_detect
del
login_inst
59
Description
envoyer un message pour signer l’attaque
augmentation des privilèges
trouver les services d’un système par des scans réseau
chiffrer ses données
utiliser un canal caché
ajouter des informations cachées dans un fichier
(exemple : stéganographie)
se connecter illicitement à un système
utiliser une porte cachée (le système compromis est un
serveur)
utiliser une porte cachée inversée (le système compromis
est un client)
inhibition de la détection (exemple : IP Spoofing)
supprimer des données
installer un nouveau compte utilisateur
TAB . 2.4 – Les variables action action
Nom de la variable
image
syst_check
net_check
syst_var
retrieve
net_log
int_topo
ext_topo
comm
physic
Description
création de l’image d’un média
vérification des fichiers du système (audit, configuration,
etc.)
vérification des fichiers réseau (pare-feu, etc.)
vérification des variables système (login, processus, etc.)
récupération des fichiers cachés ou supprimés, analyse de
fichiers binaires, etc.
utilisation d’une sonde réseau pour surveiller les actions
de l’attaquant
vérification de la topologie du réseau compromis
vérification des interconnexions du réseau compromis
analyse des communications comme les logs IRC, les
mails, etc.
analyse des accès physiques à un système ou un bâtiment.
TAB . 2.5 – Les variables techniques d’investigation tech
60
F IG . 2.4 – Les flux d’information dans le moteur d’inférences
2.3. CONSTRUCTION D’UN PLAN D’INVESTIGATION
61
des nœuds de sortie. Les nœuds attack et action (parties attaque et action) sont aussi
des nœuds d’entrée et des nœuds de sortie, mais pour des raisons différentes. Ils seront
d’abord des nœuds de sortie, car lors de la première phase d’une enquête, l’enquêteur
voudra savoir quel type d’attaque a pu avoir lieu sur le système, connaissant sa configuration. Au fur et à mesure de l’enquête, les observations et les indices permettent de
confirmer la présence de certaines attaques. Cette connaissance peut alors être entrée
dans le réseau. Les nœuds attack et action sont donc aussi des nœuds d’entrée. Enfin les nœuds tech (partie technique d’investigation) sont exclusivement des nœuds de
sortie. Le fait de savoir que les enquêteurs ont utilisé telle technique ne permet pas de
comprendre l’attaque et donc ne permet pas non plus de retrouver l’attaquant.
2.3 Construction d’un plan d’investigation
Nous considérerons dans cette partie qu’un système informatique a été compromis
par une attaque. Cette partie décrit la construction d’un réseau bayésien : la création
des variables, la création de la structure du réseau et l’initialisation des tables de probabilités.
2.3.1 Les variables
Les variables de nos réseaux bayésiens sont les variables décrites ci-dessus (paragraphe 2) : la variable address, les 6 variables loss, les 21 variables attack, les 12 variables action et les 10 variables représentant les techniques d’investigation. A ces 50
variables, il faut ensuite ajouter la configuration du système attaqué grâce aux variables
soft. Cette configuration doit être ajoutée manuellement en fonction des logiciels présents sur le système attaqué. Par défaut, nous utilisons la base des logiciels répertoriés
dans la base de vulnérabilités ICAT car elle est assez complète et mise à jour régulièrement (à ce jour, plusieurs milliers de logiciels sont référencés, sans compter les
différentes versions).
2.3.2 Construction de la structure
Comme il est décrit à la section 1.3.4, il existe deux façons de créer la structure
d’un réseau bayésien : soit on fait appel à des experts du domaine, soit on utilise des
algorithmes exploitant des bases de données. Étant donné que nous avons au minimum
50 variables plus les logiciels, la première solution n’est pas envisageable. Le travail serait beaucoup trop long (plusieurs milliers de logiciels et de versions à gérer ; même si
l’utilisateur ne choisira que quelques-uns de ces logiciels, il faudra quand même dans
un premier temps initialiser tous les nœuds). Nous utilisons donc la deuxième méthode. Comme les réseaux sont potentiellement grands, nous avons mis en œuvre un
algorithme d’apprentissage basé sur un score (section 1.3.4.1) pour améliorer la vitesse
d’analyse, et choisi K2 de Cooper et Herskovits [CH92]. Cet algorithme est largement
utilisé dans la littérature car il permet de construire un réseau très rapidement même si
la structure obtenue est très dépendante de l’ordre d’initialisation des variables. L’ordre
d’initialisation de nos variables est le suivant : les variables dégâts (loss), les variables
62
logiciels (soft), les variables attaques et actions (attack et action) et les variables techniques d’investigation (tech). Les premières variables initialisées sont les variables qui
apportent les premières information sur l’intrusion : les variables dégâts (loss) et les
variables logiciels (soft), puis les variables attaques et actions (attack et action) sont
initialisées. Enfin, les variables techniques d’investigation (tech) sont initialisées car ce
sont les dernières variables proposées à l’utilisateur.
L’algorithme construit les relations entre les variables en exploitant les échantillons
de la base de données. Cette construction peut être libre de toutes contraintes sur les
relations du réseau, ou bien il est possible, comme le suggère la figure 1.22, de fixer
certaines contraintes à la construction. Certaines classes de variables ne peuvent être
reliées qu’à une autre classe : les logiciels vers les attaques et les actions, les dégâts
observés vers les attaques et les actions. Pour certains types de variables, les relations
entre variables de même type sont autorisées, par exemple une attaque particulière peut
influer sur une autre. Par contre, pour le type soft, ces relations n’ont aucune signification et n’existent pas. Comme nous le verrons plus loin, chaque échantillon de la base
de données contient une vulnérabilité appliqué à un logiciel particulier. Chaque échantillon peut donc contenir plusieurs attaques et actions, mais ne peut contenir qu’un seul
logiciel. Puisqu’il n’y a qu’un seul logiciel par échantillon, il ne peut y avoir de relation
entre deux logiciels. Le raisonnement est le même si l’on utilise une base de données
sur les enquêtes : pour chaque attaque globale conservée, seul un logiciel est conservé,
puisqu’un attaquant ne peut attaquer qu’un seul logiciel à la fois.
La mise en place de nœuds racine peut être une contrainte intéressante. Un nœud
racine est un nœud qui n’a pas de parent et n’a donc que des enfants. Les nœuds de type
loss peuvent être des nœuds racine, car comme ce sont des observations initiales, toutes
les inférences et les observations suivantes se déduisent de l’observation de l’une ou de
plusieurs de ces variables.
2.3.3 Initialisation des probabilités
Après avoir construit la structure du réseau, il faut calculer les probabilités initiales.
C’est ce qu’on appelle l’apprentissage de paramètres (section 1.3.4.1). Les réseaux que
nous utilisons se basent sur un très grand nombre de données (plus de 7000 vulnérabilités dans la base ICAT). Nous avons donc privilégié encore une fois la rapidité en
utilisant un algorithme de type maximum de vraisemblance, c’est-à-dire que nous nous
basons sur un calcul statistique (Figure 2.5). Pour chaque échantillon de la base de
connaissances, chaque valeur des états de chaque nœud sera additionnée, puis normalisée pour obtenir des valeurs entre 0 et 1.
2.3.4 Bases de données
En l’absence d’une base de résultats d’enquêtes, nous utilisons un autre type de base
de données, la plus proche possible sémantiquement : une base de données contenant
des vulnérabilités, ICAT. Le type de résultats attendu est donc complètement différent :
avec une base d’enquêtes, le sens des nœuds attack et action est : si l’attaque X à
un pourcentage pX , cela signifie que cette attaque X a été vue pX fois sur 100
2.3. CONSTRUCTION D’UN PLAN D’INVESTIGATION
63
value = tableau d’entier
for éch in each [échantillons]
for var in each [variables du réseau]
for état in each [états de la variable var]
value(var)(état) = value(var)(état) + éch(var)(état)
# éch(var)(état) est égale à 1 si la
# variable "var" est à l’état "état"
# dans l’échantillon "éch" et 0 sinon
normalize(value)
F IG . 2.5 – L’algorithme de maximum de vraisemblance
dans les enquêtes précédentes (au niveau des probabilités initiales). En ce qui
concerne les probabilités postérieures, cela pourra se traduire par il y a p X % de
"chances" que cette attaque ait eu lieu connaissant les enquêtes précédentes. Par
contre, si on utilise une base de vulnérabilités, le sens devient : p X représente
le nombre de vulnérabilités sur 100 utilisant cette attaque pour les probabilités initiales. Pour les probabilités postérieures, cela représente le pourcentage
de "chance" de trouver cette attaque connaissant les vulnérabilités associées au
système compromis.
les variables soft ont aussi un sens différent suivant le type de base de données. Avec
une base sur les enquêtes précédentes, le pourcentage pY pour un logiciel Y
représente la probabilité avec laquelle une vulnérabilité de ce logiciel a été utilisée dans le cadre d’une attaque. Avec une base de vulnérabilités, le pourcentage
pY pour un logiciel Y représente le nombre de vulnérabilités présentes pour ce
logiciel.
la variable address représente avec la base des enquêtes, la provenance de l’attaque
(locale au système, interne au réseau ou externe à l’entreprise), dans le cas de la
base de vulnérabilités, cette variable représente les possibilités d’attaque : locale,
les vulnérabilités doivent être utilisées en locale ou externe, les vulnérabilités
doivent être utilisées à distance (ici interne n’a aucune signification réelle mais,
certaines vulnérabilités pouvant être à la fois utilisée localement ou à distance,
dans ce cas, nous avons utilisé la valeur : interne).
Les différentes interprétations sont récapitulées dans le tableau 2.6
De façon stricte, nous ne pouvons pas mélanger ces deux bases de données. La première est axée sur les vulnérabilités, tandis que la deuxième est axée sur les attaques et
les enquêtes. Néanmoins, l’utilisation simultanée des deux bases de données peut être
un atout dans la recherche de l’attaque globale et de l’attaquant. En effet, la réponse
donnée va prendre en compte d’une part le fait que le système analysé comporte obligatoirement des vulnérabilités, et d’autre part le fait que des attaquants ont déjà utilisé
le même mode opératoire. Il y a néanmoins une restriction au niveau de la variable
address, qui ne peut prendre que deux valeurs dans la base ICAT (local et externe, ie.
distant), et trois dans la base des enquêtes (local, interne et externe). Lors de l’analyse
64
address
loss
soft
attack
ICAT
Emplacement (local ou distant)
depuis lequel on peut utiliser la
vulnérabilité
Dégâts observables après utilisation de la vulnérabilité
Logiciels pouvant avoir été utilisés pour compromettre le système informatique. Ces variables dépendent du nombre de
vulnérabilités utilisant ces logiciels
Ces variables dépendent du
nombre de vulnérabilités qui
utilisent ces attaques élémentaires. Elles dépendent donc du
nombre d’attaques globales utilisant ces attaques élémentaires
action
Ces variables représentent les
actions élémentaires utilisées
dans les vulnérabilités. Elles dépendent donc du nombre de vulnérabilités utilisant ces actions
élémentaires
tech
Ces variables n’ont aucune signification puisqu’elles ne sont
pas présentes dans la base ICAT
Base d’attaques
l’adresse source de l’attaque
(locale, interne ou externe)
Dégâts observés par les enquêteurs
Logiciels pouvant avoir été utilisés pour compromettre le système informatique. Ces variables dépendent du nombre
d’attaques recensées utilisant
ces logiciels
attaques élémentaires utilisées
par les attaquants. Ces attaques
appartiennent aux attaques globales recensées dans la base
de données. Ces variables dépendent du nombre d’attaques
globales utilisant ces attaques
élémentaires
actions élémentaires utilisées
par les attaquants. Ces actions
appartiennent aux attaques globales recensées dans la base
de données. Ces variables dépendent donc du nombre d’attaques globales utilisant ces actions élémentaires
techniques d’investigation qui
peuvent être utilisées pour
trouver d’éventuelles indices
ou preuves. Ces variables
dépendent
essentiellement
des logiciels et des attaques /
actions qui ont été utilisés par
l’attaquant
TAB . 2.6 – Les différentes interprétations associées à nos types de variables
2.4. INFÉRENCE ET EXPLOITATION DES PLANS D’INVESTIGATION
65
des résultats, il faudra mettre en valeur l’interprétation la plus contraignante, c’est-àdire celle de la base ICAT (2 valeurs possibles). Pour cela, on peut confondre les valeurs
intern et extern pour n’avoir qu’une seule valeur correspondant à une attaque distante
ou l’utilisation d’une vulnérabilité distante.
2.4 Inférence et exploitation des plans d’investigation
2.4.1 Les algorithmes
Quand le réseau bayésien est construit, on peut l’exploiter. Nous avons choisi un
algorithme d’inférence approximative, car la taille et la complexité des réseaux que
nous exploitons est beaucoup trop importante pour des algorithmes d’inférence exacte.
Nous avons testé différents algorithmes d’inférence approximative grâce à un logiciel
en Java : BNJ4 (Bayesian Network tools in Java). Ces algorithmes sont :
– Logic Sampling,
– Forward Sampling,
– Likelihood Weighting,
– Self-Importance Sampling,
– Adaptive Importance Sampling (AIS).
Une description de ces algorithmes a été faite au paragraphe 1.3.4.2. Après quelques
essais, nous avons observé que, comparativement aux autres algorithmes, le Likelihood
Weighting donnait de bons résultats en rapidité et en qualité . Des problèmes techniques
dans l’utilisation de BNJ nous ont conduit à construire notre propre librairie pour réseau bayésien, pyBN, avec laquelle nous avons implémenté l’algorithme Likelihood
Weighting.
D’autre part, à partir de maintenant et jusqu’à la fin du mémoire, nous allons utiliser
le terme de score en lieu et place du terme probabilité. Il y a plusieurs raisons à cela :
– Au niveau compréhension, le fait de voir un résultat égal à 0% ou 100% peut
induire en erreur. Si un utilisateur observe un résultat égal à 100%, il peut arrêter
sa recherche en pensant qu’il a trouvé la solution. Si le résultat est égal à 0%, il
peut être tenté d’oublier cette variable jusqu’à la fin de l’enquête.
– Nous fusionnons plusieurs bases dont les données ont des interprétations sémantiques différentes, ce qui en soi fausse le résultat d’un point de vue purement
probabiliste.
2.4.2 Utilisation des résultats finaux de l’enquête
Quand une enquête est terminée, l’enquêteur a acquis une certaine expérience. Pour
conserver cette expérience, certaines données sont ajoutées à la base de connaissance
de notre modèle. Les données sauvegardées correspondent aux résultats intermédiaires.
Chaque plan d’investigation est sauvegardé, ces plans contenant les informations suivantes :
– l’adresse source (état de la variable addr) ;
4 http://bndev.sourceforge.net
66
Réseau 1
Système 1
?
PI 3
Temps 1
PI 4
Temps 2
Système 2
PI 1
Temps 3
PI 2
Première observation
F IG . 2.6 – Un exemple d’arbre d’attaque
– les dégâts observés (état des variables loss) ;
– les attaques et les actions effectuées par l’attaquant (état des variables attack et
action) ;
– les techniques utilisées par les enquêteurs pour retrouver l’attaquant (état des
variables tech) ;
– éventuellement les fichiers et autres éléments qui ont permis de faire avancer
l’enquête (par exemple, la découverte dans le fichier d’audit d’un serveur Web
IIS de la ligne cmd.exe permet de dire que ce logiciel a été utilisé par l’attaquant).
Chaque plan d’investigation conduit à la création d’un nouvel enregistrement dans la
base de données. Ces données peuvent être exploitées pendant l’enquête en cours, pour
pouvoir immédiatement en tirer bénéfice, ou bien après la résolution complète.
2.5 Création et analyse de plusieurs plans d’investigation
Dans le cas d’enquêtes réelles, il n’y a pas forcément qu’un seul système compromis. Des attaquants peuvent utiliser des systèmes préalablement compromis, soit pour
d’autres attaques, soit pour être plus discret, soit pour être plus efficace.
2.5.1 Utilité de la variable adresse
C’est de ce point de vue que la variable address est la plus utile. Elle permet de
présenter à l’enquêteur d’où vient potentiellement l’attaque. Cette variable sert de lien
2.5. CRÉATION ET ANALYSE DE PLUSIEURS PLANS D’INVESTIGATION 67
entre les différents plans d’investigation. La figure 2.6 représente un exemple d’attaque : chaque rectangle en traits pleins représente un plan d’investigation, chaque
rectangle en traits pointillés représente un système compromis ou ayant été utilisé par
l’attaquant. Les flèches en traits pleins représentent le cheminement de l’attaquant et
celles en pointillé le cheminement des enquêteurs. Dans cet exemple, les enquêteurs
commencent leur enquête au niveau du plan d’investigation 1 ; la variable address
va permettre de caractériser la source de l’attaque représentée par la flèche intitulée
Temps 2 ; ici, la source de l’attaque est interne au réseau.
2.5.2 Relation entre les plans d’investigation
Quand des plans d’investigations concernent le même système, d’une part, la configuration logicielle va rester la même et d’autre part c’est a priori la même personne
(ou le même groupe) qui aura effectué les différentes attaques, avec le même modus
operandi. Par exemple, si l’attaquant est entré dans le système de façon bruyante, il
y a de grandes chances qu’il continue de façon bruyante. Par attaque bruyante, on
fait référence à des attaques qui sont facilement décelables, comme les sondes réseau,
ou l’utilisation d’exploits qui provoquent certains dommages "collatéraux" (ajout de
lignes dans les fichiers d’audit, par exemple). Dans le cas où les plans concernent des
systèmes différents, il est probable que ce sont les mêmes attaquants, mais il faut cependant être plus circonspect. Certaines observations faites par les enquêteurs sur un
plan particulier au niveau des attaques et des actions peuvent donc éventuellement être
utilisées sur d’autres plans d’investigation. Pour des recherches sur le même système,
on peut garder toutes les observations qui sont faites sur ce système, et pour un système
différent, ces observations peuvent avoir une influence sur les résultats.
Par exemple, les enquêteurs constatent une attaque de type suppression de données
sur un site FTP. Le premier plan d’investigation décrit le défigurement du site FTP en
lui même, c’est-à-dire une attaque de type degrad (dégradation), qui a permis à l’attaquant de supprimer plusieurs fichiers. Dans ce plan, les observations seront : le serveur
FTP, l’attaque de type degrad, l’action del car l’attaquant a supprimé des fichiers et
les techniques d’investigation check_syst, qui a permis de découvrir l’attaque degrad
et retrieve (récupération des fichiers supprimés), qui a permis de découvrir l’attaque
del. Un deuxième plan doit être construit pour comprendre comment l’attaquant a eu
accès au serveur. Sur ce deuxième plan, certaines observations du premier plan vont
pouvoir être réutilisées. Comme l’attaquant a pu utiliser un autre logiciel, nous n’allons pas garder les observations sur les logiciels (ici, le serveur FTP). Par contre, le fait
qu’il ait utilisé une attaque de type degrad et qu’il ait supprimé des données peut être
une information intéressante pour ce second plan d’investigation. Enfin, comme pour
les logiciels, le fait de savoir quelles techniques l’enquêteur a utilisé pour trouver des
réponses n’est pas pertinente dans ce deuxième plan.
La réutilisation d’observations peut être mise en place de deux manières :
→ soit en mettant les variables correspondantes (degrad et del dans l’exemple cidessus) dans l’état observé,
68
→ soit on ajoutant de façon automatique un échantillon temporaire5 dans la base de
données courante.
Avec la première technique, les résultats seront fortement influencés par les observations. Par contre la deuxième solution a beaucoup moins d’effets de bord que la première, cela revient à ajouter une nouvelle attaque. Dans ce cas, il est alors possible de
prendre en compte le ou les logiciels attaqués ainsi que les techniques d’investigation
utilisées.
D’autre part, la mise en relation des différents plans d’investigation permet de tracer les arbres d’attaque et d’enquête. Ces arbres sont importants à garder, car d’une
part cela permet d’écrire le rapport final, et d’autre part, l’arbre d’attaque permet de
connaître le cheminement de l’attaquant.
2.5.3 Apport de la création de plusieurs plans d’investigation au
niveau de l’analyse de l’attaquant
Des relations entre les plans d’investigation, nous pouvons tirer quelques informations pouvant être importantes sur l’attaquant. Ces informations sont les suivantes :
– les logiciels qu’il préfère attaquer,
– les attaques qu’il préfère mener,
– les actions qu’il sait utiliser,
– sa localisation (attaquant interne ou externe).
Ces observations peuvent éventuellement permettre de caractériser l’attaquant : son
objectif principal (recherche-t’il quelque chose de précis ou cherche-t’il simplement à
s’amuser ?) ou son niveau d’expérience (un attaquant n’utilisant que des exploits standards sera moins expérimenté qu’un attaquant utilisant des combinaisons d’attaques
différentes pour rester discret).
5 cet échantillon contiendrait l’adresse source de l’attaque, le logiciel utilisé pour l’attaque, l’attaque en
elle même et / ou l’action, le ou les dégâts observés et la technique d’investigation utilisée qui a permis
d’observer cette attaque
Chapitre 3
Expérimentations
Après avoir décrit les concepts de notre proposition, nous présentons dans un premier temps la plateforme logicielle qui a été réalisée pour tester le modèle. Ensuite,
nous l’utilisons sur les cas suivants :
– l’affaire Kevin Mitnick contre Tsutomu Shimomura, pour montrer les principes
généraux d’utilisation ;
– les challenges des ouvrages Hacker’s Challenge [Sch01, Sch02], pour évaluer la
pertinence de nos résultats.
Pour finir, ces cas vont nous permettre de tirer quelques conclusions sur notre approche.
3.1 Description de la plateforme de test
Les développements ont été réalisés avec le langage de programmation Python1 .
Ce choix a été fait pour plusieurs raisons :
– c’est un langage à objets, donc le code est facile à comprendre et à maintenir ;
– c’est un langage de type script, donc la programmation est rapide ;
– l’inclusion de modules en langage C est possible ;
– les scripts Python s’exécutent sous une machine virtuelle : l’application résultante est donc portable sur plusieurs systèmes (Linux, Windows, etc.).
D’autre part, Python dispose d’une communauté très importante et de nombreux logiciels sont écrits dans ce langage (Zope2 et la distribution Linux Gentoo3 sont parmi
les projets les plus importants).
Comme nous l’avons déjà expliqué, les premiers tests réalisés avec BNJ ne nous ont
pas donné entière satisfaction. Nous avons donc construit une bibliothèque en Python
pour nous permettre d’effectuer des calculs sur des réseaux bayésiens, avec un code
suffisamment modulaire pour pouvoir par la suite ajouter de nouveaux algorithmes
d’apprentissage ou d’inférence.
1 http://www.python.org
2 http://www.zope.org
3 http://www.gentoo.org
69
CHAPITRE 3. EXPÉRIMENTATIONS
70
L’interface graphique, XMeta, est écrite en python et en GTK (Gimp ToolKit) 4 .
Le choix de GTK a été dicté par le fait que la création de l’interface peut être faite
graphiquement et rapidement grâce à l’environnement Glade5 .
3.1.1 Base de connaissances
Cette base de données est construite à partir de la base de vulnérabilités ICAT6 .
Cette dernière nous fournit directement les logiciels et les dégâts observés. Par contre,
la récupération des attaques et des actions n’est pas triviale, puisqu’il n’y a pas ce
type de champ dans la base de données. Ces informations sont extraites du champ
CVE_Description (cf. annexe A). En analysant ce champ, on peut retrouver sur quelles
attaques et / ou quelles actions s’appuie chaque vulnérabilité. L’analyse est une analyse
par dictionnaire. Nous avons créé un dictionnaire regroupant les principaux termes qui
sont utilisés dans ICAT pour décrire les attaques et les actions. Par exemple, l’attaque
exploit peut être décrite par « #exec function » ou « execut&dangerous&program », le
& correspondant à un ET logique. 383 termes ou groupe de termes permettent de traiter
la totalité des vulnérabilités ICAT.
La plateforme offre la possibilité d’utiliser d’autres bases de données. Comme il
est expliqué dans le paragraphe 2.3.4, le moteur réagit différemment selon les données.
L’idée est d’offrir aux utilisateurs le choix d’utiliser une base de données différente
suivant le contexte de l’enquête. Nous avons construit une base réunissant des résultats
d’enquêtes dans lesquelles il y a eu compromission d’un ou de plusieurs systèmes. Cependant, on pourrait très bien imaginer des bases de données spécialisées dans les délits
financiers, la pédopornographie, etc. En effet, dans certains types de délits les auteurs
utilisent des techniques spécifiques. Dans le cas des délits financiers, il y aura plus de
vol de données et d’usurpation d’identité que de déni de service ou d’exploitation de
vulnérabilité.
3.1.2 Interface Homme-Machine
L’IHM de XMeta est pour l’instant divisée en quatre parties. La moitié gauche
(parties 1 et 2) de l’écran présente le ou les systèmes attaqués, la partie droite (3 et 4)
présente les attaques et les investigations effectuées. La partie haute (1 et 3) correspond
à une attaque sur un système, alors que la partie basse (2 et 4) correspond à l’ensemble
de l’enquête. En résumé, l’interface est constituée de :
1. une zone où l’utilisateur rentre la configuration du système attaqué ;
2. une zone qui liste l’ensemble des systèmes analysés ;
3. une zone où l’on peut analyser le système courant ;
4. une zone qui liste l’ensemble des investigations proposées.
4 http://www.gtk.org
5 http://glade.gnome.org
6 http://icat.nist.gov/exporticat.htm
3.1. DESCRIPTION DE LA PLATEFORME DE TEST
F IG . 3.1 – Structure de l’interface homme-machine XMeta
71
72
3.1.3 Fonctionnalités de la plateforme
Voici la liste des fonctionnalités qui ont été spécifiées7 , présentées dans l’ordre des
zones de la figure 3.1 :
I Zones 1 : configuration :
– création de plan d’investigation,
– ajout des dégâts observés ;
– recherche de logiciel suivant une chaîne de caractère ;
– ajout / suppression de logiciels au système compromis.
I Zones 2 : l’ensemble des équipements analysés :
– navigation entre les différents plans d’investigation ;
– séparation des plans d’investigation par système et par réseau ;
× liaison des différents plans d’investigation.
I Zones 3 : l’analyse d’une attaque :
– inférence multiple du réseau bayésien ;
– présentation des scores de chaque variable ;
– ajout des observations faites par les enquêteurs.
I Zones 4 : investigations déjà effectuées :
– liste des techniques d’investigation utilisées depuis le début de l’enquête ;
– liste des preuves ou indices trouvés depuis le début de l’enquête ;
× organisation de la liste par date, plans d’investigation, etc.
I Divers :
– enregistrement des plans d’investigation (cf. C.1) ;
– ouverture d’une enquête précédemment enregistrée ;
– énumération des vulnérabilités (ICAT) associées au système en cours d’analyse ;
– ajout / utilisation d’autres bases de données ;
– changement de la qualité de l’inférence (contraintes sur le réseau bayésien) ;
× visualisation de l’arbre de l’attaque.
3.2 Exemple sur un cas concret : l’affaire Kevin Mitnick
3.2.1 Introduction
Nous proposons ici de revisiter avec XMeta une partie de l’une des affaires les plus
connues au monde, présentée en détail dans de nombreux articles, notamment par Tsutomu Shimomura, propriétaire des systèmes compromis [SM96]. L’affaire Mitnick est
intéressante car c’est une attaque complexe mettant en jeu plusieurs systèmes informatiques. Tsutomu Shimomura est chercheur (Senior Fellow) au Supercomputer Center
de San Diego, Californie, et travaille dans différents domaines de recherche dont la
sécurité informatique. En 1994, un inconnu s’infiltre dans les systèmes de Shimomura
et, après 7 semaines de traque intensive, Kevin Mitnick est localisé à Raleigh, Caroline
du nord. Mitnick est arrêté le 14 février 1995, puis inculpé pour intrusion dans des
systèmes d’information et vol de données confidentielles.
7 le
sigle × indique que la fonctionnalité est prévue et en cours d’implémentation
3.2. EXEMPLE SUR UN CAS CONCRET : L’AFFAIRE KEVIN MITNICK
73
F IG . 3.2 – Les ordinateurs impliqués dans l’attaque
3.2.2 L’enquête assistée par la plateforme XMeta
Quand les ordinateurs ont été attaqués, les premiers indices ont été trouvés sur le
système, Ariel (voir Fig. 3.2). Beaucoup de sondes réseaux avaient été effectuées la nuit
précédente. Un très gros fichier (oki.tar.Z) avait été créé, transféré vers une destination
inconnue, puis supprimé du système. Il s’avéra par la suite que ce fichier contenait
notamment un certain nombre de données confidentielles.
Ces premières constatations ont été saisies dans XMeta :
ARIEL :
Logiciels : SunOS, GNU Tar, GNU Ghostscript, fingerd, ruserd et FTP
Dégats : LT_Confidentiality
Le système XMeta répond :
Les attaques les plus probables sont : bypass, contournement d’un
équipement de sécurité (0,65), diversion (masquage d’une attaque sur un
autre système, 0,56) et overrun, attaque par force brute (0,56).
Les actions complémentaires les plus probables sont : infection, infection de fichiers (0,83), inhib_detect, inhibition de la détection (0,81) et
login_inst, installation d’un nouveau compte système (0,71).
Les logiciels suspectés sont : GNU Tar (0,73), Finger Service (0,73) et
FTP (0,27).
Les éventuels fichiers d’audit des applications suspectées devraient donc être vérifiés.
Les 3 attaques proposées laissent à supposer que l’action devait venir de l’extérieur,
cela étant confirmé par le nombre important de sondes réseaux révélées par l’enquête.
L’attaquant a contourné un équipement (ou un service) de sécurité ou bien il a fait
une diversion pour s’emparer du fichier oki.tar.Z. On peut ignorer l’attaque par force
brute car elle ne permet pas de s’emparer d’un fichier. Cependant, la présence de cette
attaque peut s’expliquer facilement : étant donné le peu d’expériences accumulées,
notre base de connaissance est le reflet des vulnérabilités répertoriées dans la base
74
14:09:32
14:10:21
14:10:50
14:11:07
14:11:38
14:11:49
14:12:05
toad.com#
toad.com#
toad.com#
toad.com#
toad.com#
toad.com#
toad.com#
finger -l @target
finger -l @server
finger -l root@server
finger -l @x-terminal
showmount -e x-terminal
rpcinfo -p x-terminal
finger -l root@x-terminal
F IG . 3.3 – Premiers fichiers d’audit de toad.com ; target correspond à Ariel, server
correspond à Rimmon et x-terminal correspond à Osiris [Shi95]
14:18:25.906002
14:18:26.094731
14:18:26.172394
14:18:26.507560
14:18:26.694691
14:18:26.775037
...
apollo.it.luc.edu.1000 > x-terminal.shell: S 1382726990:1382726990(0) win 4096
x-terminal.shell > apollo.it.luc.edu.1000: S 2021824000:2021824000(0) ack 1382726991 win 4096
apollo.it.luc.edu.1000 > x-terminal.shell: R 1382726991:1382726991(0) win 0
apollo.it.luc.edu.999 > x-terminal.shell: S 1382726991:1382726991(0) win 4096
x-terminal.shell > apollo.it.luc.edu.999: S 2021952000:2021952000(0) ack 1382726992 win 4096
apollo.it.luc.edu.999 > x-terminal.shell: R 1382726992:1382726992(0) win 0
F IG . 3.4 – Les fichiers d’audit provenant d’Osiris [Shi95]
ICAT. Les scores estimés sont fonction de la fréquence d’apparition des logiciels et des
attaques dans cette base. Ce dysfonctionnement devrait disparaître au fur et à mesure
de l’enrichissement de la base d’expériences.
Toutes les sondes réseaux provenaient du domaine Internet toad.com (la figure 3.3
extraite de [Shi95] présente un extrait de l’historique des commandes utilisées par
l’attaquant sur le système de toad.com). L’enquêteur a aussi observé que l’ordinateur
nommé Osiris avait un comportement étrange, avec des fenêtres vides affichées en haut
de l’écran. Nous avons donc les faits suivants :
– Ariel et Osiris ont des relations de confiance fortes ;
– Osiris est physiquement au domicile de Tsutomu Shimomura, qui n’a pas de
relation avec toad.com ;
– beaucoup de trafic réseau a été observé vers Osiris (la figure 3.4 présente un
extrait des paquets circulant sur le réseau).
Tout ceci implique que l’enquête doit continuer sur Osiris et pas (dans un premier
temps) sur le réseau de toad.com. Osiris est peut-être la source de l’attaque ou au moins
un vecteur. Un nouveau plan d’investigation est donc créé sur Osiris et prend comme
observation initiale le fait que cet ordinateur semblait être déconnecté du réseau et en
particulier d’Ariel.
OSIRIS :
Dégats : : LT_Availability
Le système XMeta répond :
Les attaques les plus probables sont : repeat (scanning sweeping par
exemple, 1,0), overrun (DOS, DDOS, smurf, fraggle, etc., 0,89) et bypass
(contournement d’un équipement de sécurité, 0,68)
Les actions complémentaires sont : infection (0,73), trap (installation
d’une backdoor, 0,62) et del (suppression de données, 0,45)
Les logiciels potentiellement cibles sont : FTP (0,73), GNU Tar (0,38) et
GNU Ghostscript (0,38).
3.2. EXEMPLE SUR UN CAS CONCRET : L’AFFAIRE KEVIN MITNICK
14:18:22.516699
14:18:22.566069
14:18:22.744477
14:18:22.830111
14:18:22.886128
...
130.92.6.97.600
130.92.6.97.601
130.92.6.97.602
130.92.6.97.603
130.92.6.97.604
>
>
>
>
>
server.login:
server.login:
server.login:
server.login:
server.login:
S
S
S
S
S
75
1382726960:1382726960(0)
1382726961:1382726961(0)
1382726962:1382726962(0)
1382726963:1382726963(0)
1382726964:1382726964(0)
win
win
win
win
win
F IG . 3.5 – Les fichiers d’audit provenant de Rimmon [Shi95]
x-terminal% modstat
Id Type Loadaddr
1 Pdrv ff050000
Size
1000
x-terminal% ls -l /dev/tap
crwxrwxrwx 1 root
37,
B-major
C-major
59.
Sysnum
Mod Name
tap/tap-2.01 alpha
59 Dec 25 14:40 /dev/tap
F IG . 3.6 – Quelques variables système de Rimmon [Shi95]
Cela implique qu’Osiris n’est peut-être qu’un vecteur pour l’attaquant, car ce dernier
n’a pas pu pénétrer dans le système en utilisant des sondes réseaux ou par un déni de
service. Ces résultats nous incitent à explorer une autre piste.
Osiris est un Terminal X-Window connecté à Rimmon, qui a donc pu être aussi attaqué. Ceci est confirmé par les fichiers d’audit récupérés par Shimomura (la figure 3.5
présente un extrait des paquets réseau à destination de Rimmon). Comme nous n’avons
pas beaucoup d’informations sur Rimmon, nous supposons qu’il est configuré comme
Osiris et Ariel. Un utilisateur non autorisé a réussi à installer un module-noyau nommé
Tap 2.01 sur Rimmon, ce qui implique d’avoir des droits administrateur sur la machine
(la figure 3.6 présente la sortie des commandes modstat et ls et montre l’installation
d’un module dans le noyau du système).
RIMMON :
Dégâts : LT_Obtain_all_priv et LT_Availability
XMeta répond :
Les attaques les plus probables sont : trojan (installation d’un cheval de
Troie, 0,93), bypass (0,78) et brute_force, attaque par force brute (0,58).
Les actions complémentaires les plus probables sont : login_inst (installation d’un compte, 0,58), infection, infection de fichier (0,51) et trap
(0,46)
Les logiciels potentiellement cibles : FTP (0,59) et GNU Tar (0,41).
Grâce à ces résultats, si nous ne trouvons pas de cheval de Troie sur Rimmon, cela signifie que ce dernier a aussi été utilisé comme vecteur d’attaque comme Osiris. Tsutomu
n’a pas trouvé de cheval de Troie, mais une attaque par Flooding (appelée Overrun dans
XMeta). Nous pouvons maintenant affirmer que Rimmon était bien un moyen d’accéder à Osiris et Ariel. L’attaque Overrun n’était classée qu’en 10ème position8 sur 21.
Ce résultat peut s’expliquer par le fait que la base d’apprentissage que nous utilisons
est une base de vulnérabilités et il y a plus de vulnérabilités qui utilisent des attaques de
8 de
1 à 10 : Trojan, bypass, brute_force, broadcast, chaff, repeat, intercept, net_listen, bounce et overrun
4096
4096
4096
4096
4096
76
type trojan, bypass ou brute_force dans ce type de configuration que de vulnérabilités
qui utilisent des attaques de type overrun.
3.2.3 Synthèse des résultats obtenus avec XMeta
Nous avons trouvé les éléments suivants :
– Ariel :
– le fichier oki.tar.Z a pu être téléchargé grâce à une attaque de type contournement (bypass) sur le système d’exploitation.
– Osiris :
– l’attaquant a envoyé des paquets sur le réseau (repeat) pour obtenir des informations sur ce système ;
– l’attaquant a utilisé une attaque de type contournement (bypass) pour obtenir
des droits administrateur.
– Rimmon :
– l’attaquant a utilisé une attaque de type déni de service (overrun) pour bloquer
le système.
Ces résultats peuvent être sauvegardés pour des enquêtes futures, et complétés en précisant les techniques employées pour analyser chacun des systèmes. Ces résultats comprennent la configuration logicielle des systèmes attaqués, les attaques qu’ils ont subies, les techniques d’investigation utilisées ainsi que les éléments (fichiers, événements, etc.) qui ont permis aux enquêteurs de découvrir ces attaques. La sauvegarde
permet aussi par la suite de "rejouer" l’attaque ou l’enquête, par exemple à des fins
d’explication devant un tribunal.
Dans le cadre de l’enquête présentée ici, les prochaines étapes seraient, d’une part,
de comprendre comment l’attaquant a pu obtenir les droits administrateur sur les ordinateurs de toad.com, d’autre part, d’analyser la chronologie des événements entre les
trois systèmes et enfin d’essayer d’identifier la destination du fichier oki.tar.Z.
3.2.4 Conclusions de l’enquête de Tsutomu Shimomura
Pour information, nous allons présenter dans ce paragraphe les conclusions de Tsutomu Shimomura sur les actions que l’attaquant a réellement effectuées. L’attaque décrite par Tsutomu Shimomura s’est jouée en trois temps.
Dans une première phase, l’attaquant a essayé de prédire les numéros de séquence
initiaux des connexions TCP acceptés par Osiris en lui envoyant un nombre important de paquets TCP SYN (cette attaque est appelée Repeat dans XMeta), puis en les
annulant avec des paquets TCP RST (Fig. 3.7).
Il a pu ensuite envoyer à Osiris par rsh la commande "echo ++ >>/.rhosts"
en se faisant passer pour Rimmon (Fig. 3.8). Il a ainsi obtenu un accès total à cette
machine. Cette attaque est nommé bypass, contournement d’un équipement de sécurité
dans XMeta. Nous avons vu qu’elle était classée en troisième position avec une score
de 0,68. L’attaque par Flooding (Overrun dans XMeta) a été utilisée pour "bâillonner"
Rimmon et l’empêcher de répondre à Osiris (Fig. 3.8).
Dans la troisième phase de l’attaque, l’attaquant a installé le programme Tap sur
Osiris, ce qui lui a permis de prendre le contrôle de la relation de confiance entre Osiris
3.3. HACKER’S CHALLENGE 1 & 2
Ariel
77
Rimmon
SYN
SYN_ACK
RST
several times
Osiris
F IG . 3.7 – L’attaque de Kevin Mitnick : première étape
et Ariel (Fig. 3.9). Il a eu alors accès à Ariel et a pu créer, transférer puis supprimer le
fichier oki.tar.Z.
3.3 Hacker’s Challenge 1 & 2
Mike Schiffman décrit dans [Sch01] vingt attaques sur des réseaux d’entreprise.
Ces attaques sont, entre autres, des attaques sur des serveurs HTTP (35%), des attaques
via un réseau sans fil (20%) et des attaques sur des serveurs de messagerie (10%). Dans
une première partie, les attaques sont décrites de manière à ce que le lecteur puisse
répondre à certaines questions sur l’incident. Puis dans une deuxième partie, il propose
une solution avec une description plus complète de l’attaque, des techniques utilisées
pour récupérer les preuves, ainsi que des techniques pour protéger le ou les systèmes
qui ont été compromis.
3.3.1 Exemple du challenge numéro 8
Voici un exemple d’attaque, le challenge numéro 8 du premier tome : The Tip
of The Iceberg, analysé par notre outil XMeta et la base de données ICAT seule.
Le premier événement qui a permis de découvrir l’attaque est le défigurement du site
Web de l’entreprise Financialco.net (Microsoft IIS), avec le message suivant :
f-- USA Government
f-- PoizonB0x
contact [email protected]
78
Ariel
Rimmon
FLOODING
1: SYN
{
2: SYN + ACK
3: ACK + DATA
4: "echo ++ ./rhosts"
Osiris
F IG . 3.8 – L’attaque de Kevin Mitnick : deuxième étape
Ariel
Rimmon
hack connection
using "Tap" software
Installation of "Tap" software
Osiris
F IG . 3.9 – L’attaque de Kevin Mitnick : troisième étape
79
En entrant la configuration du système sur la plateforme9 et en indiquant que l’on a
observé :
– un dégât de type atteinte à l’intégrité ;
– une attaque de type dégradation (degrad),
on obtient les résultats de la figure 3.1010 . On observe dans la colonne de droite que
les attaques les plus probables sont degrad qui a déjà été observée, bypass, diversion
et exploit. Cela signifie que l’enquêteur doit essayer de chercher ces trois attaques en
priorité. De plus, on peut observer que, d’après XMeta, cette attaque a été effectuée à
distance (extern et intern : 0.93) et que le meilleur logiciel pour cette attaque est le serveur Web Microsoft IIS. En réalité, l’attaquant a utilisé une attaque particulière appelée
attaque unicode sur le serveur Web Microsoft IIS, permettant depuis l’extérieur
du système d’obtenir tous les droits sur le système cible. Cette attaque appartient à
notre catégorie exploit que l’on trouve en troisième position avec une score de 0,94.
Mike Schiffman explique que cette attaque a pu être prouvée grâce aux fichier d’audit
du serveur Microsoft IIS, dans lesquels on trouve des lignes contenant la chaîne de
caractères suivante :
GET, /scripts/../../winnt/system32/cmd.exe
L’attaque globale qui a permis le défigurement Web est donc de la forme :
[ exploit → degrad ]
Le lendemain, l’administrateur système reçoit un email d’un administrateur de site
Web lui disant que son réseau venait de se faire attaquer par l’une des machines du
réseau Financialco.net : solarisbox.financialco.net. Pour intégrer cette information,
nous devons créer un nouveau plan d’investigation qui va décrire ce système (cf. figure 3.11). La première constatation faite par l’administrateur du site était que ce
système était situé en dehors du pare-feu de l’entreprise, directement connecté à internet. L’attaquant a eu donc accès au système entier sans avoir à se préoccuper du
pare-feu. Pour pouvoir lancer ses attaques, l’attaquant devait avoir les droits administrateurs sur la machine. L’observation préliminaire va donc être l’obtention des
droits administrateur. Sur la figure 3.11, on observe que les attaques les plus probables sont dans l’ordre exploit, diversion et bypass. La véritable attaque était une
attaque nommée sadmin exploit qui appartient à notre catégorie exploit. Cette attaque
a permis à l’attaquant d’obtenir les droits administrateurs sur ce système. Dans le cas
où les enquêteurs auraient pu avoir accès aux systèmes compromis des autres sites
web, on aurait pu créer d’autres plans d’investigation correspondant à ces systèmes. Le
schéma de l’attaque est décrit sur la figure 3.12. L’attaquant a tout d’abord compromis
solarisbox.financialco.net, puis par ce système il a défiguré le site web
de financialco.net. Ensuite, l’attaquant a recherché de nouvelles cibles et les
a attaqué (www.just_another_victim.net). Le cheminement de l’attaquant
9 c’est
à dire en créant un premier plan d’investigation
des raisons de commodité, les 20 challenges du premier livre ont été enregistrés dans une même
session de la plateforme XMeta. Les 20 challenges correspondent à 20 réseaux différents qui ont pour nom
le numéro et le nom du challenge qu’ils décrivent
10 pour
80
F IG . 3.10 – Le premier système compromis de Financialco.net. Les enquêteurs ont
observé une atteinte à l’intégrité du système et une attaque de type dégradation.
est représenté sur la figure 3.12 par les numéros situés en haut et à droite des boites.
Les numéros situés en bas et à gauche représentent le cheminement des enquêteurs,
qui ont d’abord observé le défigurement de www.financialco.net, puis, par des
messages d’administrateurs système, ont découvert le défigurement d’autres sites Web,
puis l’attaque sur solarisbox.
3.3.2 Exemple du challenge numéro 6
Après la description d’un challenge sur plusieurs systèmes, voici un challenge où
l’attaquant n’a compromis qu’un seul système, mais où la possibilité d’ajouter de nouvelles observations après chaque inférence s’avère indispensable pour trouver la solution. Le challenge s’intitule : The Genome Injection. Ce challenge décrit une
attaque sur un serveur Web qui interroge un serveur SQL. Un attaquant a réussi à télécharger des données confidentielles depuis le serveur SQL de l’entreprise via le serveur
Web. Ces données sont des résultats de plusieurs années de recherche dans le domaine
du génome humain. Ces données ont été ensuite supprimées par l’attaquant pour qu’il
en soit le seul détenteur. Nous allons analyser cette attaque avec la base ICAT comme
seule source de données. Après avoir rentré les logiciels installés sur le système cible
(le serveur SQL), nous indiquons les dégâts observés : perte de confidentialité et perte
81
F IG . 3.11 – Le deuxième système compromis de Financialco.net, les enquêteurs découvrent que l’attaquant a eu accès à un compte administrateur
F IG . 3.12 – Cheminement de l’attaquant en traits pleins et des enquêteurs en traits
pointillés
82
Fichier HTML :
<form . . . method= " p o s t " . . . >
< i n p u t t y p e = " t e x t " name= " uname " >
< i n p u t t y p e = " p a s s w o r d " name= " pword " >
</ form>
Fichier SQL :
S e l e c t ∗ from u s e r i n f o where u s e r n a m e = ’ uname ’ and
p a s s w o r d = ’ pword ’
F IG . 3.13 – Challenge 6 : un extrait du code source du site web et SQL
d’intégrité. Après analyse de la base de données, la plateforme crée un réseau sur 294
vulnérabilités, les résultats se trouvant sur la figure 3.15. Les attaques les plus probables ici sont diversion, exploit et listing. Dans un deuxième temps, nous intégrons
le fait que l’attaquant a envoyé un message à l’administrateur pour signer son forfait
et pour demander une rançon contre la récupération des données. Nous mettons alors
la variable d’action msg dans l’état observé. Nous obtenons alors la figure 3.16. Nous
pouvons effectuer quatre observations à cet instant :
– Premièrement, on voit nettement que l’ajout de la dernière observation permet
au réseau de mieux préciser le type d’attaque. Sur la figure 3.15, les scores sont
compris entre 0.99 et 0.38, alors que sur la figure 3.16 ils sont compris entre 1.0
et 0.1.
– Deuxièmement, certaines attaques ont changé de position. C’est notamment le
cas pour l’attaque de type bypass qui passe de la dixième position (0.61) à la
deuxième position (0.99).
– Troisièmement, on remarque que les scores associés aux logiciels (à gauche des
figures) changent : les scores du module SSL11 et celui du serveur Windows NT
chutent (-0,31, -0,37 et -0,29) alors que le score du serveur SQL ne diminue
pas autant (-0,16). Comparativement, le serveur SQL devient le vecteur le plus
probable de l’attaque.
– Enfin, les scores extern + intern et local sont presque identiques (0,47 et 0.53).
On ne peut donc rien en conclure sur le fait que l’attaquant ait utilisée une vulnérabilité en local ou à distance.
Après quelques recherches, l’administrateur du site a trouvé la véritable attaque : l’attaquant a utilisé une attaque de type SQL injection, consistant en l’injection de code
SQL dans des entrées HTML où ce code n’est pas attendu. La figure 3.13 montre un
extrait du code source du site. Si un attaquant insère comme nom d’utilisateur MOI et
dans le champ password : ’ or 0=0 -’ il obtient la requête SQL de la figure 3.14.
De cette façon, en détournant le mécanisme de sécurité du serveur SQL, il peut obtenir
toutes les informations qu’il souhaite. Cette attaque est pour notre plateforme de type
bypass (contournement d’un élément de sécurité) et agit sur le serveur SQL.
11 mod_ssl,
mod_ssl et Mod_ssl, Mod_ssl
83
S e l e c t ∗ from u s e r i n f o where u s e r n a m e = ’MOI ’ and
p a s s w o r d = ’ ’ o r 0 = 0 −− ’
F IG . 3.14 – Challenge 6 : requête SQL résultante
F IG . 3.15 – Challenge 6 : première analyse avec les observations : perte de confidentialité et perte d’intégrité
84
F IG . 3.16 – Challenge 6 : deuxième analyse avec l’ajout de l’action message : l’attaquant a envoyé un message à l’administrateur (l’action message n’est pas visible sur
cette figure, nous n’avons laissé que les attaques proposées)
85
F IG . 3.17 – Challenge 6 : troisième analyse après observation de l’attaque bypass
La figure 3.17 montre la fin de l’analyse, l’attaque bypass a été observée, aucun
changement n’est visible avec la précédente capture, cela montre que l’analyse de ce
système avec la plateforme XMeta arrive à terme si l’enquêteur ne propose pas de
nouveaux faits ou observations.
Nous voyons que l’analyse en plusieurs passes est un atout très intéressant. Chacune des passes offre des résultats nouveaux qui permettent de faire avancer significativement l’enquête.
3.3.3 Protocole d’expérimentation
Pour tester XMeta, nous avons mis en place un protocole d’expérimentation exploitant les données des livres Hacker’s Challenge [Sch01, Sch02] :
1. Analyse des 39 affaires des livres Hacker’s Challenge avec la base ICAT ;
2. Analyse des 19 affaires du deuxième tome avec la seule base de données résultante de l’analyse des affaires précédentes (base des enquêtes) ;
3. Analyse des 39 affaires des livres Hacker’s Challenge avec une troisième
base de données qui est la concaténation de la base ICAT et de la base de données
des enquêtes.
Pour chaque plan d’investigation, nous mesurons :
– le score obtenu par chaque variable attack et action ;
86
– le rang obtenu par chaque variable attack et action ;
– le score et le rang des attaques ou actions qui ont été réellement utilisées par
l’attaquant ;
– le score et le rang des techniques d’investigation utilisées pour trouver les attaques (les variables tech n’ont été mesurées qu’avec les cas du tome 2 et seulement avec la base de données des attaques, l’analyse des techniques d’investigation n’étant pas possible avec la base ICAT (cf. 3.1.1)) ;
– le temps de calcul pour chaque plan d’investigation (création du réseau et inférence).
Nous n’avons pas retenu de résultats sur les autres variables pour différentes raisons :
– les variables loss, car ces variables ne sont que des entrées au système ;
– les variables soft, car les challenges que nous avons étudiés ne contenaient pas
de descriptions exhaustives de la configuration des systèmes compromis.
Nous avons regroupé les variables attack et action, car les résultats sur les variables
action sont minoritaires par rapport à ceux sur les variables attack. En effet, la plupart
des plans d’investigation analysés ont mis en évidence une, voire plusieurs variables
attack. Par contre, les variables action ont été en général peu utilisées, chaque plan
d’investigation contenant au plus une variable.
Ces tests ont été réalisés sur la configuration suivante :
– un Pentium IV cadencé à 2,40 GHz ;
– une distribution Linux Ubuntu 5 ;
– Python 2.4.1 ;
– le module python-psyco (python specializing compiler) 1.3.1 ;
– la base ICAT du 13 juin 2005 contenant 7630 vulnérabilités.
Pour une question d’équité entre les expériences, nous avons choisi de n’effectuer
qu’une seule passe sur chaque plan d’investigation. De cette manière, les plans d’investigation présentés ci-dessous ont subit un traitement identique tout au long des expériences.
3.3.4 Présentation des résultats
Sur les vingt affaires du premier tome, nous avons fait ressortir 44 attaques distinctes pouvant être représentées par une à trois attaques / actions élémentaires (certains plans d’investigation n’ont pas été pris en compte dans ce décompte car ils ne
contenaient que des actions de type scan, c’est-à-dire des sondages réseaux). En ce qui
concerne le tome 2, les 19 affaires ont pu être analysées par 28 attaques distinctes. En
moyenne, pour chaque plan d’investigation, une attaque élémentaire a suffit pour décrire l’attaque de ce plan. Le tableau 3.1 représente les attaques élémentaires les plus
utilisées, les attaque de type exploitation de failles (exploit) sont les attaques les plus
nombreuses du tome 1 alors que dans le tome 2, les attaques de type usurpation (usurp)
sont prédominantes.
3.3.4.1 Contraintes sur la structure du réseau bayésien
Comme nous l’avons vu au paragraphe 1.3.4.1, il est possible d’appliquer certaines
contraintes pour la construction de la structure du réseau bayésien. Un mécanisme de
Variables
Nombre
d’utilisations
les attaquants
exploit
12
scan
6
inhib_detect
4
decrypt
3
bypass
3
usurp
2
del
2
trap
2
net_listen
2
overrun
2
bounce
1
broadcast
1
parasit
1
diversion
1
intercept
1
cnx_illic
1
blocking
1
listen
1
login_inst
1
Challenge du tome 1
87
par
Variables
usurp
exploit
embezzlement
bypass
bounce
intercept
trap
degrad
blocking
hidden_channel
diversion
scan_use
login_inst
cnx_illic
net_listen
overrun
listen
control
Nombre
d’utilisations
les attaquants
7
5
2
2
2
2
2
2
2
1
1
1
1
1
1
1
1
1
par
Challenge du tome 2
TAB . 3.1 – Les attaques analysées dand les tomes 1 et 2 de Hacker’s Challenge
moyenne des scores
écart-type des scores
à 0 variables
0.310
0, 970 · 10−2
Réseau contraint
à 3 variables
à 7 variables
0.519
0.544
1, 124 · 10−2
1, 161 · 10−2
TAB . 3.2 – Quelques statistiques sur les expériences menées sur les contraintes du
réseau bayésien
88
contrainte a été implémenté pour permettre d’effectuer des calculs plus rapidement
suivant le contexte de l’enquête. Ce mécanisme permet de fixer certaines variables
comme racines du réseau bayésien (les variables racines sont des variables qui n’ont
aucun parent, mais qui peuvent avoir des enfants). Ces variables sont dans l’ordre12 :
1. addr, adresse source de l’attaque ;
2. Obtain all priv, obtention des privilèges administrateur ;
3. Obtain some priv, obtention des privilèges utilisateur ;
4. Confidentiality, atteinte à la confidentialité ;
5. Integrity, atteinte à l’intégrité ;
6. Availability, atteinte à la disponibilité ;
7. Obtain other priv, obtention des droits système.
Elles correspondent aux types address et loss. Les variables de type loss ont été choisies
car elles correspondent à ce que l’utilisateur va observer en premier. Toutes les observations suivantes, notamment sur les attaques et les actions, découlent de ces premières
observations sur les dégâts. La variable address a aussi été choisie car, comme pour les
variables précédentes, les attaques et les actions effectuées par l’attaquant dépendent
de l’endroit d’où il attaque. L’utilisateur peut donc trouver un compromis entre vitesse
de calcul et précision dans le calcul. Plus le réseau donnera des résultats précis, plus
l’enquêteur pourra facilement en déduire certaines conclusions. Cette précision peut se
définir comme la possibilité pour l’enquêteur de discriminer les différentes possibilités
d’attaque et / ou d’action de manière claire et sans équivoque. Cette définition peut
être étendue aux logiciels installés et aux techniques d’investigation. D’un point de vue
statistique, cette précision peut être caractérisée par deux grandeurs :
– D’une part par l’étendue des scores du réseau. Ici, pour chaque expérience,
l’étendue est comprise entre 0,0 et 1,0 ; qui est l’étendue maximale.
– D’autre part par l’écart-type des scores. Plus l’écart type est important, plus les
scores ont une répartition large sur l’étendue des valeurs observées et sont statistiquement éloignés de la moyenne.
Nous constatons sur le tableau 3.2 une diminution de l’écart-type avec la diminution
des contraintes sur le réseau. Plus les contraintes sont importantes sur le réseau, plus
les scores seront répartis vers les extrémités de la répartition. Si l’ensemble des scores
est réparti sur l’ensemble [0.0, 1.0] de manière équitable, l’écart-type est : 0.41 · 10 −2
pour les variables d’attaques. Ce résultat correspond à un écart-type où chaque score
des variables attaques est séparé de son plus proche voisin de
d=
1
≈ 0.52 · 10−2
21
La moyenne de ces scores fictifs est donc :
moy =
12 cet
P21
d∗i
21
i=1
ordre est fonction du taux de présence de la variable dans les enquêtes que nous avons analysées
89
F IG . 3.18 – Scores de la plateforme avec contraintes
et l’écart-type :
P21
∗ i − moy)2
≈ 0.41 · 10−2
212
Si l’ensemble des scores est réparti équitablement sur les bornes de l’ensemble [0.0, 1.0]13 ,
l’écart-type est : 1.18 · 10−2 pour les variables d’attaques. Ce résultat correspond à
un écart-type où les scores sont totalement séparés de part et d’autre de la moyenne.
Le meilleur écart-type correspond donc à une grandeur comprise entre 0.41 · 10 −2 et
1.18 · 10−2 . Le résultat est similaire pour les variables action. Nous pouvons constater
dans le tableau 3.2 qu’un réseau avec aucune contrainte a un écart-type qui correspond
à ces résultats. Par contre, lorsqu’il y a 7 variables contraintes, le réseau ne propose
pas de solutions qui puissent être utilisé par les enquêteurs. Dans ce cas de figure, un
réseau typique propose que des scores 1.0 ou que des scores à 0.0. Dans le cas où il n’y
a que trois variables contraintes, l’écart-type se situe juste à la limite entre 0.41 · 10 −2
et 1.18 · 10−2 . Ceci signifie que pour certains cas, cette contrainte a pu fournir à l’enquêteur des résultats aussi précis que lorsque le réseau ne subissait aucune contrainte.
Les figures 3.18 et 3.19 montrent la diminution de cette précision avec l’augmentation des contraintes sur le réseau bayésien. Ces figures représentent l’amplitude des
scores sur l’ensemble des réponses du moteur. La figure 3.18 montre la répartition des
scores des variables attack et action à 0.0 et 1.0. La figure 3.19 provient des mêmes
résultats mais nous avons ajouté une courbe qui lisse l’histogramme de la figure 3.18.
Les histogrammes ont l’équation suivante :
et =
∀s, F (s) =
13 c’est-à-dire
i=1 (d
N h
X
i
si (state = ”true”) = s | 0
10 variables ayant un score de 0.0 et 11 un score de 1.0
i
(3.1)
90
F IG . 3.19 – Scores de la plateforme avec contraintes
avec
– N le nombre de variables recensées dont on cherche à évaluer le score ;
– s le score de la variable analysée arrondie au centième le plus proche14 ;
– si (state = ”true”) le score de la variable i pour l’état true.
h
i
La ligne
si (state = ”true”) = s | 0
est égale à 1 si la valeur de si (state =
”true”) est égale à s, et à 0 sinon. Nous retrouvons le résultat précédent, dans lequel
plus le réseau est contraint, plus les scores se rapprochent des bornes de l’intervalle,
plus l’écart-type est important. Ceci implique que plus le réseau est contraint, moins
la distribution des scores est homogène. Tous les résultats sont radicalisés, c’est-à-dire
qu’ils se rapprochent des bornes (scores 0,0 ou 1,0). Au niveau rapidité, plus le réseau
est contraint, plus le calcul du réseau bayésien (apprentissage et inférence) est rapide
(cf. figure 3.20). On peut remarquer sur cette figure que le temps de calcul peut être
excessivement long pour certaines attaques (typiquement pour des réseaux bayésiens
où le nombre des cas trouvés dans la base de données dépasse les 200). Ces temps excessivement long sont notamment dus au fait que la librairie est un prototype en Python
et que ce langage n’est pas très rapide (c’est un langage interprété à base de machine
virtuelle comme le langage Java). Une réécriture en C améliorerait grandement les performances. Mise à part la valeur absolue des résultats, ce graphique est néanmoins
intéressant car il montre que pour toutes les contraintes nous obtenons le même facteur
de forme entre chaque courbe.
14 nous
calculons en fait des intervalles intercentiles
91
F IG . 3.20 – Temps de calcul (construction et inférence du réseau bayésien) pour chaque
expérience
3.3.4.2 Changement de bases de données
Nous décrivons dans cette partie les avantages qu’apportent l’utilisation de bases
de données différentes seules ou concaténées.
Les différents graphiques ont été calculés en répertoriant toutes les attaques observées et en notant leur rang. Quand certaines attaques avaient des scores égaux, nous
avons pris le cas le plus pessimiste, par exemple :
..
. ···
4
5
6
7
..
.
usurp 0,89
exploit 0,75 (observé)
bypass 0,75
blocking 0,60
···
Dans cet exemple, l’attaque exploit a été utilisée mais les scores des variables exploit
et bypass sont égaux Dans ce cas la valeur de rang retenue sera donc 6.
Les rangs calculés peuvent être classés en trois catégories. Une première catégorie,
entre les rangs 0 et 5, pour laquelle le résultat calculé est très pertinent. Une deuxième
catégorie, entre 6 et 15, pour laquelle le résultat calculé est moyennement pertinent, une
dernière catégorie, pour laquelle le résultat calculé n’est pas pertinent. Cette dernière
catégorie peut être aussi interprétée comme une impossibilité du moteur à trouver un
cas dans la base de données qui soit similaire à l’enquête en cours. Ces différentes
92
rangs ≤ 5
5 < rangs < 16
rangs ≥ 16
rang moyen des attaques réelles
écart-type du rang
des attaques réelles
Challenges du tome 1
ICAT
ICAT +
Enquêtes
54%
61%
13%
21%
33%
18%
9, 81
6, 97
23%
23%
54%
14, 11
1, 20
1, 99
0, 86
ICAT
Challenges du tome 2
Enquêtes
ICAT +
Enquêtes
37%
40%
26%
40%
37%
20%
10, 51
8, 63
1, 42
0, 94
TAB . 3.3 – Quelques statistiques sur les expériences menées sur les différentes bases
de données
catégories sont observables sur les figures 3.21, 3.22, 3.23 et dans le tableau 3.3.
Sur tous ces graphiques, nous pouvons observer un maximum pour la première catégorie (très pertinent), une partie plate pour la deuxième catégorie et à nouveau un
maximum (souvent exponentiel) pour la troisième catégorie. Ces observations simples
nous permettent de dire que la plateforme a de bonnes réactions. Une proportion importante des attaques ou des actions réellement utilisées par les attaquants se placent
dans la catégorie très pertinent. Néanmoins, l’existence du maximum de la troisième
partie montre que toutes les attaques ne sont pas découvertes. Les variables dans cette
zone correspondent la plupart du temps à des scores de 0,0 et donc au dernier rang.
Ce maximum signifie que les bases de données que nous utilisons ne sont pas suffisament complètes pour qu’il soit possible de calculer un score. Ce manque de données
est significatif sur la figure 3.21. Cette figure représente deux séries d’expériences sur
les cas du tome 1. La première analyse a été faite en utilisant la base ICAT seule et la
deuxième en utilisant la base ICAT et la base des enquêtes, construite grâce aux résultats de ce tome 1. Pour cette deuxième série d’expériences, nous analysons le tome 1
avec les résultats du tome 1 ; mais ces résultats sont mélangés avec les échantillons de
la base de données de vulnérabilités, ce qui va non seulement nous permettre de caractériser les possibilités d’apprentissage de notre approche mais aussi de montrer que le
maximum de la dernière catégorie est bien dû à un manque de données de nos bases
et qui empêche le moteur d’inférences de calculer un score. Dans la deuxième série
d’expériences, nous avons donc mélangé deux bases de données différentes sémantiquement, mais en nous conformant aux restrictions décrites dans le paragraphe 2.3.4,
notamment sur la variable address qui n’aura que deux états possibles (local et internextern) et sur la sémantique des résultats qui est un mélange entre une sémantique sur
les vulnérabilités et une sémantique sur les attaques. Nous pouvons dire que les résultats sont meilleurs en utilisant la base ICAT avec la base des enquêtes qu’en utilisant
seulement la base ICAT. Ceci est très visible notamment par le fait que le maximum
de la troisième zone a considérablement diminué par rapport au reste du graphique, ce
qui prouve bien que ce maximum est dû à un manque de données en entrée du moteur
d’inférence.
93
F IG . 3.21 – Tome 1 : rang des attaques en utilisant la base ICAT puis la base ICAT et
la base des enquêtes
Le tableau 3.3 présente d’une part, les pourcentages des rangs des attaques réellement utilisées par les attaquants pour chacune des catégories citées ci-dessus, et d’autre
part, les moyennes et les écarts-type de ces rangs. Pour les challenge du tome 1, nous
observons de nouveau que l’ajout de la base des enquêtes améliore sensiblement les résultats, le rang moyen des attaques réelles passe de 9,81 à 6,97 et nous observons aussi
une nette augmentation des rangs inférieurs ou égaux à 5 et une diminution des rangs
supérieurs ou égaux à 16. Ces observations permettent de montrer que l’apprentissage
permet de donner de meilleurs résultats sur les attaques réellement utilisées et permet
aussi de diminuer le nombre de cas non résolues par le moteur (rangs supérieurs ou
égaux à 16).
On retrouve les mêmes résultats pour les challenges du tome 2. Le rang des attaques utilisées est nettement meilleur entre les expériences avec la base ICAT et les
expériences avec la base des enquêtes. Ce résultat est encore meilleur entre les expériences avec la base des enquêtes et la troisième base (ICAT + Enquêtes).
3.3.4.3 Analyse des résultats sur les techniques d’investigation
L’analyse des techniques d’investigation n’a pu être faite qu’avec le deuxième tome
de Hacker’s Challenge car ces techniques ne sont pas présentes dans la base ICAT mais
94
F IG . 3.22 – Tome 2 : rang des attaques en utilisant la base ICAT puis la base des
enquêtes
95
F IG . 3.23 – Tome 2 : rang des attaques en utilisant la base ICAT puis la base ICAT et
la base des enquêtes
96
Score moyen des techniques utilisées
Ecart-type de ces scores
Rang moyen des techniques utilisées
Ecart-type de ces rangs
17, 81
4, 18
5, 0
0, 50
TAB . 3.4 – Les résultats du tome 2 sur les techniques d’investigation
check_syst
log_net
var_syst
check_net
topo_int
physic
topo_ext
image
comm
retrieve
12
7
3
2
2
2
2
1
1
0
TAB . 3.5 – Les techniques d’investigation utilisées pour le tome 2
seulement dans la base des enquêtes. Le tableau 3.5 présente les techniques d’investigation les plus utilisées dans les challenges du tome 2. Nous pouvons noter que le score
moyen des techniques d’investigation réellement utilisées est faible (cf. Tab. 3.4). Il
est à l’image du score moyen des attaques et des actions réellement utilisées sur le
tome 2 et en utilisant seulement la base des enquêtes. Le rang moyen est égal à 5, 0,
la médiane. Ces résultats sont similaires aux résultats sur les attaques et les actions
présentés ci-dessus. Nous n’avons malheureusement pas assez de cas pour tirer des
conclusions générales sur ces résultats, mais nous pouvons extrapôler quelques idées.
La base des enquêtes n’est pas assez importante, il faudrait intégrer beaucoup plus de
cas pour permettre une réponse plus fiable du moteur. Ce nombre de cas à intégrer
est assez incertain. Comme précédemment il faudrait que chaque logiciel soit mis en
correspondance avec une ou plusieurs techniques d’investigation, ce qui représente un
travail long et fastidieux difficile à effectuer à l’heure actuelle. Le mélange de plusieurs
bases de données de sémantiques différentes pour les techniques d’investigation peut
être aussi un atout comme dans le cas des attaques et des actions. Dans le cas de la base
ICAT, la sémantique des techniques d’investigation serait très similaire à la sémantique
de la base des enquêtes. Dans les deux cas, les techniques d’investigation sont utilisées
pour découvrir des indices ou des preuves sur les systèmes informatiques compromis.
Il y aurait donc pas de problème au niveau sémantique et les résultats seraient plus
fiables, si on se réfère aux analyses précédentes sur les attaques et les actions.
3.3.4.4 Discussion
Grâce aux expériences effectuées ci-dessus, nous pouvons mettre en évidence plusieurs inconvénients et avantages de notre modèle. Tout d’abord, on constate que dans
97
l’état actuel des travaux le calcul d’un réseau prend énormément de temps, ceci s’expliquant en partie par la taille des réseaux bayésiens que nous calculons : une variable
d’adressage, 21 attaques, 20 actions, 7 dégâts et 10 techniques d’investigation, ce qui
fait un total de 59 nœuds sans compter les logiciels que l’on ajoute dynamiquement.
Ces nœuds sont reliés entre eux par plusieurs arcs en général ce qui augmente la complexité du calcul.
Ensuite, nous pouvons observer qu’un grand nombre d’attaques utilisées ont des
rangs situés dans la troisième catégorie (peu pertinente). C’est un problème d’exhaustivité de nos bases, difficile à résoudre. Ce problème d’exhaustivité signifie que ces
bases, et notamment la base des enquêtes, ne contient pas assez d’échantillons pour
pouvoir traiter les cas de figures potentiels. C’est un des inconvénients majeurs de
notre approche.
Cependant les avantages de notre approche sont nombreux. Premièrement, le système s’enrichit avec le résultat des enquêtes précédemment traitées. Deuxièmement,
malgré les différences de taille entre la base ICAT et la base complémentaire, la fusion a un effet bénéfique sur les résultats produits. L’ajout de données supplémentaires
dans la base de connaissance a donc un effet immédiat sur le comportement du réseau
bayésien.
Enfin, notre méthode permet de montrer à l’utilisateur les attaques les plus probables en les classant et en montrant, grâce aux scores, les écarts entre différents
groupes d’attaque. Par exemple, si l’utilisateur observe :
1 attack_a 0,89
2 attack_b 0,75
3 attack_c 0,75
4 attack_d 0,20
5 attack_e 0,15
6 attack_f 0,14
..
. ···
Cela peut être une indication forte sur l’attaque ou les attaques qui ont pu être utilisées.
98
Conclusion
Bilan
Notre travail a consisté à proposer une approche permettant d’assister les enquêteurs informatiques dans leurs recherches des auteurs de délits et crimes informatiques.
Nous avons proposé un modèle comportemental de l’enquêteur. Ce comportement
est guidé par la connaissance de la configuration des systèmes compromis et par les
observations constatées. Ce modèle apporte une aide au processus d’investigation, tout
en le rendant plus facile et plus compréhensible pour les non-spécialistes. Ce modèle
permet en outre une certaine automatisation, dans le sens où l’enquêteur peut s’affranchir de certaines recherches fastidieuses, comme l’analyse systématique de tous
les fichiers, puisque le moteur peut proposer des éléments de réponse sous forme de
techniques d’investigation couplées à des éléments à analyser, comme par exemple des
noms de fichiers, voire des chaînes de caractères à rechercher dans ces fichiers.
Il est aussi possible de mettre en évidence plusieurs points capitaux pour l’enquête :
– les points faibles du système étudié en montrant les logiciels les plus vulnérables ;
– les meilleures attaques et actions possibles du point de vue de l’attaquant, en
utilisant la configuration logiciel du système compromis ;
– les méthodes à utiliser sur le système compromis pour retrouver des indices ou
des preuves de l’attaque.
Notre approche permet non seulement de proposer des solutions d’analyse sur des attaques connues (vulnérabilités connues) mais elle permet aussi de proposer des solutions sur des attaques qui sont inconnues au moment de cette analyse. Ceci est possible
car le modèle que nous avons mis en place est assez souple pour permettre la description de n’importe quelle attaque.
Tous les résultats des analyses sont conservés et peuvent être réutilisés de plusieurs
manières différentes :
– les attaques peuvent être mises dans une base de données annexe, pour enrichir
la détection des attaques futures et pour enrichir l’analyse de ces attaques grâce
à des techniques d’investigation plus évoluées ;
– les attaques et enquêtes peuvent être rejouées, soit à des fins d’explication devant
une cour de Justice par exemple ; soit à des fins d’apprentissage.
– un rapport peut être édité automatiquement pour pouvoir être présenté ensuite
devant la Justice, devant d’autres enquêteurs, etc.
99
Développements futurs
Notre prototype intéresse plusieurs organismes étatiques (DGA/CELAR, DST, SRPJ,
etc.). Nous voulons donc continuer les développements pour le mettre à disposition des
personnes intéressées. Pour cela, nous voulons travailler sur plusieurs axes :
L’utilisation éventuelle d’un nouveau moteur d’inférences. Ce mémoire présente les
réseaux bayésiens comme une bonne solution pour répondre à nos besoins, mais
il pourrait être intéressant de comparer les premiers résultats obtenus avec ceux
produits avec un autre modèle.
L’utilisation de nouveaux algorithmes pour l’apprentissage et l’inférence de nos réseaux bayésiens. Ce mémoire a présenté un certain nombre d’algorithmes. Nous
en avons choisi deux qui présentaient à nos yeux les meilleurs rapports qualité
- vitesse de calcul. Ce choix a été fait d’une part par une analyse de chaque
algorithme et d’autre part par quelques expérimentations sur un logiciel tiers.
L’objectif serait d’effectuer des expérimentations plus poussées, en utilisant les
réseaux tels qu’ils sont construits en ce moment pour trouver si certains algorithmes donnent des résultats de meilleure qualité. En outre, nous voudrions analyser si cette qualité évolue avec des situations d’enquêtes différentes.
La construction d’une base de données des enquêtes plus importante. Comme nous
l’avons vu, nous utilisons deux bases de données, la base ICAT qui a une taille
importante et la base des résultats d’enquêtes qui a, au contraire, une très petite
taille. Pourtant cette dernière possède des qualités indéniables pour l’enquêteur.
Il faudrait continuer l’incorporation de connaissances au sein de cette dernière.
Ces connaissances doivent provenir de cas réels analysés par des enquêteurs professionnels.
La création de plusieurs bases de données en vue de les spécialiser sur certains types
affaires (pédopornographie, affaires financières, affaires propres à la DST, IRCGN,
SRPJ, etc.). L’objectif serait d’analyser les différents besoins et de déterminer le
type de base de connaissances correspondant le mieux à ces besoins.
La ré-écriture de la librairie pyBN en C pour permettre une analyse des attaques plus
rapide. La figure 3.20 montre que certains calculs prennent beaucoup trop de
temps pour pouvoir être exploitable opérationnellement.
Une interface homme-machine améliorée, simple et intuitive. L’analyse criminelle
informatique est une activité complexe, qui nécessite des outils ergonomiques.
Cette ergonomie devra être travaillée en relation avec les utilisateurs finaux, en
particulier avec la police et la gendarmerie.
La construction d’un profil d’attaquant pour pouvoir reconnaître des attaquants connus
ou des styles d’attaques connus. Les forces de police utilisent de plus en plus les
profils de criminels, notamment pour les crimes de sang en série. L’objectif serait
d’étudier la création et l’utilisation de ces profils et de voir comment cela peut-il
être transposé dans le domaine informatique.
la construction de liaisons fortes entre les plans d’investigation : cela permettrait à la
plateforme de proposer des attaques qui ont éventuellement pu avoir lieu avant
ou après le plan d’investigation en cours d’analyse.
Bibliographie
[BC99]
Hal Burch and Bill Cheswick. Tracing anonymous packets to their approximate source. Technical report, Canergie Mellon University - Lumeta
Corps., 1999.
[BC04]
Nicole Lang Beebe and Jan Guynes Clark. A hierarchical, objectivesbased framework for the digital investigations process. In Digital Forensic
Research Workshop, Baltimore, Maryland, august 2004.
[BFOS84] L. Breiman, J. H. Friedman, R. A. Olshen, and C. J. Stone. Classification
and regression trees. Technical report, Wadsworth International, Monterey, CA, 1984.
[BT04]
Venansius Baryamureeba and Florence Tushabe. The enhanced digital
investigation process model. Technical Report 2, Makerere University
Institute of Computer Science, june 2004.
[Car03]
Brian Carrier. Defining digital forensic examination and analysing tools
using abstraction layers. International Journal of Digital Evidence,
1(4) :1–12, 2003.
[Cas01]
Eoghan Casey, editor. Handbook of Computer Crime Investigation : Forensic Tools & Technology. Academic Press, 1 edition, October 2001.
ISBN : 0121631036.
[CBL97a]
Jie Chang, David Bell, and Weiru Liu. An algorithme for bayesian network construction from data. In the 6th International Workshop on Artificial Intelligence and Statistics AI&STAT’97, pages 83–90, 1997.
[CBL97b] Jie Chang, David Bell, and Weiru Liu. Learning belief networks from
data : an information theory based approach. In the sixth ACM International Conference on Information and Knowledge Management CIKM, pages
325–331, 1997.
[CGH95]
D. Chickering, D. Geiger, and D. Heckerman. Learning bayesian networks : Search methods and experimental results. In Preliminary Papers
of the Fifth International Workshop on Artificial Intelligence and Statistics, pages 112–128, 1995.
[CGK+ 02] Jie Chang, Russel Greiner, Jonnathan Kelly, David Bell, and Weiru Liu.
Learning bayesian networks from data : an information theory-based approach. Artificial Intelligence, 137 (1-2) :43–90, 2002.
101
102
BIBLIOGRAPHIE
[CH92]
G.F. Cooper and E. Herskovits. A bayesian method for the induction of
probabilistic networks from data. Machine Learning, 9 :309–347, 1992.
[CHE]
Cheops. http ://www.marko.net/cheops/. logiciel de cartographie réseau.
[CL68]
C. Chow and C. Liu. Approximating discrete probability distributions
with dependence trees. IEEE Transactions on Information Theory,
14(3) :462–467, May 1968.
[CLU04]
CLUSIF. Panorama de la cybercriminalité - année 2004. Technical report,
CLUSIF, 2004.
[Con03]
CTOSE Consortium.
Cyber tools on-line search for evidence.
http ://www.ctose.org, 2003.
[Coo90]
G. Cooper. Computationnal complexity of probabilistic inference using
Bayesien belief networks. Artificial Intelligence, 1990.
[Daw79]
A.P. Dawid. Conditional independence in statistical theory. Journal of the
Royal Statistical Society, 41(1) :1–39, 1979.
[DCF]
Dod computer forensics laboratory data duplicator.
fldd.sourceforge.net/. une version modifiée de dd.
[Dif82]
John Diffenbach. Influence diagrams for complex strategic issues. Strategic Management Journal, 3-2 :133–146, 1982.
[Dun06]
Référenciel Dunod. Radiographie de la criminalité économique dans les
entreprises françaises. Protection des systèmes d’information, 2006.
[EC]
Encase. http ://www.guidancesoftware.com. Outil pour l’analyse d’image
disque.
[ES95]
Kazuo J. Esawa and Til Schuermann. Fraud / uncollectible debt detection
using a bayesian network base learning. In Philippe Besnard and Steve
Hanks, editors, Proceedings of the Eleventh Conference of Uncertainty in
Artificial Intelligence, San Mateo, California, 1995.
[ES03]
Brian Carrier Eugene and H. Spafford. Getting physical with the digital investigation process. International Journal of Digital Evidence, 2(2), 2003.
http://www.ijde.org/docs/03_fall_carrier_Spa.pdf.
[ET01]
Christopher Elsaesser and Michael C. Tanner. Automated diagnosis for
computer forensics. Technical report, MITRE Corporation, august 2001.
[FBI04]
CSI / FBI. Computer crime and security survey. Technical report, Computer Security Institute, 2004.
[FC89]
Robert Fung and Kuo-Chu Chang. Weighing and integrating evidence for
stochastic simulation in bayesian networks. 5 :209–219, 1989.
http ://dc-
[FKP+ 99] Rich Feiertag, Cliff Kahn, Phil Porras, Dan Schnackenberg, Stuart
Staniford-Chen, and Brian Tung. A common intrusion specification language (cisl). Technical report, University of Southern California’s Information Sciences Institute (ISI), 1999.
[FV]
D. Farmer and W. Venema.
The coroner’s
http ://www.porcupine.org/forensics/tct.html. (Forensics tools).
toolkit.
BIBLIOGRAPHIE
[FW04]
103
Mark Foster and Joseph N. Wilson.
Process forensics : A pilot study on the use of checkpointing technology in computer forensics.
International Journal of Digital Evidence, 3(1), 2004.
http://www.ijde.org/docs/foster.pdf.
[GHK+ 98] M. Ghallab, A. Howe, C. Knoblock, D. Mc Dermott, A. Ram, M. Veloso,
D. Weld, and D. Wilkins. PDDL the Planning Domain Definition Language. Technical report, Yale University, 1998.
[Gla04]
Pavel Gladyshev. Formalisation of event reconstruction problem. PhD
thesis, University College Dublin, 2004.
[Goo02]
Michael T. Goodrich. Efficient packet marking for large-scale ip traceback. Technical report, Department of Info. and Computer Science University of California, 2002.
[GP04]
Pavel Gladyshev and Ahmed Patel. Finite state machine approach to digital event reconstruction. Digital Investigation journal, 1(2), 2004.
[HB95]
E. Horvitz and M. Barry. Display of information for time-critical decision
making. In Philippe Besnard and Steve Hanks, editors, Proceedings of the
Eleventh Conference of Uncertainty in Artificial Intelligence, San Mateo,
California, 1995.
[Heb49]
Donald Hebb. The organization of behavior : A neuropsychological
theory. Wiley, 1949.
[HEL]
Helix. http ://www.e-fense.com/helix/index2.html. distribution Linux tenant sur un CD et spécialiser dans l’analyse forensique.
[Hen88]
M. Henrion. Propagating uncertainty in bayesian networks by probalistic
logic sampling. 2 :149–163, 1988.
[HGC94]
D. Heckerman, D. Geiger, and D. Chickering. Learning bayesian networks : The combination of knowledge and statistical data. Machine Learning, 20 :197–243, 1994.
[HNT]
Honeynet. http://project.honeynet.org. pot de miel informatique.
[IL]
Ilook. http ://www.ilook-forensics.org/. Outil pour l’analyse d’image
disque.
[IST]
Ists,
institute
for
security
http://www.ists.dartmouth.edu/.
[Jen98]
K. Jensen. A brief introduction to colored petri nets. In Proc. Workshop
on the Applicability of Formal Models, 2 June 1998, Aarhus, Denmark,
pages 55–58, 1998.
[Jeu02]
Brieuc Jeunhomme. Introduction au firewalling. Multi-System & Internet
Security Cookbook, 2002.
[KER]
Kerf, infrastructure for distributed collaboration in detecting network attacks. http://kerf.cs.dartmouth.edu.
technology
studies.
104
BIBLIOGRAPHIE
[Kjæ94]
U. Kjærulff. Reduction of computational complexity in bayesian networks
through removal of weak dependences. In Proceedings of the Tenth Conference on Uncertainty in Artificial Intelligence, San Francisco, CA, USA,
1994. Morgan Kaufmann Publishers Inc.
[KNO]
Knoppix. http ://www.knoppix.net/. distribution Linux tenant sur un CD
complet (1.8Go compressé).
[Koh89]
T. Kohonen. Self-Organization and associative memory. Springer-Verlag
New York, Inc., New York, NY, USA, 1989. ISBN : 0-387-51387-6.
[LC]
Linuxcare. http ://www.lnx-bbc.org/. mini distribution Linux.
[LGD]
[LK04]
Languard. http ://www.gfisoftware.com.
Ryan Leigland and Axel W. Krings. A formalization of digital forensics.
[LL00]
Tod S. Levitt and Kathryn Blackmond Laskey. Computational inference
for evidential reasoning in support of judicial proof. In Symposium - Artificial Intelligence and Judiciary Proofs, 2000.
[LMMP59] J. Y. Lettvin, H. R. Maturana, W. S. McCulloch, and W. H. Pitts. What the
frog’s eye tells the frog’s brain. In Proceedings of the Institute of Radio
Engineers, volume 47, pages 1940–1951, 1959.
[LS90]
S. L. Lauritzen and D. J. Spiegelhalter. Local computations with probabilities on graphical structures and their application to expert systems. pages
415–448, 1990.
[McK99]
Rodney McKemmish. What is forensic computing ? Trends & Issues in
Crime and Criminal Justice, 118, june 1999. ISBN 0 642 24102 3.
[Mic02]
Cédric Michel. Langage de descriptions d’attaques pour la détection
d’intrusions en environnement réseau hétérogène. PhD thesis, Supélec
Rennes, 2002.
[MP01]
Kevin Mandia and Chris Procise. Incident Response : Investigating
Computer Crime. McGraw-Hill Osborne Media, June 2001. ISBN :
0072131829.
Sharon D. Nelson and John W. Simek.
Takedowns :
legendary
successes
in
computer
forensics.
http://www.vsb.org/publications/valawyer/apr02/tech_law.pdf,
april 2002.
[NS02]
[NWL+ 04] Patrick Naïm, Pierre-Henri Wuillemin, Philippe Leray, Olivier Pourret,
and Anna Becker. Réseaux bayésiens. Eyrolles, 2004.
[OPN]
[Pal01]
[Pea88]
Opnet. http ://www.opnet.com.
Gary Palmer.
A road map for digital forensic research.
Technical report, DFRWS, November 6 2001.
http://www.dfrws.org/dfrws-rm-final.pdf.
Judea Pearl. Probabilistic reasoning in intelligent systems : networks of
plausible inference. Morgan Kaufmann Publishers Inc., San Francisco,
CA, USA, 1988.
BIBLIOGRAPHIE
[Pet62]
[PV91]
[PYF]
105
Carl Adam Petri. Kommunikation mit Automaten (Communication with
Automata). PhD thesis, Institut fur Instrumentelle Mathematik, Bonn,
1962.
J. Pearl and T. Verma. A theory of inferred causation. In J.A. Allen,
R. Fikes, and E. Sandewall, editors, Principles of Knowledge Representation and Reasoning : Proceedings of the Second International Conference,
pages 441–452, San Mateo, CA, 1991.
Python forensic and log analysis gui. http ://pyflag.sourceforge.net/.
[QR89]
J. Ross Quinlan and Ronald L. Rivest. Inferring decision trees using
the minimum description length principle. Information and Computation,
80 :227–248, 1989.
[Sch01]
Mike Schiffman. Hacker’s Challenge : Test Your Incident Response Skills
Using 20 Scenarios. McGraw-Hill Osborne Media, October 2001. ISBN :
0072193840.
[Sch02]
Mike Schiffman. Hacker’s Challenge II. McGraw-Hill Osborne Media,
October 2002. ISBN : 0072193840.
[SGS91]
P. Spirtes, C. Glymour, and R. Scheines. An algorithm for fast recovery of
sparse causal graphs. Social Science Computer Review, 9 :62–72, 1991.
[Shi95]
Tsutomu Shimomura. Technical details of the attack described by markoff
in nyt. Article : 14059 of comp.security.misc, 1995. 25 Jan 1995 04 :36 :37
-0800.
[SL03]
Tye Stallard and Karl Levitt. Automated analysis for digital forensic
science : Semantic integrity checking. In Annual Computer Security Applications Conference, december 2003.
Task et autopsy for linux. http ://www.sleuthkit.org/index.php. Les outils
d’analyse de disque.
[SLE]
[SM96]
Tsutomu Shimomura and John Markov. Takedown. New York : Hyperion
Press, 1996.
[SP89]
Ross D. Shachter and Mark A. Peot. Simulation approaches to general
probabilistic inference on belief networks. 5 :221–231, 1989.
[Spi02]
Lance Spitzner. Honeypots : Tracking Hackers. Addisson Wesley Professionnal, 1 edition, september 2002. ISBN : 0321108957.
Tye Stallard. Automated Analysis for Digital Forensic Science. PhD thesis,
University of California, 2002.
Peter Stephenson. Investigating Computer-Related Crime. CRC Press,
2000.
Peter Stephenson.
Modeling of post-incident root cause analysis.
http://people.emich.edu/pstephen/my_papers/03_fall_stephenson.pdf.
Peter Stephenson. Structured Investigation of Digital Incidents in Complex Computing Environments. PhD thesis, Oxford Brookes University,
2003.
[Sta02]
[Ste00]
[Ste03a]
[Ste03b]
106
[Ste04]
BIBLIOGRAPHIE
Peter Stephenson. Application of formal methods to root cause analysis
of digital incidents. International Journal of Digital Evidence, 3(1), 2004.
http://www.ijde.org/docs/stephenson.pdf.
[SWKA01] Stefan Savage, David Wetherall, Anna Karlin, and Tom Anderson. Practical network support for ip traceback. Technical report, Department of
Computer Science and Engineering - University of Washington, Seattle,
2001.
[TRI]
Trinux. http ://www.trinux.org. mini distribution Linux.
[Wil03]
Svein Willassen. Forensics and the gsm mobile telephone system.
http://www.ijde.org/03_spring_art1.html, 2003.
Annexe A
La base de vulnérabilités ICAT
La base ICAT est une base de données contenant plusieurs milliers de vulnérabilités. Cette base est un produit de la Computer Security Division du National Institute of Standards and Technology. Elle peut être interrogée via le site web [http:
//icat.nist.gov/icat.cfm] ou téléchargée dans son intégralité dans les formats Excel ou CSV1 .
Via le site web, l’utilisateur peut rechercher des vulnérabilités en fonction de certains critères : identifiant, date de publication, logiciels vulnérables, description, etc. Si
l’on télécharge la base de données, on peut effectuer d’autres types de recherche.
1 Comma
Separated Value
107
108
ANNEXE A. LA BASE DE VULNÉRABILITÉS ICAT
Cette base contient plus d’une cinquantaine de champs différents :
"CVE_ID"
"Publish_Date"
"CVE_Description"
"Severity" "HL1" "HL2" "HL3" "HL4" "HL5" "Link1Source"
"Link2Source" "Link3Source" "Link4Source" "Link5Source"
"Link1Name"
"Link2Name"
"Link3Name"
"Link4Name"
"Link5Name"
"Link1Type"
"Link2Type"
"Link3Type"
"Link4Type"
"Link5Type"
"AR_Launch_remotely"
"AR_Launch_locally"
"LT_Security_protection"
"LT_Obtain_all_priv"
"LT_Obtain_some_priv"
"LT_Confidentiality"
"LT_Integrity"
"LT_Availability"
"VT_Input_validation_error"
"VT_Boundary_condition_error"
"VT_Buffer_overflow"
"VT_Access_validation_error"
"VT_Exceptional_condition_error"
"VT_Environment_error"
"VT_Configuration_error"
"VT_Race_condition"
"VT_Other_vulnerability_type" "Vuln_Software" "DT_Unix"
"DT_Win_95" "DT_Win_NT" "DT_Apple" "DT_Other_OS"
"EC_Operating_system"
"EC_Network_protocol_stack"
"EC_Non_server_application"
"EC_Server_application"
"EC_Hardware"
"EC_Communication_protocol"
"EC_Encryption_module" "EC_Other" "EC_Specific_component"
"AR_Protocol_used" "AR_Target_access_attacker" "References_a"
"Evaluator_Comments"
"Status_a"
"LT_Sec_Prot_Other"
"VT_Design_Error" "prev_ID"
Les champs les plus importants sont les suivants :
CVE_ID ce champ donne un identifiant unique pour la vulnérabilité,
CVE_Description ce champ donne une description succinte de la vulnérabilité et de
ses effets,
AR_Launch_remotely et AR_Launch_locally ce sont deux variables bouléennes (0
ou -1) qui indiquent si la vulnérabilité doit être exploitée localement ou à distance,
LT_* Loss Type, ces champs correspondent aux dégâts observables sur le système
informatique,
DT_* Domain Type, ces champs donnent le domaine d’application de la vulnérabilité,
en d’autres termes sur quel système d’exploitation la vulnérabilité est utilisable,
Vuln_Software ce champ donne une liste complète des logiciels vulnérables à cette
vulnérabilité, le nom du logiciel est complété éventuellement du nom de l’entreprise responsable du produit ainsi que de son ou de ses numéros de version.
Cette base de données est très complête mais très difficile à analyser. En effet, le
format CSV n’est pas toujours respecté, notamment au niveau des logiciels vulnérables
("Vuln_Software"), le format CSV stipule que le caractère séparateur d’échantillons
(ici les vulnérabilités) est un retour chariot, or dans ce champ, ce caractère est aussi
utilisé pour séparer les différents logiciels vulnérables. De plus, certains noms de logiciels portent à confusion, par exemple :
109
Apache Group, Apache,
Apache Group, HTTP Server,
Apache Software Foundation, Apache,
Apache, HTTP Server.
Cette base est maintenant obsolète et à été remplacée en septembre 2005 par la National Vulnerability Database (NVD) [http://nvd.nist.gov/] qui est une base
utilisant le format XML.
110
ANNEXE A. LA BASE DE VULNÉRABILITÉS ICAT
Annexe B
Construction du réseau
B.1 Apprentissage de la structure
Cet algorithme utilise un score pour restreindre l’espace de recherche. L’algorithme
utilise le score Bayesian Dirichlet (ScoreBD) avec un a priori uniforme sur les structures.
Le score peut s’écrire de la façon suivante :
ScoreBD(B, D) ≈
n
Y
g(i, pai )
i=1
avec
– B la structure du réseau,
– D les données qui permettent de construire la structure
et
g(i, pai ) =
qi
Y
r
i
Y
Γ(Nijk + αijk )
Γ(αij )
.
Γ(Nij + αij )
Γ(αijk )
j=1
k=1
– Γ étant la fonction gamma,
– n le nombre de nœuds,
– pai les parents du nœud i.
Pour maximiser ce score, Cooper et Herskovits proposent de rechercher tous les
parents pai du nœud Xi qui vont maximiser un score intermédiaire g(i, pai ). L’algorithme permet aussi de fixer une borne supérieure u qui limitera le nombre de parents
possibles. L’algorithme est décrit dans la figure B.1, Pred(X[j]) correspond aux
prédecesseurs de X[j].
111
ANNEXE B. CONSTRUCTION DU RÉSEAU
112
for i from 1 to n
pa[i] = 0
g_old = g(i, pa[i])
OK = "vrai"
repeat
find X[j] in Pred(X[i])\pa[i]
which maximize g(i, {pa[i], X[j]})
g_new = g(i, pa[i]) dans {X[j]}
if g_new > g_old alors
g_old = g_new
pa[1] = pa[1] + {X[j]}
else if
OK = "faux"
while OK and |pa[i]| < u
F IG . B.1 – L’algorithme K2
B.2 Apprentissage des paramètres
Pour calculer les paramêtres du réseau, nous avons utilisé un algorithme de type
maximum de vraisemblance, le calcul des paramêtres est un calcul statistique.
∀i ∈ {1, N }
p(Xi = ”yes”) =
avec
–
–
–
–
PM
j=1
[q (state = ”yes”) | 0]
M
N le nombre de nœuds ;
M le nombre d’échantillon ;
p(Xi = ”yes”) la probabilité du nœud Xi pour l’état ”yes” ;
q (state = ”yes”) | 0) est égale à 1 si le j me échantillon du nœud Xi est égal à
”yes”, 0 sinon.
Annexe C
Le logiciel XMeta
C.1 Enregistrement des données
Pour enregistrer les données d’une enquête (configuration logicielle des systèmes
compromis, attaques utilisées, techniques d’investigation utilisées), nous avons choisi
d’utiliser un outil intégré au langage Python : la sérialisation d’objets (paquetage Pickle). La sérialisation consiste à enregistrer dans un fichier texte ou binaire une ou
plusieurs instances d’objets, ainsi que toutes les instances d’objets qui leur sont reliées.
Dans notre cas, nous enregistrons la liste [Networks] et donc tous les System,
Software, etc.
113
114
ANNEXE C. LE LOGICIEL XMETA
F IG . C.1 – Les principaux objets de l’application XMeta
Index
aspects légaux, xvi
audit réseau, 24
Autopsy, 33
FTK (Forensic ToolKit), 35
base de connaissances, 55, 70
bayésien, réseau, 40, 43
BEFTI (Brigade d’Enquête sur les Fraudes
aux Technologies de l’Information), xvii
ICAT, 56, 70
IDS (Intrusion Detection System), 24
Ilook, 35
IRCGN (Institut de Recherche Criminelle de la Gendarmerie Nationale), xviii
IRCGN (Institut de Recherche Criminologique de la Gendarmerie
Nationale), xvii
hacker, xix
CERTA (Computer Emergencing Response Team Administration),
xviii
code pénal, xvi
criminalité informatique, xiii
CTOSE (Cyber Tools On-line Search
for Evidence), 5
Kerf, 13
Kohonen, cartes de, 37
Data Duplicator, 32
décision, arbre de, 39
délinquant, xix
DFRWS (Digital Forensic Research Workshop), xix
diagramme d’influence, 42
Distributed Denial of Service, xiii
DMZ (DeMilitarized Zone), 56
données volatiles, 21
DST (Direction de la Surveillance du
Territoire), xviii
duplication, 23
Encase, 33
enquêteur, xix
FBI (Federal Bureau of Investigation),
xiv
fichiers d’audit, 19
fichiers temporaires, 21
moteur d’inférences, 55
neurones, réseau de, 36
OCLCTIC (Office Central de Lutte contre
la Criminalité liée aux Technologies de l’Information et
de la Communication), xvii
pare-feu, 24
pédopornographie, xvii
Petri, réseau de, 38
pirate informatique, xix
plan d’investigation, 55
pot de miel, 26
préservation des traces, 23
preuve physique, 32
Sleuthkit, 33
SRPJ (Services Régionaux de Police Judiciaire), xvii
115
116
systèmes experts, 35
systèmes zombies, xiii
topologie du réseau, 29
Wifi (Wireless Fidelity), 56
INDEX
VU :
Le Directeur de Thèse
VU :
Le Responsable de l’École Doctorale
VU pour autorisation de soutenance
Rennes, le
Le Président de l’Université de Rennes 1
Bertrand FORTIN
VU après soutenance pour autorisation de publication :
Le Président du Jury,

analyse informatique post-mortem

Transcription

Documents pareils

Séminaire CyberSécurité 2015

Communiqué du Sharp paris et plus généralement des skinheads

+mot - aramis

inspecteur general du holding d`amenagement al omrane

Lire la suite - Nicolas Arpagian

panzers-p001-009 debut

Théorie sur la motivation d`un DDos par un pirate

ATTI AMCX

Décès de Gabriel Marc, ancien président du CCFD