Rapport d'activités

1 Rappel de la proposition (voir aussi le texte de la proposition)

Ce projet se situe dans le domaine de la détection d'intrusions, pour laquelle deux principales approches peuvent être adoptées : la détection supervisée et la détection non supervisée.

Les méthodes issues de la détection supervisée échouent face à une attaque qui ne fait pas partie de la liste prédéfinie. En d’autres termes, ces approches n’offrent aucune une résistance aux nouvelles attaques.

Le deuxième type d’approches repose sur la détection d’anomalies (ou comportements atypiques). Avec une première phase d’apprentissage (généralement de la fouille de données), ce type de méthode établit une base de connaissances sur les comportements « normaux ». Dès qu’un comportement s’écarte trop de ceux enregistrés dans cette base, il est considéré comme anormal ou atypique. Bien entendu, tous les comportements atypiques ne sont pas malveillants. Si un comportement atypique est, à tort, considéré comme une attaque et lève le déclenchement d’une alarme, alors on dit qu’il s’agit d’un faux positif (ce qui correspond d’ailleurs à une fausse alarme…).

L'objectif du projet MUTAN est la réduction du nombre de faux positifs dans la détection d’anomalies. Pour cela nous avons exploré une stratégie basée sur le partage des anomalies entre les systèmes à surveiller.

L'idée principale est que la découverte d'une faille par un utilisateur malveillant :

1. sera exploitée sur plus d'un site et

2. sera classée parmi les anomalies.

La justification du premier point vient du fait que les systèmes surveillés reposent sur un nombre limité d'architectures (Oracle, PHP, etc...). En revanche, les données stockées par ces systèmes seront différentes. Par exemple, deux laboratoires de recherche partagent le même logiciel en ligne de gestion de l'annuaire mais les contenus sont différents (les chercheurs ne sont pas les mêmes).

Si la requête « annuaire/req.php?nom=../../etc/passwd¹ » est effectuée sur les sites Web de deux laboratoires distincts, on peut en déduire que ce n'est pas normal (ils ne sont pas censés partager les mêmes chercheurs). En réalité, l'utilisateur qui fait cette requête fait le pari qu'elle va fonctionner sur un site (au moins) dans une liste de sites (potentiellement victimes de l'attaque).

Ainsi, nous supposons qu'en filtrant les anomalies pour ne garder que celles qui sont partagées entre plusieurs sites, nous devrions obtenir une liste de tentatives d'intrusion.

2 Participants

Ce projet réunissait deux partenaires académiques :

• Le projet AxIS de l'Inria Sophia Antipolis Méditerranée : Céline Fiot (post-doc), Alice Marascu (doctorante) et Florent Masseglia (CR1).

• Le projet KDD du LGI2P (Nîmes) : François Trousset (Dr.) et Pascal Poncelet (Prof.).

Nous avons également obtenu la participation de l'IRISA, via ses services informatique et sécurité, pour travailler sur les logs d'accès Web de ce Centre.

3 Stages

Nous avons co-encadré 3 stagiaires financés par cette action :

• « Détection d'anomalies partagées ». Goverdhan Singh, étudiant de l'Indian Institute of Technology (IIT), Guwahati (Inde). L'objectif de Goverdhan était de proposer et d'implémenter une architecture de détection d'anomalies partagées entre les logs de navigations sur plusieurs sites. Ce travail a donné lieu a une publication internationale [2], une publication nationale [4] et un rapport de stage [9]. Ces résultats sont également en cours de soumission dans un ouvrage international [6]La section 5.2 résumé cette proposition. Encadrement : Céline Fiot, Alice Marascu, Florent Masseglia et Pascal Poncelet.

• « Détection d'intrusions dans un environnement collaboratif sécurisé ». Nischal Verma, étudiant de l'Indian Institute of Technology (IIT), Guwahati (Inde). L'objectif de Nischal était de proposer une approche de détection d'intrusions dans un environnement collaboratif. Toutefois comme les données manipulées sont sensibles il était important de proposer un cadre générique qui puisse garantir la préservation des données privées de tous les sites collaboratifs. Une nouvelle approche a été proposée et permet de garantir que ni la requête à tester ni les contenus des sites ne peuvent être divulgués à l'extérieur. Ce travail a donné lieu à une publication nationale [3] et est en cours de soumission dans un ouvrage international [7]. Encadrement : François Trousset, Pascal Poncelet et Florent Masseglia.

• « Détection de motifs séquentiels avec une granularité de temps optimale ». Gaurav Pathari, étudiant du Laxmi Niwas Institute of Information Technology (LNMIIT) Jaipur (Inde). L'objectif de Gaurav était d'extraire des motifs séquentiels ayant un support significatif sur une période limitée. Malheureusement, l'aspect combinatoire de ce problème s'est avéré plus difficile qu'exprimé dans le sujet. Ce sujet reste encore à explorer et Gaurav a proposé un rapport interne [8]. Encadrement : Florent Masseglia.

4 Fonctionnement

Le projet MUTAN peut se diviser en trois temps. Dans un premier temps, nous avons défini une architecture globale, dans laquelle nous avions identifié deux défis majeurs :

1. Détecter des anomalies sur des sites et comparer ces anomalies.

2. Préserver la confidentialité des données lors des échanges entre sites.

Dans un deuxième temps, nous avons proposé des solutions sur chacun des défis. Ce travail a fait l'objet des stages décrits dans la section 3.

Enfin, le troisième temps, en cours de réalisation après la période de ce COLOR, consiste à intégrer les solutions aux deux défis, dans une même architecture logicielle.

Nos réunions se sont déroulés lors de déplacements, ou bien par audio-conférence et vidéo-conférence. Nos réunions par audio-conférence étaient hebdomadaires. Les réunions lors de déplacements visaient à nous rencontrer lors de missions vers des lieux communs aux deux partenaires (EGC 08 à Sophia Antipolis, réunions de l'ANR MIDAS le 23 mai 2008 et le 03 octobre 2008).

5 Résultats scientifiques

Les deux défis exposés en section 4 permettent d'aborder deux problèmes de recherche distincts (dans un premier temps). La section 5.1 présente les résultats que nous avons obtenus en comparant les anomalies entre plusieurs sites. La section 5.2 présente un cadre sécurisé pour effectuer ce type d'opérations. Enfin, la section 5.3 présente quelques résultats obtenus grâce aux techniques proposées dans le projet MUTAN.

5.1 Comment détecter les anomalies partagées ?

Notre idée principale est que les nouveaux usages sont spécifiques au site sur lequel ils apparaissent, alors qu'une nouvelle faille sera exploitée sur plusieurs sites utilisant le système qui présente cette faille. Notre approche consiste donc à détecter les usages inhabituels qui se produisent à la fois sur plusieurs sites et à les étiqueter comme étant des attaques. Considérons par exemple A_x, une anomalie détectée dans les usages du site S₁ et qui correspond a une requête PHP sur l'annuaire des employés pour chercher l'entrée correspondant à Jean Dupont, qui travaille bureau 204, étage 2, dans le département R&D. Cette requête sera de la forme :

staff.php?FName=Jean&LName=Dupont&room=204&floor=\&Dpt=RD

Si Jean Dupont est recruté depuis deux jours, alors cette nouvelle requête sera inhabituelle mais, pour autant, ne doit pas être considérée comme une attaque.

Considérons maintenant la requête A_y, correspondant à une anomalie et une véritable intrusion. A_y est basée sur une faille de sécurité du système (par exemple une vulnérabilité PHP) et pourrait, par exemple, être de la forme : staff.php?path=../etc/passwd%00

On peut voir, dans cette requête, que les paramètres ne sont pas liés aux données accessibles au script PHP, mais plutôt à une faille de sécurité du script de l'annuaire.

Si ce script est fourni par un même éditeur de logiciel à plusieurs compagnies, alors l'utilisation de cette faille sera répétée d'un système à un autre et les requêtes ayant le paramètre path=../etc/passwd%00 seront répétées sur tous les sites victimes.

Notre proposition [2,4] pour détecter les anomalies communes à plusieurs sites repose sur un seul paramètre : n, le nombre d'alarmes désirées. Nous considérons en effet que notre approche sera utilisée dans un environnement dynamique. L'utilisateur doit pouvoir contrôler le nombre d'alarmes en temps réel afin de l'ajuster en fonction du nombre de faux positifs. Si ce nombre est trop élevé, cela signifie que le système est trop sensible.

Ensuite, en fonction de l'analyse des usages sur les différents sites partenaires, notre algorithme détectera n anomalies communes. Ces anomalies seront alors étiquetées comme étant des attaques.

COD (Common Outlier Detection) est le framework (illustré par la figure 1) et l'algorithme que nous avons proposés pour réaliser cette tâche. Un comportement sera considéré comme outlier (anomalie) si il est difficile de le placer dans un groupe de comportements. Ainsi, les comportements isolés et les petits groupes de comportements seront considérés comme des anomalies. Nous reviendrons plus loin dans ce document sur cette notion de « petits » groupes et de leur détection. Notre algorithme général peut-être résumé comme suit :

1. Pour chaque période de temps, les usages sont considérés comme des objets à segmenter.

2. La segmentation est effectuée sur chaque site, en commençant par une distance de 5%, puis en augmentant progressivement cette valeur sur chaque site.

3. A chaque fois que la valeur de distance utilisée dans la segmentation augmente, les anomalies sont détectées sur chaque site et elles sont comparées entre les deux sites.

4. Tant que le nombre d'anomalies communes (alarmes) est supérieur au nombre désiré par l'utilisateur, la valeur de distance est augmentée et l'algorithme reprend à l'étape 3.

Dans la figure 1, la première étape correspond à un clustering (segmentation) avec une similitude de 5%, les comportements sont difficiles à regrouper et on trouve beaucoup d'outliers (anomalies). Par exemple, les outliers A, B, C et D sont communs aux deux sites. A l'étape n, on trouve un seul outlier commun (A). Si l'utilisateur avait demandé une seule alarme au maximum, alors l'algorithme peut cesser et le résultat est obtenu (une alarme correspondant au comportement décrit par le cluster A).

Notre algorithme de segmentation utilise comme mesure de similitude la plus longue sous-séquence commune entre les chaines de caractères qui représentent les paramètres.

Figure 1: Principe général de l'approche COD

La principale difficulté posée par cette approche réside dans la détection des anomalies sur un ensemble de comportements sans faire intervenir l'utilisateur. Pour cela, nous avons proposé [1,5] de considérer la distribution des clusters en fonction de leur taille, après les avoir classés par taille croissante. Cette distribution sera alors découpée en deux sous-ensembles correspondants aux anomalies (« petits » clusters) et aux clusters normaux, grâce aux ondelettes de Haar. Nous calculons en effet la décomposition de cette distribution et nous gardons les deux coefficients les plus significatifs. Les deux plateaux obtenus permettent alors de distinguer les petits clusters sans faire intervenir de paramètre utilisateur et de façon auto-adaptative. Ces deux aspects sont très importants dans notre contexte car la détection d'intrusions doit se faire sur des flots de données d'usages et le temps consacré à la vérification des résultats et au choix des paramètres doit être optimisé. Nos travaux, décrits en [1] et [5], montrent que cet objectif est atteint en comparaison des méthodes existantes de détection d'anomalies.

5.2 Comment partager les anomalies en confiance ?

Dans le cadre de notre proposition, nous nous sommes plus particulièrement intéressés aux systèmes de type détection d'anomalies. Leur principe général est le suivant : une comparaison est effectuée entre une nouvelle requête et les signatures d'attaques représentées sous la forme d'expressions régulières. Par exemple, une attaque qui cherche à récupérer le fichier des mots de passes d'une machine (e.g. abc/../de/../../../fg/../etc/passwd) pourra être détectée via l'expression régulière suivante : (/[\^\ ./]*/..)*/etc/passwd. Traditionnellement ces signatures sont obtenues à partir d'algorithmes d'apprentissage ou bien via des sites spécialisés (e.g. OSVDB, arachNIDS). Même si ces systèmes sont largement utilisés aujourd'hui, le problème essentiel est qu'ils ne savent pas gérer des attaques qui n'appartiennent pas à la base de signatures. Ainsi, lorsqu'une requête n'est pas reconnue par l'IDS, une alarme est déclenchée afin de requérir une expertise extérieure.

Récemment de nouvelles approches de détection, appelées Collaborative Intrusion Detection Systems (CIDS), ont été proposées. En comparaison avec les IDS isolés, ces CIDS offrent la possibilité d'améliorer considérablement les temps de réactions et l'efficacité des détections en partageant, entre les IDS répartis sur une ou plusieurs organisations, les informations sur les attaques. Le principe général de ces approches est d'échanger via des réseaux Pair à Pair des informations survenues sur les différents IDS. Cependant traditionnellement les informations échangées se limitent aux adresses IP sources d'attaques et considèrent que les données peuvent librement être échangées parmi les pairs. Cette dernière contrainte est malheureusement très forte dans la mesure où de plus en plus les entreprises, pour des raisons de confidentialités, ne souhaitent pas dire qu'elles ont été attaquées et donc ne veulent pas donner d'information sur les signatures utilisées. Nous avons proposé une nouvelle approche de détection collaborative sécurisée [3], appelée SrexM (Secure Regular Expression Mapping), qui garantit que les données privées ne seront pas divulguées. Via notre approche, les différentes expressions régulières contenues dans les différents sites collaboratifs peuvent être utilisées sans qu'aucune information ne soit divulguée à l'extérieur. Les sites collaboratifs ont toute liberté pour travailler avec des signatures d'attaques ou de non attaques. Ainsi, lorsqu'une nouvelle requête intervient, la réponse obtenue sera simplement qu'il s'agit d'une attaque, d'une non attaque ou qu'il n'est pas possible de répondre, i.e. les bases de données n'ont pas d'information pour permettre de décider. Pour réaliser cela, SrexM repose sur une architecture composées de sites semi honnêtes ils suivent le protocole correctement mais sont libres d'utiliser l'information qu'ils ont collectée pendant l'exécution du protocole. Ces sites indépendants collectent, stockent et évaluent l'information de manière sécurisée. Les différentes fonctions de ces sites sont les suivantes :

• Le site de contrôle (Control Site) CTRL est utilisé pour ordonnancer les différentes opérations de comparaisons de l'expression régulière. Pour cela, il interagit avec deux sites non collaboratifs NC₁ et NC₂.

• Les sites Non Collaboratifs (Non Colluding Sites) NC_1 et NC_2. Ces sites symétriques collectent les données bruitées de toutes les bases ainsi que la requête bruitée à tester. Sous le contrôle de CTRL, ils interagissent avec $PS$ et réalisent une série d'opérations de manière sécurisée (en utilisant des opérateurs booléens et notamment des XOR pour bruiter les données) sans pouvoir inférer ni des résultats intermédiaires ni du résultat final qui est retourné au site S.

• Le site de calcul (Processing Site) PS est utilisé à la fois par NC_1 et NC_2 pour calculer de manière sécurisée les différentes fonctions et opérations. De manière similaire aux sites NC_1 et NC_2, PS ne peut pas déduire les résultats intermédiaires ou finaux des données qu'il traite.

Le principe général des échanges d'information est de répartir les différentes données, après que celles-ci aient été bruitées sur les sites NC_1 et NC_2. Via cette approche, les deux sites ne disposent jamais des données complètes et ne savent pas si ce qu'elles contiennent est du bruit ou les vrais données. Si les deux sites se mettaient à collaborer ensemble, étant donné que l'opération est bruitée soit par PS soit par CTRL, ils ne peuvent jamais connaître les données manipulées.

Via notre approche, il est également possible de déduire le type d’attaque qui a eu lieu si celui-ci est précisé dans les bases de données. Les travaux que nous menons actuellement concernent d’une part l’étude de la suppression du site semi honnête CTRL en répartissant les opérations à réaliser pour évaluer l’automate entre les différents autres sites. D’autre part, nous étudions l’optimisation de la gestion de l’automate (e.g. prise en compte de nouveaux opérateurs de conditions).

5.3 Quelques résultats

Les attaques trouvées dans la suite de ce texte ont toutes échoué, mais leur détection montre le bien-fondé de notre approche.

• Injection de code : un type récent d'attaque consiste à injecter du code PHP dans des scripts en donnant une URL en paramètre. Quand le code à faire exécuter par le script victime est trop long (taille maximum de paramètre dépassée) cette technique permet de contourner la limite et de passer le code tout de même. Voilà un échantillon des URL ainsi détectées :

  • http://myweddingphotos.by.ru/images?h

  • http://levispotparty.eclub.lv/images?

  • http://0xg3458.hub.io/pb.php?

  Selon les réglages PHP sur le site victime, le code injecté peut permettre la modification du site. Ces URL sont données en paramètres de manière automatique et massive à des scripts via des batch d'instructions (statistiquement, l'attaquant espère trouver un site vulnérable).

• Mots de passe : un autre genre (naïf) d'attaque consiste à tenter de récupérer le fichier des mots de passe d'un système, via son site Web. Les tentatives sont alors caractérisées par des paramètres du type ../etc/passwd avec un nombre variable de « ../ » en début de paramètre. Cette tentative est probablement la plus courante. Elle n'est généralement pas dangereuse (car bien connue) mais doit être détectée pour montrer l'efficacité d'un outil de détection d'intrusions.

• Les œufs de pâques : il ne s'agit pas vraiment d'une attaque, mais les caractéristiques sont strictement les mêmes. Sur la plupart des serveurs, si on ajoute le code suivant :

  ?=PHPE9568F36-D428-11d2-A769-00AA001ACF42

  à la fin de n'importe quelle page PHP, un affichage se produit avec des images des développeurs. De plus, le 1er avril, une image remplacera le logo PHP sur la page phpinfo(). Ce code est détecté comme une anomalie commune car il ne concerne pas les données gérées par le site, mais bien une particularité du code utilisé par plusieurs sites.

Si la capacité de détection était la première motivation de ce projet, le taux de faux positifs était la seconde. Nous avons donc également évalué les taux de faux positifs issus de COD. Les résultats sont bien meilleurs que ceux obtenus par les méthodes de détection d'anomalies traditionnelles. Cela est principalement dû au fait que l'existence d'une anomalie « de référence » (i.e., similaire sur un autre site) permet de filtrer la majorité des fausses alarmes. Ces taux sont de l'ordre de 1% de fausses alarmes au maximum.

6 Publications issues de ce projet

[1] Alice Marascu and Florent Masseglia. “A Multi-Resolution Approach for Atypical Behaviour Mining”. In 13th Pacific-Asia Conference on Knowledge Discovery and Data Mining (PAKDD’09 ). To appear, April 2009.

[2] G. Singh, F. Masseglia, C. Fiot, A. Marascu and P. Poncelet. “Data Mining for Intrusion Detection: from Outliers to True Intrusions.” In 13th Pacific-Asia Conference on Knowledge Discovery and Data Mining (PAKDD'09). To appear, April 2009.

[3] Nischal Verma, François Trousset, Pascal Poncelet, Florent Masseglia: « Détection d'intrusions dans un environnement collaboratif sécurisé ». In Extraction et gestion des connaissances (EGC 2009), Strasbourg, January 2009. pp 301-312.

[4] Goverdhan Singh, Florent Masseglia, Celine Fiot, Alice Marascu, Pascal Poncelet: “Collaborative Outlier Mining for Intrusion Detection”. In Extraction et gestion des connaissances (EGC 2009), Strasbourg, January 2009. pp 313-324.

[5] Alice Marascu, Florent Masseglia: « Détection d'enregistrements atypiques dans un flot de données: une approche multi-résolution ». In Extraction et gestion des connaissances (EGC 2009), Strasbourg, January 2009. pp 455-456.

7 Travaux en cours de soumission suite à ce projet

[6] G. Singh, F. Masseglia, C. Fiot, A. Marascu and P. Poncelet. “Mining Common Outliers for Intrusion Detection”. Invité dans l'ouvrage collectif "Advances in Knowledge Discovery and Management". Springer. Parution prévue en 2009. Collection "Studies in Computational Intelligence".

[7] Nischal Verma, François Trousset, Pascal Poncelet, Florent Masseglia: "Intrusion Detections in Collaborative Organizations by Preserving Privacy". Invité dans l'ouvrage collectif "Advances in Knowledge Discovery and Management". Springer. Parution prévue en 2009. Collection "Studies in Computational Intelligence".

Nous rédigeons actuellement un article regroupant les travaux décrits en section 5. Cet article sera soumis dans une revue internationale en 2009.

8 Références annexes

[8] Gaurav Panthari. « Extracting Sequential Patterns at Optimum Time Granularities ». Internship Report. 2008.

[9] Goverdhan Singh. « Common Outlier Detection in a Collaborative Environment ». Internship Report. 2008.