Soutenance mémoire
VULNÉRABILITÉS LOGICIELLES : GÉNÉRALITÉS
Cybersécurité et vulnérabilités
Le nombre croissant des systèmes informatiques interconnectés, et la dépendance croissante à leur égard, que ce soit de la part des particuliers, des entreprises ou des entités industrielles et gouvernementales, signifie qu’un nombre important de systèmes est à risque. La cybersécurité vise à protéger les systèmes informatiques contre le vol et l’endommagement de leur matériel, de leurs logiciels ou des informations qu’ils contiennent. Ce domaine est d’une grande importance pour tous les acteurs des technologies de l’information, du simple utilisateur à domicile aux grandes agences gouvernementales. ce domaine est très vaste et le devient de plus en plus. La cybersécurité couvre des domaines techniques tels que les opérations de sécurité, l’architecture de sécurité ou l’évaluation des risques, des domaines réglementaires tels que la gouvernance ou la conformité aux normes et des domaines liés aux ressources humaines tels que le développement de carrière ou l’éducation des utilisateurs. Nous nous concentrons sur le domaine de l’évaluation des risques et plus particulièrement sur les sous-domaines de l’analyse des vulnérabilités et de l’analyse du code source.
L’analyse de vulnérabilité est généralement effectuée à l’aide d’outils automatisés qui signalent les vulnérabilités déjà connues. Ces vulnérabilités connues sont publiées et documentées dans différentes bases de données en ligne. Parmi celles-ci, la plus célèbre est la liste des identificateurs communs de vulnérabilité CVE (Common Vulnerabilities and Exposures) [1], qui est gérée par l’organisation MITRE [2] avec le financement de la division nationale de la sécurité informatique du gouvernement américain.
Le base CVE attribue à chaque vulnérabilité rendue publique un identifiant unique qui peut être utilisé pour récupérer des informations sur celle-ci. La base CVE est le dictionnaire qui associe à tous ces identificateurs une brève description de la vulnérabilité et toute référence pertinente à celle-ci. Bien que le système CVE soit assez connu, il s’avère que la plupart des personnes qui le mentionnent se réfèrent en réalité à la base de données nationale des vulnérabilités NVD (National Vulnerability Database) [32]. Cette dernière est une base de données établie par le NIST (National Institute of standards and Technology) [33] et le gouvernement américain afin d’encourager le développement de logiciels sécurisés, la divulgation publique et la gestion des vulnérabilités. Le NVD enrichit chaque entrée du CVE avec des informations telles que la gravité (appelée CVSS) et le type (appelé CWE) d’une vulnérabilité. En outre, les données sont continuellement mises à jour par le personnel du NVD.
Parmi les informations trouvées dans le NVD, deux sont particulièrement intéressantes : le Common Vulnerability Scoring System (CVSS) et le Common Weakness Enumeration (CWE). Le système CVSS saisit les principales caractéristiques d’une vulnérabilité et produit une note numérique allant de 0 à 10 reflétant sa gravité. Cette note peut être traduite en une représentation qualitative, telle que faible [0 – 4[, moyenne [4,0 – 7[, élevée [7,0 – 9[ et critique [9,0 – 10,0] pour aider à hiérarchiser la vulnérabilité. La version actuelle du CVSS est la 3.0 qui a été publiée en juin 2015 [34]. Le CWE est un système de catégorisation des faiblesses et des vulnérabilités des logiciels. Il est piloté par un projet communautaire dont l’objectif est de comprendre les failles logicielles. Il est utilisé par le NVD pour catégoriser les vulnérabilités et est actuellement en version 3.1 [35].
L’analyse des vulnérabilités doit être effectuée en continu pour s’assurer que le système d’information est au moins immunisé contre les vulnérabilités connues. D’autre part, l’analyse des codes logiciels se fait soit dans une boîte blanche avec un accès au code source, soit dans une boîte noire avec un accès au code binaire des logiciels qui peut être utilisé pour découvrir des vulnérabilités généralement nouvelles (appelées « zero days » par la communauté de la sécurité). Le résultat de l’analyse est un ensemble d’alertes ou d’avertissements expliquant où se trouve la vulnérabilité. L’utilisation de la taxonomie CWE (Common Weakness Enumeration) [21] permet aux auditeurs de logiciels d’utiliser facilement différents outils ou techniques et de conserver le même vocabulaire pour décrire les mêmes choses.
Vulnérabilités logicielles
Les vulnérabilités informatiques peuvent être classées dans différentes classes, les plus importantes sont les vulnérabilités matérielles, logicielles ou de réseau. Il existe certes d’autres types de vulnérabilités telles que les vulnérabilités liées au personnel ou au site physique où sont stockées les machines. Dans ce manuscrit, nous nous intéressons aux vulnérabilités logicielles car elles sont responsables de la majorités des exploits. De plus, une vulnérabilité logicielle peut entraîner plusieurs autres vulnérabilités ce qui est appelé un effet cascade.
Exemples de Vulnérabilités
Pour avoir une idée précise sur les vulnérabilités logicielles, nous présentons quelques exemples de vulnérabilités accompagnées de leurs descriptions et d’exemples d’exploits possibles.
Débordement de tampon
Le débordement de tampon, aussi appelé dépassement de tampon (en anglais, buffer overflow) est une vulnérabilité qui se produit lorsque l’écriture dans un tampon dépasse la taille autorisée. En conséquence, des informations se retrouvant après le tampon sont écrasées. Cela peut entraîner un mauvais fonctionnement du programme, voire de tout le système, puisque les nouvelles données peuvent corrompre les données d’autres tampons ou processus. Le débordement de la mémoire tampon peut également être utilisé intentionnellement pour injecter un code malveillant afin de modifier l’exécution normale du programme et de prendre le contrôle du système. Le langage de programmation C est particulièrement affecté par cette vulnérabilité en raison de sa gestion dynamique de la mémoire. En effet, certaines applications critiques comme l’aéronautique interdisent l’utilisation de pointeurs ou d’allocations dynamiques de mémoire pour éviter ces problèmes. Par exemple, dans le programme C suivant :
int main(int argc, char **argv) {
char buffer[1024] ;
strcpy (buffer, argv[1]) ;
}
Le paramètre argv[1] peut contenir plus de 1024 caractères. La fonction strcpy copiera le contenu de argv[1] dans la variable buffer sans aucune vérification : elle copie le contenu de la chaîne de caractères jusqu’à ce qu’elle rencontre un caractère de fin de chaîne (caractère nul).
Cette vulnérabilité peut être exploitée de différentes manières. Lorsque la fonction strcpy est appelée dans une méthode, elle peut écraser l’adresse de retour au programme initial. Ceci permet de bloquer le processus ou de contrôler l’exécution. la pile d’exécution d’un programme lors de la copie d’une chaîne de caractères d’une taille inférieure à la taille du buffer (vulnérabilité non exploitée) et une autre pile d’exécution lorsque la taille de la chaîne est supérieure à celle du buffer (vulnérabilité exploitée). Un autre exploit possible serait de copier une chaîne longue qui finit par le chiffre « 1 » avant un booléen important. Il en résulte que la valeur « 1 » sera affectée à ce booléen ce qui pourrait représenter un réel danger selon l’importance du booléen.
Injection SQL
Toute application qui utilise une base de données SQL doit être protégée contre l’injection SQL (SQLi). Un attaquant peut obtenir des informations sensibles de la base de données en injectant des entrées élaborées non prévues par le système et pouvant en compromettre la sécurité. Si les entrées ne sont pas bien filtrées, elles peuvent être exécutées par l’interpréteur SQL et exposer le contenu de la base de données. Par exemple, si une application demande à l’utilisateur de saisir son nom pour se connecter et que l’attaquant entre le texte suivant : ’ OR ’1’ = ’1, alors l’application peut exécuter la commande SQL suivante :
SELECT * FROM users WHERE name = ” OR ’1’=’1’ ;
Ainsi, l’attaquant obtiendra un nom d’utilisateur valide puisque l’évaluation de l’énoncé ’1’=’1’ est toujours vraie. De la même manière, l’attaquant peut obtenir des informations confidentielles, modifier le contenu ou même supprimer les enregistrements de la base de données ayant un impact sur le service et/ou l’activité. Un autre exemple très simple d’une injection SQL serait d’introduire, dans le champ alloué au nom, une chaîne de caractères suivie de ’ ;– comme dans ce qui suit :
SELECT uid FROM Users WHERE name = ’Dupont’ ;–’ AND password = ’XXXX’ ;
Les caractères – marquent le début d’un commentaire en SQL. La requête est donc équivalente à :
SELECT uid FROM Users WHERE name = ’Dupont’ ;
L’attaquant peut alors se connecter sous l’utilisateur Dupont avec n’importe quel mot de passe. Ceci représente une injection SQL réussie.
Cross-Site Scripting
Le cross-site scripting (abrégé XSS) est une vulnérabilité associée aux applications web permettant d’injecter du code dans les pages web qui sont accessibles à d’autres utilisateurs. L’attaquant peut exploiter cette faille pour contourner les contrôles d’accès, pratiquer l’hameçonnage, l’usurpation d’identité ou mettre à jour les connexions. Cette vulnérabilité est très répandue et se produit partout où une application web utilise les données d’un utilisateur sans les valider. Un attaquant peut exploiter la faille XSS pour envoyer un script malveillant à un utilisateur sans méfiance. Le navigateur de l’utilisateur exécutera le script ce qui permettra à l’attaquant d’accéder à n’importe quelles informations sensibles enregistrées par le navigateur et utilisées avec ce site.
|
Table des matières
I Introduction
1 Introduction
1.1 Contexte
1.2 Défis de la thèse
1.3 Contributions de la thèse
1.4 Structure de la thèse
II Contexte de travail et état de l’art
2 Vulnérabilités logicielles : généralités
2.1 Cybersécurité et vulnérabilités
2.2 Vulnérabilités logicielles
2.3 Exemples de Vulnérabilités
2.3.1 Débordement de tampon
2.3.2 Injection SQL
2.3.3 Cross-Site Scripting
2.4 Causes de Vulnérabilités
2.5 Remédiation
2.6 Résumé et discussion
3 Identification de vulnérabilités
3.1 Méthodes d’analyse logicielle
3.1.1 Analyse statique
3.1.2 Analyse dynamique
3.1.3 Analyse hybride
3.2 Évaluation et comparaison d’outils
3.3 Combinaison d’outils
3.4 Résumé et discussion
4 Modèles de Prédiction de Vulnérabilités
4.1 Utilisation de techniques d’apprentissage automatique et d’exploration de données
4.2 Processus de construction de modèles de prédiction de vulnérabilités
4.3 Travaux sur les modèles de prédiction de la vulnérabilité
4.3.1 Analyse de dépendances
4.3.2 Métriques logicielles
4.3.3 Analyse de texte
4.3.4 Métriques liées au facteur humain
4.3.5 Combinaison d’approches
4.3.6 Autre modèles de prédiction
4.4 Résumé et discussion
5 Résumé de la partie 2
III Contributions
6 Conception d’un méta-scanner de vulnérabilités logicielles
6.1 Introduction
6.2 Approche générale
6.3 Outils d’analyse de vulnérabilités logicielles
6.4 Benchmark de vulnérabilités logicielles
6.4.1 Cas de test Juliet
6.4.2 Utilisation des cas de test Juliet
6.4.2.1 Vrais positifs et faux négatifs
6.4.2.2 Faux positifs et vrais négatifs
6.4.2.3 Rapports de défauts non liés au défaut ciblé
6.4.3 Localisation des failles : Choix de la granularité
6.5 Mise en correspondance d’identifiants CWE
6.5.1 Estimation des performances des outils d’analyse de vulnérabilités
6.6 Combinaison des outils
6.7 Validation du méta-outil proposé
6.7.1 CVMS vs. les outils d’analyse de vulnérabilités
6.7.2 CVMS vs les approches existantes
6.7.3 Discussion
6.7.4 Menaces à la validité
6.8 Résumé et discussion
7 Création d’un corpus de vulnérabilités logicielles
7.1 Corpus existants
7.2 Critères du corpus
7.3 Choix des données
7.4 Choix de la granularité
7.5 Corpus SecureQualitas
7.6 Discussion
7.7 Résumé
8 Modèles de prédiction du code vulnérable
8.1 Objectifs
8.2 Ensembles de données pour la construction de modèles de prédiction
8.2.1 Choix de la granularité
8.2.2 Métriques logicielles
8.2.3 Utilisation du corpus SecureQualitas
8.2.4 Construction des ensembles de données
8.3 Expérimentations
8.3.1 Prédiction du code vulnérable : QR1
8.3.2 Prédiction de vulnérabilités non connues : QR2
8.3.3 Discussion
8.4 Menaces à la validité
8.5 Résumé
IV Conclusion
