Evaluation de systèmes de détection d’intrusions pour les applications Web

Vulnérabilités et attaques web

      Au même titre qu’une application classique ou qu’un système d’exploitation, les applications Web peuvent présenter des failles de sécurité. Cela est d’autant plus grave que ces applications manipulent parfois des données confidentielles (mots de passe, numéros de cartes bancaires) et qu’elles sont généralement déployées sur Internet et donc exposées au public. Même sur un serveur Web sécurisé s’exécutant sur un système d’exploitation réputé sûr (Apache sur OpenBSD, par exemple), des failles de sécurité peuvent subsister, car elles sont la plupart du temps dues à des fautes de programmation de l’application elle-même, et non du serveur. Comme nous l’avons précisé dans l’introduction, la complexité croissante des technologies utilisées pour le développement de ces applications, ainsi que le manque de compétence en sécurité des multiples développeurs de ce genre d’application peut en grande partie expliquer les vulnérabilités récurrentes qu’elles présentent. Définissons à présent plus précisément les termes de vulnérabilité, attaque et intrusion que nous utiliserons tout au long de ce mémoire. Ces définitions sont extraites du projet MAFTIA [MAFTIA ET AL. 03].
– Une vulnérabilité est une faute accidentelle ou intentionnelle (avec ou sans volonté de nuire), dans la spécification, la conception ou la configuration du système, ou dans la façon selon laquelle il est utilisé. La vulnérabilité peut être exploitée pour créer une intrusion.
– Une attaque est une faute d’interaction malveillante visant à violer une ou plusieurs propriétés de sécurité. C’est une faute externe créée avec l’intention de nuire. Une attaque peut être ou non réalisée par des outils automatiques.
– Une intrusion est une faute malveillante interne, mais d’origine externe, résultant d’une attaque qui a réussi à exploiter une vulnérabilité.
Il existe une grande variété de vulnérabilités visant les applications Web. Toutefois certaines sont plus connues et plus dangereuses que d’autres. Plusieurs bases de données répertoriant ces vulnérabilités avec des statistiques indiquant leur importance relative existent. Nous citons par exemple les bases de données de vulnérabilités telles que CVE 1 (Common Vulnerabilities and Exposures), NVD 2 (National Vulnerability Database) ou VUPEN 3 (Vulnerability Penetration testing). Ces bases de données répertorient tous types de vulnérabilités, incluant celles ciblant les serveurs et applications Web. La multiplication des vulnérabilités et des attaques sur des sites web sur Internet ont poussé de nombreuses organisations à poser un regard critique sur la qualité de la sécurité de leurs applications web. Ainsi, plusieurs communautés ont vu le jour, dans le but d’améliorer la sécurisation des applications web. Les travaux dans ce contexte se sont traduits aussi par la proposition de taxonomies et de classifications pour les vulnérabilités et les attaques web les plus répandues. Parmi ces communautés, nous citons OWASP 4 (Open Web Application Security Project) et WASC5 (Web Application Security Consortium). Les membres du “Web Application Security Consortium” ont créé ce projet pour développer et promouvoir une terminologie standard décrivant les problèmes de sécurité des applications Web et permettant aux développeurs d’applications, experts en sécurité, développeurs de logiciels et les consultants en sécurité, d’utiliser un langage commun pour interagir entre eux. Une première version pour la classification des vulnérabilités composée de six classes a été proposée dans le document “Web
1. http://www.cve.mitre.org
2. http://web.nvd.nist.gov
3. http://www.vupen.com
4. https://www.owasp.org
5. http://www.webappsec.org/
8 Contexte des travaux
Application Security Consortium : Threat Classification” :
– Authentification : il s’agit de vulnérabilités qui concernent les fonctions du site Web permettant d’identifier un utilisateur, un service ou une application.
– Autorisation : cette classe regroupe les vulnérabilités liées aux fonctions destinées à vérifier les droits attachés à un utilisateur, un service ou une application.
– Attaques côté client (”Client-side Attacks”) : il s’agit de vulnérabilités permettant aux attaquants de cibler directement les utilisateurs du site Web en leur délivrant par exemple des contenus illicites tout en faisant croire qu’il s’agit d’informations provenant du site original.
– Exécution de commandes (”Command Execution”) : cette classe regroupe les vulnérabilités permettant l’exécution à distance de commandes sur le site Web.
– Divulgation d’information sensible (”Information Disclosure”) :  cette classe inclut les vulnérabilités dont l’exploitation permet l’obtention d’informations sur le système (système d’exploitation, version, etc.).
– Erreurs logiques et bug logiciel (”Logical Attacks”) : les vulnérabilités appartenant à cette classe peuvent conduire à des attaques permettant de détourner la logique d’implémentation de l’application pour réaliser des actions illicites. Cette classification mélange parfois les faiblesses et les attaques permettant de les exploiter. Une nouvelle version a été développée par la suite pour pallier à ce problème en distinguant ces deux dimensions et en fournissant une liste plus riche des menaces (WASC WSTC v2) . D’un autre côté, l’Open Web Application Security Project (OWASP) a défini dans l’un de ses projets nommé “TOP 10” les dix classes de vulnérabilités Web les plus critiques. L’objectif principal du Top 10 de l’OWASP est d’informer les développeurs, concepteurs, architectes, managers, et les entreprises au sujet des conséquences des faiblesses les plus importantes inhérentes à la sécurité des applications Web. Le Top 10 fournit des techniques de base pour se protéger contre ces vulnérabilités. La dernière version la plus récente date de 2010. Les vulnérabilités listées sont les suivantes, classées par ordre d’importance :
1. Failles d’injection
2. Cross-Site Scripting (XSS)
3. Violation de gestion d’authentification et de session
4. Référence directe non sécurisée à un objet
5. Falsification de requêtes inter-sites (CSRF)
6. Mauvaise configuration de sécurité
7. Stockage cryptographique non sécurisé
8. Manque de restriction d’accès d’URL
6.http://projects.webappsec.org/w/page/13246973/ThreatClassific tionPreviousVersions
7. http://projects.webappsec.org/Threat-Classification
9. Protection insuffisante de la couche transport
10. Redirections et renvois non validés

Mauvaise configuration de sécurité

     La mauvaise configuration de sécurité peut se manifester à différents niveaux, incluant le système d’exploitation, le serveur Web, le framework applicatif, l’application elle-même. Les développeurs et les administrateurs réseau doivent s’assurer que toutes les couches sont configurées correctement. En effet, l’attaquant peut accéder facilement à des comptes par défaut, pages non utilisées, vulnérabilités non corrigées, fichiers et répertoires mal protégés, etc., afin d’obtenir des accès non autorisés, des informations confidentielles, voire même, de pouvoir modifier des données ou prendre le contrôle de la machine.
Exemple 1 : La console de gestion applicative d’une application Web est automatiquement installée et non désactivée. Les comptes par défaut sont inchangés. L’attaquant découvre la console, utilise le compte par défaut, et prend le contrôle.
Exemple 2 : L’affichage du contenu des répertoires d’un serveur Web est possible, suite à une mauvaise configuration du serveur. L’attaquant le découvre et télécharge les classes java compilées, qu’il décompile pour obtenir le code source qu’il peut ensuite analyser pour y chercher des vulnérabilités.

Élimination de vulnérabilités : vérification et test

     L’élimination des fautes vise à identifier les vulnérabilités résiduelles introduites lors de développement de l’application et à les corriger. Elle s’appuie sur différentes techniques de vérification complémentaires qui peuvent être utilisées avec ou sans l’activation de l’application. La vérification sans activation réelle correspond à la vérification statique, qui peut concerner les différentes phases du développement (spécification, conception, codage). Dans l’autre cas, il s’agit de vérification dynamique s’appuyant généralement sur des techniques de test, en particulier des tests de pénétration. Il est nécessaire d’appliquer les deux techniques de vérification aussi souvent que nécessaire, celles-ci étant complémentaires. De plus, en raison de la complexité croissante des applications Web, le développement d’outils d’aide à la vérification devient indispensable. Plusieurs travaux récents ont été effectués sur des techniques d’analyse statique de code pour l’identification de vulnérabilités dans des applications Web (ASP, PHP, Java, …). On peut citer par exemple ([WASSERMANN ET SU 07],[LAM ET AL. 08],[HUANG ET AL. 04],[LIVSHITS ET LAM 05], [MINAMIDE 05],[JOVANOVIC ET AL. 06], [JOVANOVIC ET AL. 10],[XIE ET AIKEN 06]). L’avantage d’une telle méthode est qu’elle permet d’éliminer les fautes dans le logiciel avant que celui-ci ne soit déployé. Cependant cette méthode n’est pas adaptée aux cas où le code n’est pas disponible. Concernant la vérification dynamique, outre des tests de pénétration classiques qui s’appuient généralement sur l’expertise et le savoir faire des évaluateurs en charge de ces tests, plusieurs travaux ont été menés sur le développement de techniques et d’outils permettant de faciliter la recherche de vulnérabilités en adoptant une approche boîte noire (c’est-à-dire sans avoir accès au code source). Les outils correspondants sont en général nommés scanners de vulnérabilités Web [STEFAN ET AL. 06], ou outils de détection de vulnérabilités. L’effort a porté principalement sur l’identification des principales classes de vulnérabilités ciblant les applications Web (injections SQL, XSS, injection de commandes, etc.) que nous avons décrites dans la section 1.2 [MARTIN ET LAM 08],[KOSUGA ET AL. 07],[HALFOND 06],[KIEZUN ET AL. 09].

Analyse critique des scanners de vulnérabilités web

    Les deux approches que nous venons de présenter dans la section 2.1.1 présentent un certain nombre de limites. Nous en présentons une synthèse dans les paragraphes suivants. L’efficacité de l’approche par reconnaissance de messages d’erreurs est liée à la complétude de la base de connaissance regroupant les messages d’erreurs susceptibles de résulter de l’exécution des requêtes soumises à l’application Web. Généralement, comme c’est dans le cas de W3af, on considère principalement les messages d’erreurs issus de la base de données. Cependant, les messages d’erreurs qui sont inclus dans des pages HTML de réponse ne proviennent pas forcément du serveur de bases de données. Le message d’erreur peut également être généré par l’application qui peut aussi reformuler le message d’erreur issu du serveur, par exemple pour le rendre compréhensible par le client. Par ailleurs, même si le message est généré par le serveur de base de données, la réception de ce message n’est pas suffisante pour affirmer que l’injection SQL est possible. En effet, ce message signifie que, pour cette requête particulière, les entrées n’ont pas été assainies, mais ne permet pas de conclure par rapport à d’autres requêtes SQL, en particulier celles qui seraient susceptibles de correspondre à des attaques réussies. En ce qui concerne l’approche par similarité, elle se base sur l’hypothèse que le contenu d’une page de rejet est généralement différent du contenu d’une page d’exécution. Pour que cette comparaison puisse cependant être efficace, il est important d’assurer une large couverture des différents types de pages de rejet qui pourraient être générés par l’application. Ceci peut être réalisé en générant un grand nombre de requêtes visant à activer le plus grand nombre possible de pages de rejet variées. Cependant, les implémentations existantes de cette approche, en particulier dans Skipfish, génèrent trop peu de requêtes. Skipfish utilise seulement 3 requêtes. Si les réponses correspondent à différentes pages de rejet, il conclut à tort que la vulnérabilité est présente conduisant ainsi à un faux positif. Par ailleurs, pour l’approche par similarité, comme dans tout problème de classification, le choix de la distance est très important. Celle utilisée dans Skipfish ne prend pas en compte les ordres des mots dans un texte. Cependant, cet ordre définit généralement la sémantique de la page. Il est donc important d’en tenir compte comme par exemple dans [HUANG ET AL. 03]. Enfin, il est à noter qu’aucun des outils que nous avons analysés dans la section 2.1.1 n’a été conçu pour générer automatiquement des requêtes d’attaque qui mènent à l’exploitation réussie de la vulnérabilité identifiée. Cependant, une telle possibilité serait utile pour déterminer si la vulnérabilité suspectée peut être effectivement exploitée et réduire ainsi le taux de faux positifs. Outre les analyses que nous venons de faire en considérant principalement les algorithmes implémentés dans Skipfish, W3af et Wapiti, d’autres études basées sur des analyses expérimentales ont aussi fait état de certaines limitations des scanners web, incluant des outils commerciaux. Nous détaillons ces études dans la sous section 2.1.3.2. Ces analyses montrent clairement le besoin de développer de nouvelles approches permettant d’améliorer l’efficacité des outils de détection de vulnérabilités et les capacités d’automatisation des campagnes d’évaluation. Les travaux présentés dans le cadre de ce manuscrit s’inscrivent dans cette optique.

Aperçu global de l’approche

    L’approche proposée [AKROUT ET DESSIATNIKOFF 10] s’appuie sur certains concepts hérités des outils existants et inclut des extensions significatives. Elle est basée sur la classification automatique des réponses retournées par les serveurs Web en utilisant les techniques de regroupement de données (ou clustering) et permet d’identifier les requêtes qui sont capables d’exploiter avec succès des vulnérabilités présentes. La génération automatique des requêtes permettant l’exploitation réussie des vulnérabilités est particulièrement utile pour faciliter la validation des applications Web et l’élaboration de tests de pénétration. Notre approche comporte deux étapes : i) la recherche de points d’injection dans les pages du site et ii) la détection de vulnérabilités dans ces points d’injection. Nous définissons un point d’injection par une entrée d’une page dans laquelle il est possible d’injecter du code : un paramètre d’une URL ou un champ d’un formulaire. Notre algorithme de détection de vulnérabilités vise à réduire le nombre de faux positifs en fournissant les requêtes qui ont réellement permis d’exploiter chaque vulnérabilité. Cet avantage est double puisque l’exploitation effective des vulnérabilités nous permet également de découvrir de nouvelles pages de l’application Web que nous ne pouvions atteindre auparavant. Ces nouvelles pages peuvent contenir de nouveaux points d’injection et éventuellement de nouvelles vulnérabilités. La figure 3.1 présente une vue de haut niveau de l’approche proposée. Elle commence par l’analyse de l’URL initiale (qui correspond, la plupart du temps, à la page principale de l’application). A partir de cette URL, l’exploration identifie tous les points d’injection potentiellement vulnérables. Cette première étape se termine lorsque tous les points d’injection accessibles ont été atteints. La deuxième étape correspond à l’exécution de notre algorithme de classification, basé sur des techniques de clustering (que nous détaillons dans la section 3.2) sur chaque point d’injection. Cet algorithme permet l’identification et l’exploitation effective de vulnérabilités présentes. Il permet ainsi de découvrir de nouvelles pages qui peuvent contenir de nouveaux points d’injection qui n’étaient pas accessibles dans la première étape. Par conséquent, un nouveau domaine de l’application devient accessible. Par la suite, de façon itérative, la première étape de l’approche est ré-exécutée sur ce nouveau domaine, etc. Notre algorithme ([AKROUT ET AL. 11], [DESSIATNIKOFF ET AL. 10]) a été implémenté dans un outil développé en utilisant le langage Python, langage qui facilite grandement la gestion des concepts HTTP (cookies, paramètres, etc.). Cet outil utilise également le logiciel d’analyse statistique R1. Ce logiciel intègre un ensemble de programmes de clustering que nous allons détailler par la suite. Ils ont été utilisés pour développer notre algorithme de classification. Cet outil est nommé Wasapy, qui signifie Web Application Security Assessment in Python.

Table des matières

Introduction Générale
1 Contexte des travaux
1.1 Technologies Web 
1.2 Vulnérabilités et attaques web 
1.2.1 Failles d’injection
1.2.2 Cross-Site Scripting (XSS)
1.2.3 Violation de gestion d’authentification et de Session
1.2.4 Référence directe non sécurisée à un objet
1.2.5 Falsification de requête inter-site (CSRF)
1.2.6 Mauvaise configuration de sécurité
1.2.7 Stockage cryptographique non sécurisé
1.2.8 Manque de restriction d’accès URL
1.2.9 Protection insuffisante de la couche de transport
1.2.10 Redirections et renvois non validés
1.3 Contre mesures et moyens de protection 
1.3.1 Prévention des vulnérabilités
1.3.2 Élimination de vulnérabilités : vérification et test
1.3.3 Prévention, détection et tolérance aux intrusions
1.3.3.1 Pare-feu
1.3.3.2 Détection d’intrusions
1.3.3.3 Tolérance aux intrusions
1.3.4 Évaluation des techniques de protection
1.3.4.1 Méthodologie
1.3.4.2 Métriques d’efficacité des IDS
1.4 Conclusion 
2 État de l’art 
2.1 Outils de détection de vulnérabilités web : Scanner web
2.1.1 Principe des outils de détection de vulnérabilités
2.1.1.1 Approche par reconnaissance de messages d’erreurs
2.1.1.2 Approche par étude de similarité des réponses
2.1.2 Analyse critique des scanners de vulnérabilités web
2.1.3 Évaluation expérimentale
2.1.3.1 Injection de vulnérabilités
2.1.3.2 Études expérimentales : Exemples
2.2 Détection d’intrusions pour des applications Web 
2.2.1 Les approches par signature
2.2.2 Les approches comportementales
2.2.2.1 Approche boîte noire
2.2.2.2 Approche boîte grise
2.2.2.3 Approche boîte blanche
2.2.3 Approche hybride
2.2.4 Analyse critique
2.3 Évaluation de systèmes de détection d’intrusions 
2.4 Conclusion
3 Détection de vulnérabilités par classification automatique des pages html 
3.1 Aperçu global de l’approche 
3.2 Algorithme de classification 
3.2.1 Génération des trois ensembles de requêtes
3.2.2 La distance utilisée
3.2.3 Regroupement des pages en grappes et choix du seuil
3.2.4 Exemple
3.3 Génération des requêtes : utilisation des grammaires
3.3.1 Requêtes syntaxiquement valides : Riv
3.3.2 Requêtes aléatoires : Ra
3.3.3 Requêtes syntaxiquement invalides : Rii
3.4 Extension à d’autres classes de vulnérabilités 
3.4.1 Xpath
3.4.2 Os Commanding
3.4.3 File Include
3.5 Expérimentations
3.5.1 Notation
3.5.2 Expériences avec les applications modifiées
3.5.2.1 Présentation des applications modifiées
3.5.2.2 Résultats
3.5.3 Expériences avec les applications non modifiées
3.5.3.1 Présentation des applications non modifiées
3.5.3.2 Résultats
3.5.4 Synthèse
3.6 Conclusion 
4 Dépendance entre vulnérabilités et génération de scénarios d’attaque 
4.1 Graphe d’attaque 
4.2 Présentation de l’approche 
4.2.1 Définitions
4.2.2 Crawling
4.2.3 Identification des vulnérabilités
4.3 Algorithme de génération de graphe de navigation
4.4 Exemple
4.4.1 Construction automatique du graphe de navigation
4.5 Discussion sur la complexité 
4.5.1 Pire cas
4.5.2 Comptage des chemins
4.5.3 Complexité de crawler
4.5.4 Complexité de search_vulns
4.5.5 Complexité de main
4.5.6 Maîtrise de la taille du graphe – similarité des requêtes
4.5.7 Expérimentation
4.6 Conclusion 
5 Plateforme d’évaluation 
5.1 Architecture de la plateforme d’évaluation 
5.2 Présentation des différents composants de la plateforme
5.2.1 Génération de trafic normal
5.2.1.1 Interaction humaine et crawler web
5.2.1.2 Crawler générateur automatique du trafic normal
5.2.2 Trafic d’attaque : Scénarios d’attaque, Ordonnanceur, Lanceur
5.2.2.1 Scénario d’attaque
5.2.2.2 Ordonnanceur
5.2.2.3 Le module d’exécution (lanceur)
5.2.3 Proxy enregistreur, et rejeu de traces WEB
5.2.4 Proxy : simulation de plusieurs sources
5.2.5 Application Cible et IDS
5.2.6 Traitement et Analyse des résultats
5.3 Intégration 
5.4 Expérimentations 
5.4.1 Expérimentation avec trafic sain uniquement
5.4.1.1 IDS basé sur les invariants
5.4.1.2 IDS basé sur les contrats
5.4.2 Expérimentation avec trafic malveillant
5.4.2.1 Trafic généré par Wasapy
5.4.2.2 Attaques manuelles
5.4.3 Discussion
5.5 Conclusion
Conclusion Générale
Bibliographie

Télécharger le rapport complet