Détection d’attaques contre les données dans les
applications web
La détection d’intrusion
Un système de détection d’intrusion est un système destin repérer des attaques ou des violations de la politique de sécurité l’égard d’un système d’information. La détection d’intrusion est l’tape qui consiste surveiller les évènements arrivant sur un réseau ou sur une machine hôte et identifier une menace. En résultat, un IDS peut produire des notifications l’administrateur de sécurité, produire des rapports et parfois, tenter de parvenir l’attaque. De nombreuses approches ont t prsentes au fil des ans, et certaines d’entre elles sont encore aujourd’hui du domaine de la recherche. Il existe plusieurs manières pour caractériser un IDS ; nous identifions ci-dessous les grandes classes.
Les sources de donnes
Plusieurs sources de donnes peuvent être envisages pour surveiller un système informatique. Une source particulière doit être suffisamment riche en informations analyser pour que l’IDS ait un faible taux de faux ngatifs (les attaques non dtectes). Par ailleurs, les informations doivent être raisonnablement prcises de manière rduire le taux de faux positifs (les 6 fausses détections). Les paquets circulant sur un rseau forment une bonne source de donnes analyser pour la détection d’intrusion. L’entête et le payload d’un paquet sont ainsi parcourus en vue de trouver des comportements malveillants. Snort1 , IDS très rpandu, se base sur cette source pour analyser les intrusions sur un rseau. Une autre source peut être les donnes fournies par le système d’exploitation comme les appels systèmes [1, 2]. Les donnes applicatives, comme les variables d’un programme, peuvent galement être utilises pour mettre en oeuvre des IDS sur certains types d’applications, comme les applications web.
Les mthodes de détection
Les mthodes de détection d’intrusion sont divises en deux grandes coles : l’approche par scnarios et l’approche comportementale. Les IDS bass sur une approche par scnario utilisent la modlisation du comportement jug interdit de l’entit surveille. En effet, une intrusion peut être considre comme une suite d’vènements rvlatrice d’une attaque. Ainsi, ces IDS utilisent une base de signatures – ou scnarios – identifiant les attaques et vulnrabilits connues, et les comparent un ensemble de donnes surveiller (paquets rseaux, logs systèmes…). Cette approche est relativement similaire ce qui est employ dans la détection virale. L’inconvnient majeur de cette approche est qu’elle ncessite d’avoir une connaissance pralable quant la nature des intrusions possibles. Les IDS bass sur une approche par scnario ne seront pas en mesure de detecter de nouvelles intrusions, puisque les signatures caractristiques ne seront pas prsentes dans la base de donnes. L’efficacit de cette technique repose donc totalement sur la capacit entretenir une base de donnes des signatures jour. Par ailleurs, ces IDS dtectent en gnral de très nombreux faux positifs car l’criture de signatures rellement discriminantes est difficile. En contraste, les IDS fonds sur une approche comportementale modlisent le comportement normal d’une entit. La nature d’une intrusion est inconnue dans cette approche. Nanmoins, une intrusion provoquera un comportement diffrent du système, par rapport celui observ normalement. Ainsi, toute dviation par rapport au modèle de rfrence indique une possible intrusion. L’avantage de cette approche est qu’elle permet de detecter les nouvelles attaques sans intervention additionnelle sur l’IDS. L’enjeu de cette technique est de crer un modèle de rfrence suffisamment complet et prcis pour detecter les dviations et rduire le nombre de faux positifs. Nous verrons dans le deuxième chapitre certaines techniques employes ce sujet. En règles gnrales, il y a deux tapes dans la détection d’intrusion comportementale. La première consiste crer une base de donnes du comportement normal d’une entit, c’est dire, le modèle de rfrence. La deuxième tape consiste utiliser la base de donnes prcdemment construite pour surveiller le comportement du système.
Les autres caractristiques
Plusieurs autres caractristiques peuvent être employes pour classifier les IDS. Par exemple, plusieurs architectures sont possibles. Un IDS peut être centralis, c’est–dire que son excution est ralise sur une seule machine, ou bien distribu sur plusieurs machines. Nous pouvons galement caractriser le comportement d’un IDS après la détection d’une intrusion. En gnral, il fournit un rapport d’intrusion ou une alerte l’administrateur de la scurit. Des travaux ont toutefois t publis dans le cadre d’IDS dfensif (aussi nomm Intrusion Prevention System – IPS), qui vont adopter un comportement adquat sur le système en fonction de l’intrusion dtecte. Nous avons vu dans ce chapitre les diffrents types d’IDS et quelles sont leurs caractristiques. Dans le chapitre suivant, nous allons nous focaliser sur les solutions existantes au niveau applicatif, en faisant un tat de l’art des solutions de détection d’intrusion comportementales actuelles. 2.2 détection d’intrusion au niveau applicatif Nous allons voir dans ce chapitre quelques approches populaires de la détection d’intrusion comportementale au niveau applicatif. Nous avons choisi d’organiser cet tat de l’art selon trois visions diffrentes : une approche «boîte noire», «boîte grise» et «boîte blanche». Ces trois approches de la détection d’intrusion jouent sur des niveaux d’analyse diffrents, chacun d’eux tant bas sur le type d’informations disponibles pour construire le modèle de rfrence.
L’approche en boîte noire
Les approches de type boîte noire n’utilisent aucune information interne du programme, d’o`u le nom. Aujourd’hui, elles se basent pour la plupart sur l’analyse des enchaînements des appels systèmes des processus, donc sur des informations externes au programme. Historiquement, nous devons ces premiers travaux Forest et al. dans [1] et dvelopps dans [2]. L’exprience a en effet montr que de courtes squences d’appels système gnèrent une signature stable pour modliser le comportement normal d’un processus par rapport son environnement. Prcdemment ces travaux, des approches modlisant le comportement normal d’un utilisateur ont t proposes [3, 4]. Ces dernières modlisent des profils en analysant les logs du système. Il s’est avr que l’analyse des appels système est plus avantageuse en tout point de vue. En effet, le nombre de comportements diffrents d’un programme est born, contrairement celui d’un utilisateur qui est susceptible de gnrer un très grand nombre d’actions diffrentes. Dans les travaux de Forest et al., seuls les appels système et leur ordre temporel sont considrs, les arguments tant ignors. La phase d’apprentissage construit une base de donnes des squences normales. Les nouvelles excutions sont par la suite compares aux traces prsentes dans la base de donnes. Si certains appels système caractristiques pour une excution donne n’apparaissent pas dans la squence surveille, on considère qu’il s’agit d’une attaque. La principale interrogation lie cette dmarche concerne la longueur des squences d’appels système analyser. En effet, il s’agit de trouver un juste milieu entre la prcision, o`u des squences longues semblent plus avantageuses, et le stockage de ces dernières, auquel cas on recherche plutˆot avoir des squences courtes. Cette technique permet de detecter des attaques visant modifier le flot de contrˆole de l’application. Par exemple, un attaquant peut cibler une adresse de retour sur la pile et la modifier de manière excuter du code malveillant inject quelque part dans la mmoire. Cela aura pour effet de provoquer des appels système illgaux la plupart du temps. Cette approche a cependant des faiblesses. En effet, elle est sujette aux attaques par mimtisme, dans lesquelles un attaquant imite le comportement attendu de l’application surveille avec pour objectif d’agir sur le flot de contrˆole de l’application. Cela aura pour consquence de gnrer des appels système valides du point de vue de l’IDS et donc de ne pas detecter l’attaque. Cette approche est galement encline aux attaques contre les donnes. Ces dernières visent l’intgrit des donnes sans forcment modifier le flot de contrˆole de l’application surveille. Pour tenter de pallier ces attaques, diffrents travaux ont propos d’utiliser des informations additionnelles sur l’tat interne de l’application et de les ajouter au modèle bas sur les squences d’appels système. Ces approches sont appeles approches en boîte grise.
L’approche en boîte grise
Tout comme l’approche en boîte noire, l’approche en boîte grise est fonde sur les squences d’appels système. Cependant, elle extrait des informations additionnelles du processus, notamment en utilisant la mmoire. Comme nous l’avons voqu prcdemment, l’approche en boîte noire est vulnrable plusieurs types d’attaques. Les approches en boîte grise se veulent plus complètes de manière accroître la difficult d’exploitation de ces attaques. Nous allons voir ci-dessous un tat des lieux de cette approche. L’exprience a montr que la prsence d’une attaque se manifeste souvent dans les arguments des appels systèmes. Se basant sur ce constat, Kruegel et al. [5] proposent de prendre en compte les arguments des appels système pour amliorer la technique introduite par Forest et al. [1, 2]. Pour cela, les arguments des appels système sont analyss suivant plusieurs modèles et chacun de ces modèles est instanci pour chaque appel système. Parmi ces modèles, nous pouvons citer la distribution de la taille d’un argument, la distribution de ses caractères, sa structure grammaticale et la prsence de valeurs numres. Les auteurs dmontrent ainsi qu’il est possible de rduire considrablement la capacit d’un attaquant contourner le système de détection. Nanmoins, leur travail est fond sur deux hypothèses importantes. La première tant que si une attaque est mene, alors elle aura un impact sur les arguments des appels système. La deuxième hypothèse impose quant elle qu’un paramètre utilis pour mener une attaque diffère substantiellement des valeurs observables lors d’une excution normale de l’application. Si ces deux conditions ne sont pas vrifies, alors la capacit de détection de cette approche n’est videmment plus assure. Une approche complmentaire celle dcrite prcdemment a t tudie par Mutz et al. [6]. Au lieu d’avoir une instanciation des modèles pour chaque appel système, les auteurs proposent de considrer les diffrentes phases d’un programme. Par exemple, les arguments d’une phase d’initialisation sont fortement susceptibles d’être diffrents de ceux d’une phase de production. Cette diffrenciation du comportement du programme va être ralise en prenant en compte le contexte d’un appel système, c’est dire sa pile d’appel. Les auteurs dmontrent alors que la sensibilit ajoute grˆace au contexte d’un appel système offre une meilleure performance de détection. En particulier, certaines attaques contre les donnes ont pu être dtectes alors que l’approche se basant uniquement sur les arguments des appels système les avait ignors. Les auteurs ont dmontr galement que la sensibilit au contexte d’appel apporte une granularit plus fine et permet ainsi de rduire le nombre de faux positifs. Dans l’article [7], Gao et al. introduisent un nouveau modèle de détection, nomm graphe d’excution. L’objectif de ce travail est de se rapprocher le plus possible d’une analyse de type boîte blanche (que nous dcrirons dans la partie suivante) sans que cela requière une analyse statique des sources du programme. Par consquent, les auteurs proposent cette solution lorsqu’une approche boîte blanche n’est pas envisageable. Par exemple, lorsqu’on ne possède pas les codes sources du programme (l’analyse statique sur des fichiers binaires tant complexe) ou lorsque le programme est protg par obfuscation. Le modèle de rfrence cr se veut le plus exhaustif possible pour correspondre au mieux au graphe de flot de contrˆole de l’application. Toutefois, certaines branches du programme sont susceptibles de ne pas être connues si leurs excutions ne sont prsentes dans aucune observation. Ainsi, pour crer le graphe d’excution, la structure des appels de fonctions est extraite des observations. Enfin, les auteurs assurent deux proprits intressantes leur modèle. Premièrement, les squences d’appels système acceptes par le graphe d’excution sont un sous ensemble de celles acceptes par le graphe de flot de contrˆole du programme. Deuxièmement, le langage accept par le graphe d’excution est maximal par rapport aux donnes d’entrainement fournies. Nous avons vu dans ce chapitre que l’approche boîte grise amliore l’approche boîte noire, en lui associant des informations additionnelles sans toutefois utiliser les sources du programme. En effet, nous avons soit considr l’environnement d’excution, soit considr les observations de l’excution de l’application. Toutefois, des attaques sont toujours possibles comme les attaques contre les donnes. Nous allons voir dans le chapitre suivant comment utiliser les sources du programme pour amliorer la détection d’intrusion.
L’approche en boîte blanche
Dans une approche en boîte blanche, toutes les informations prsentes dans les sources du programme peuvent être utilises pour construire un modèle de détection d’intrusion au niveau applicatif. En effet, nous considrons ici le code du programme que nous allons analyser par analyse statique ou dynamique afin d’en driver un modèle appropri. Ainsi, comme nous allons le voir dans la suite, cette approche permet de detecter la fois des attaques contre le flot de contrˆole de l’application et des attaques contre les donnes. En particulier, des attaques contre les donnes peuvent avoir pour consquence de modifier le flot de contrˆole de l’application.
Attaques contre le flot de contrˆole
Wagner et al. [8] montrent comment une analyse statique du code source peut être utilise pour construire un modèle du comportement normal de l’application. Cette technique se focalise sur la détection d’attaques contre le flot de contrôle de l’application, comme nous avons pu le voir dans l’approche en boîte noire par exemple. Pour réaliser ce travail, les auteurs proposent de driver les spécifications du programme partir d’une analyse statique de son code source. Ainsi, le comportement de l’application est modlis par un système de transition d’tats. Durant la phase de détection, si une squence d’appels système est incompatible avec ce système de transition, on peut alors considrer qu’il s’agit d’une attaque. L’objectif de ce travail a t notamment d’automatiser la construction du modèle. Pour cela, les auteurs proposent diffrentes approches. La dernière retenue est fonde sur la gnration d’un automate pile, exprimant les squences valides d’appels système. Des optimisations ont galement t proposes pour affiner la détection, comme la prise en compte des arguments des appels système. Les rsultats obtenus convergent vers ceux observs dans l’approche en boîte grise. Cependant, cette technique ne permet pas de detecter des attaques contre les donnes qui ne modifient pas le flot de contrˆole de l’application.
Attaques contre les donnes
Contrairement aux approches en boîte noire et en boîte grise, l’approche en boîte blanche a les capacits d’agir de manière efficace envers les attaques contre les donnes. En particulier, Chen et al. dmontrent dans l’article [9] que ces attaques sont une vritable menace, bien qu’elles soient plus difficiles mettre en oeuvre. Elles reposent en effet sur la connaissance de la smantique du programme cibl, imposant l’attaquant une tude approfondie de ses vulnrabilits. Ces attaques ciblent en particulier les fichiers de configuration et les paramètres d’entre de l’application, ainsi que les donnes concernant les prises de dcision (par exemple une attaque contre la valeur d’un boolen pour accder une branche particulière d’une conditionnelle). Ainsi, des informations sur le flot de donnes du programme peuvent être intressantes pour detecter ce type d’attaques. Motivs par le travail de Chen et al. [9], Cavallaro et al. [10] proposent une approche qui allie la technique de taint tracking et la détection d’intrusion comportementale. Le principe du taint tracking est de marquer toutes les variables susceptibles d’être modifies par l’utilisateur extrieur comme contamines (« tainted » en anglais). Ainsi, si une variable contamine est utilise dans une expression qui initialise une seconde variable, cette dernière est aussi marque comme contamine. On obtient au final un ensemble complet de variables potentiellement influences par une intervention extrieure. Ainsi, la proprit de contamination concerne les donnes. L’approche propose se focalise donc en particulier sur les arguments des appels système. Par ailleurs, l’analyse est sensible au contexte, comme on a pu le croiser dans certaines techniques en boîte grise. Comme dans toute approche comportementale, la dmarche est divise en deux parties. Dans une première partie, le programme tudi va être instrument de manière marquer comme contamin certains des arguments des appels système. Les proprits des arguments contamins vont ensuite être modlises durant une phase d’apprentissage dans laquelle on va infrer les distributions de leurs tailles et de leurs structures. Pendant la phase de détection, un modèle de comportement de l’application va être cr de manière dynamique. Si ce modèle de comportement est diffrent de celui appris durant la phase prcdente, une alarme sera dclenche. L’implmentation de cette approche a montr qu’il tait avantageux de considrer l’ensemble des variables contamines plutˆot que la globalit des variables du programme car cela permet de rduire le nombre de faux positifs. Castro et al. [11] proposent une dmarche diffrente qui permet comme prcdemment de detecter des attaques contre les donnes. Cette technique consiste assurer l’intgrit du flot de donnes de l’application. Dans cet objectif, les auteurs proposent une approche en trois temps. Dans la première phase, une analyse statique du programme est ralise pour calculer un graphe du flot de donnes de l’application. Dans la deuxième phase, le programme est instrument de manière garantir que le flot de donnes l’excution est autoris par le graphe prcdemment calcul. Enfin, la dernière phase concerne la détection : le programme instrument est excut et une alerte est mise si l’intgrit du flot de donnes n’est plus assure. Cette technique a l’avantage de ne pas avoir de faux positifs. En effet, lors de la construction du modèle, l’analyse statique calcule une sur-approximation du comportement de l’application. Ainsi, on peut affirmer avec certitude que si une alarme est mise, il s’agit effectivement d’une attaque. Nous pouvons cependant observer des faux ngatifs. En effet, une attaque peut être ignore dˆu la sur-approximation du comportement de l’application. Nous avons vu travers ces quelques techniques comment le code source du programme pouvait être utilis pour avoir des modèles prcis permettant de detecter une vaste panoplie d’attaques. Dans la suite, nous nous focalisons en particulier sur une autre technique de l’approche boîte blanche, que nous utiliserons galement pour le stage de cette anne.
Remerciements |
