INF4420: Éléments de Sécurité Informatique

1. INF4420: Éléments de Sécurité Informatique Module II : Sécurité OS et des logiciels

2. Module II – Aperçu • Semaine 5 – Sécurité dans les systèmes d'exploitation (SE) • Contrôle d'accès dans les SE • Authentification dans les SE • Semaine 6 – Sécurité dans les SE (suite) • Contrôle d'intégrité • Code malicieux • Contre-mesures • Semaine 7 – Sécurité du logiciel • Failles typiques et vulnérabilités • Techniques d'exploitation • Contre-mesures • Semaine 8 – période de relâche • Semaine 9 – Sécurité des BD et des applications Web • Semaine 10 – Contrôle périodique (jusqu'à semaine 7)

3. Plan de ce cours • Motivation • Types de faille de logiciel • Impact sur la sécurité • Vulnérabilités • Exploitations • Vulnérabilités de débordement de tampon • Débordement de variables • Débordement de pile • Contre-mesures • Autres vulnérabilités • Fuite d’information • Chaîne de formatage • Insertion de SQL

4. Génie logiciel (IEEE) Le programme ne fait pas ce qu'on lui a demandé de faire (spécification) Défaut ou "fault" ou "bug" Erreur de conception ou programmation Le programme fait ce qui a été spécifié, mais son exécution des conséquences non prévues (possiblement néfaste) Défaillance ou "Failure" ou "feature" Erreur de spécification Sécurité informatique Le programme a un défaut qui a des conséquences du point de vue de la sécurité Défaut de sécurité Exemple : erreur de programmation dans un programme de login Le programme fait ce qui est spécifié, mais le modèle de sécurité est inexistant ou fait défaut Défaillance de sécurité Erreur de spécification du point de vue de la sécurité Exemple : introduction de contre-mesures inadéquate, p.ex. algo de chiffrement trop facile à casser Le programme est bien conçu et bien construit, mais il a un comportement non prévu qui a des conséquence en terme de sécurité Taxonomie des failles des logiciels Dans tous les cas on parle de vulnérabilités du système

5. Dissection d'une attaque par exploitation • Le système ciblé fourni un service avec une interface accessible à l'attaquant • Accès physique (usager légitime) • Accès via le réseau • L'attaquant fait une reconnaissance du système et identifie le logiciel qui fournit le service ("footprinting" ou "fingerprinting") • Identification du SE • Identification de la version du logiciel • Outils automatisés (nmap, xprobe, etc.) • L'attaquant détecte une ou plusieurs vulnérabilités dans ce logiciel • Analyse du code source • "Cramming the input" • Liste de vulnérabilités connues (sites "white hat" et "black hat") • L'attaquant construit une méthode d'exploitation de ces ou cette vulnérabilité ("exploit") • Méthode artisanale ("Fuzzing the input") • Outils automatisés d'exploitation (Metasploit, etc.) • L'attaquant utilise cette exploitation pour atteindre ses desseins • Accès en mode "root" • Installation d’un trojan ou backdoor • Changement des permissions d'accès

6. Conditions de base Une variable tampon ("buffer") est accessible à l'usager Le programme ne vérifie pas si les valeurs entrées dépassent la mémoire allouée pour la variable tampon Les variables "cibles" qu'on veut changer ne sont "pas loin" et peuvent être changé par débordement Les variables et paramètres qui sont changés n'auront pas d'effets graves sur le fonctionnement du programme Attaques de débordement sur les variables Variable "cible" Variable "victime innocente" Tampon "accessible"

7. Révision – À quoi sert la pile • Pile ou "stack" • Utilisé par la machine de registre pour • Stocker les variables de l'environnement local • Gérer les appels de fonctions • Direction de remplissage • de la pile : vers le bas • des variables : vers le haut Variable locale 1 Environnement fonction originale Remplissage de pile Variable locale 2 pointeur d'environnement pointeur de retour arguments d'appel de fonction Variable locale A Environnement fonction appelée Remplissage de variables Variable locale B

8. ou "Stack-based Buffer Overflow" Conditions de base Après le retour de la fonction, les variables locales ne sont pas effacées Le code machine est inséré dans le tampon et autre variables qui pourraient suivre La valeur du pointeur de retour est modifié pour pointer vers le code inséré Lors de l'instruction de retour, la machine de registre lit le pointeur de retour et continue l'exécution à l'endroit indiqué Attaque par débordement de la pile Variable locale 1 Variable locale 2 pointeur d'environnement pointeur de retour modifié pointeur de retour arguments d'appel de fonction Code machine inséré execve ("/bin/sh") Variable locale A Tampon accessible (Variable local B)

9. Un example (*) void sample_function (char *string) { char buffer[16]; strcpy{buffer,string} return; } Void main () { char big_buffer[256]; int i; for (i=0; i<255; i++) big_buffer[i]='A'; sample_function(big_buffer); } (*) Tiré de "Counterhack" de Ed Skoudis, Prentice-Hall Environnement fonction main big_buffer (256) i (2) pointeur d'environnement pointeur de retour arguments d'appel de fonction *string Buffer (16) Environnement fonction appelée

10. Analyse du code source Fonction vulnérables en C/C++ fgets gets getws memcpy memmove scanf sprintf strcat strncpy Array à allocation dynamique Pointeurs Force brute Obtenir le programme (compilé) Déborder l'input du programme jusqu'à le faire crasher ("input cramming") Un nombre variable de 'A' Observer le "coredump" en cherchant des 'A' Exemple : EIP = 41414141 (Yeh !!) ESP = 00F4106C Déduction : distance à la pile Repérer les différents éléments de la pile Comment trouver des vulnérabilités de débordements

11. Difficultés de réalisation d'une exploitation • Quel code insérer ? • Doit être court (ne) • Doit permettre à l'attaquant de gagner accès au système • Solution typique : exécuter une fonction du système pour • partir un "shell" • créer un usager • lancer/arrêter un service • Problème : limiter par les droits d'accès du programme original • Où faire pointer le pointeur de retour ? • La distance entre le début du tampon et le pointeur de retour n'est pas nécessairement • Solution : traîneau de NOPs ("NOP sleds") • Comment éviter la détection automatique ? • Polymorphisme du code et des traîneaux de NOP

12. VÉRIFIER LE REMPLISSAGE DES TAMPONS !!!! Éviter l'utilisation de fonctions vulnérables Faire le remplissage caractère par caractère getchar() condition frontière DANS TOUS LES LANGAGES !! Utilisation de IDS Traîneaux de NOP Paquets excessivement longs Chaînes dans les charges payantes ("payloads") typiques, p.ex. "/bin/sh" Compilateurs et OS Connu et disponible Canaris (StackGuard) Stocker les pointeurs de retour en dehors de la pile (StackShield) Espace mémoire non-executable Solaris HP UX, Rustine pour Linux Win XP SP2 avec certains proceseeurs Possible mais pas développé Changer la direction de remplissage de la pile ?? Effacer le contenu de la pile avant le retour de fonction Outils automatisés analyse syntactique de code source "Vulnerability scanners" Contre-mesures contre les débordements de tampon

13. Attaques par fuite de mémoire • Conditions de base • Une variable "sensible" est allouée en mémoire (e.g. mot de passe) • Lorsque le code est terminée l'espace mémoire n'est pas mis à zéro • Lors d'une deuxième invocation ou via un autre programme la valeur de la variable sensible peut être obtenue en examinant la mémoire • Exemples d'utilisation • Par examen des "page file" résidant sur le disque dur • Espace tampon des dispositif de réseau • Prévention • Utilisation de destructeurs

14. Au delà du débordement de tampon • Format String Vulnerabilities • Utilise la fonction printf de C/C++ • printf ("%s", buffer) – bonne utilisation • printf (buffer) - mauvaise utilisation • La directive printf("…%n…", … , &variable) • permet d'écrire dans la variable le nombre de caractère imprimé • On insère dans le tampon accessible à l'utilisateur une "format string" • buffer = "… code … %n " (addrese stack)… • Contre-mesures • Toujours inclure une chaîne de formatage dans les invocations de printf • Éviter d’utiliser printf (plus vraiment nécessaire aujourd’hui)