Transcript 1 - LIRIS
FAILLES APPLICATIVES – INTRODUCTION & EXPLOITATION – Projet “Tutorat Réseau / Sécurité” INSA de Lyon – 2011 Lucas Bouillot Arnaud Kleinpeter Gaétan Bouquet Xavier Paquin – INTRODUCTION – – INTRODUCTION – Qu’est ce qu’une “faille applicative” ? Dans notre cas : « faiblesse dans un système informatique permettant à un attaquant de porter atteinte à l'intégrité de ce système, c'est-à-dire à son fonctionnement normal, à la confidentialité et l'intégrité des données qu'il contient » exploitation de programmes codés en C / C++ Quels types d’exploitation : Fuite d’informations Contournement de protections Détournement du flux d’exécution … – CONTEXTE D’ATTAQUE – Architecture INTEL x86 32 bits « little endian » Premières démonstrations sous Linux Dernière démonstration sous Windows XP Programmes C / C++ Démonstration, « Proof Of Concept » – CONTEXTE D’ATTAQUE – 2 types d’attaques : « remote » « local » Attaque en local : Contexte : l’attaquant possède un compte sur la machine cible (ex : session SSH) Cible : exploitation de binaires « setuid » But : « privilege escalation » – RAPPELS & PRE-REQUIS – – RAPPELS & PRE-REQUIS – Segmentation de la mémoire adresses basses .Text code du programme .Data données statiques et globales initialisées .Bss adresses hautes données statiques et globales non-initialisées .Heap données allouées dynamiquement .Stack Variables locales, contexte de fonction – RAPPELS & PRE-REQUIS – Quelques notions d’assembleur Les registres : De calcul : EAX, EBX, ECX, EDX De pile : EBP, ESP D’instruction : EIP Quelques instructions : PUSH reg, POP reg CALL / RET MOV dest, src – RAPPELS & PRE-REQUIS – Appel de fonction : gestion de la pile adresses basses Sens de la pile ESP EBP Contexte d’exécution de main() adresses hautes – RAPPELS & PRE-REQUIS – Appel de fonction : gestion de la pile 1 2, 3 adresses basses 4 5 6 Contexte d’exécution de fonction() SEBP ESP EBP SEIP 1. Argument 1 … Argument N 2. Contexte d’exécution de main() 5. adresses hautes 3. 4. 6. Empilement des arguments Sauvegarde d’EIP (SEIP) sur la pile EIP ← adresse de la fonction à appeler Sauvegarde d’EBP (SEBP) EBP « remonte » au niveau d’ESP Création d’espace pour le contexte de la fonction – RAPPELS & PRE-REQUIS – Appel de fonction : gestion de la pile adresses basses 1 2 3 ESP Contexte d’exécution de fonction() EBP SEBP SEIP Argument 1 … Argument N Contexte d’exécution de main() adresses hautes 1. 2. 3. Suppression du contexte de la fonction Restauration d’EBP (depuis SEBP) RET = POP EIP = Restauration d’EIP (depuis SEIP) – RAPPELS & PRE-REQUIS – Outils pour l’exploitation Un désassembleur / débuggeur : UNIX : GDB – GNU Debugger Windows : OllyDBG, WinDBG, IDA Un peu de shell Des « shellcodes » Suite d’instruction assembleur précompilées Permet de lancer un shell (d’où le nom…) On détournera le flux d’exécution grâce à ça – EXPLOITATION N°1 – Buffer Overflow – EXPLOITATION N°1 – Buffer Overflow – Introduction « buffer » ? « overflow » ? Zone de mémoire (ex : tableau d’éléments, structure de donnée, zone allouée avec malloc, …) dépassement Lors d’une copie, que se passe-t-il si la taille des données est supérieure à la taille du buffer qui est censé les recevoir ? – EXPLOITATION N°1 – Buffer Overflow – Explications La faille : copie de données utilisateur sans vérification de la taille Exploitation la plus courante : « stack overflow » Injection d’un shellcode sur la pile et calcul de son adresse Dépassement de capacité d’une variable sur la pile Écrasement de SEIP par l’adresse du shellcode ⇒ Le programme saute à l’adresse du shellcode lors du « RET » et l’exécute ! – EXPLOITATION N°1 – Buffer Overflow – Explications adresses basses ESP adresses basses ESP Contexte d’exécution actuel EBP SEBP SEIP EBP AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA AAAAAAAA @SHELLCODE SHELLCODE : \x90\x90\x90\x90 \xEB\x1A\x31\xC0 … adresses hautes adresses hautes – EXPLOITATION N°2 – Integer Overflow – EXPLOITATION N°2 – Integer Overflow – Introduction Opération mathématique qui produit une valeur numérique supérieure au maximum stockable Limites : Type Taille Signé Non signé char 8 bits [ -128 ; 127 ] [ 0 ; 255 ] short 16 bits [ -32768 ; 32767 ] [ 0 ; 65535 ] int 32 bits [ -2 147 483 648 ; 2 147 483 647 ] [ 0 ; 4 294 967 295 ] … – EXPLOITATION N°2 – Integer Overflow – Introduction Exemple : avec un char 0 1 1 1 1 1 1 1 127 0 0 0 0 0 0 0 1 1 1 0 0 0 0 0 0 0 -128 + – EXPLOITATION N°2 – Integer Overflow – Introduction Exemple : avec un unsigned int 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 073 741 824 4 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 1 * 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 = 4 294 967 296 =0 – EXPLOITATION N°2 – Integer Overflow – Explications La faille : erreur de typage, non vérification des conditions limites, … Diverses exploitations selon les cas : Contournement de vérification sur la taille Tentative d’allocation d’une zone mémoire de taille nulle … – EXPLOITATION N°3 – Format String Attack – EXPLOITATION N°3 – Format String – Introduction Fonctions à arguments variables <type> fonction( <type> argument1, … ); Un 1er argument obligatoire Utilisation des macros va_start, va_arg et va_end pour récupérer les arguments suivants Exemple : la famille « printf » printf( "chaîne de format", argument1, …, argumentN ) Affichage d’une chaine formatée – EXPLOITATION N°3 – Format String – Introduction adresses basses ESP Contexte d’exécution de printf() EBP SEBP SEIP %x Contexte d’exécution de la fonction appelante adresses hautes Que se passe-t-il si on ne donne pas le bon nombre d’arguments à printf() ? printf( "%x" ); ? ⇒ utilisation des valeurs de la pile ou « seraient » normalement empilés les arguments ⇒ résultat : bffffbd4 – EXPLOITATION N°3 – Format String – Explication La faille : utilisation d’une entrée utilisateur dans une chaine de format l’utilisateur pour fournir lui-même un formatage pour manipuler la mémoire Exemple : printf( argv[1] ); Bonne utilisation : printf( "%s", argv[1] ); Si argv[1] contient des « %... » ils seront interprété comme chaîne de format Peu importe ce que contient argv[1], ce sera uniquement affiché comme une chaine de caractères – EXPLOITATION N°3 – Format String – Explication Formats utiles pour l’exploitation : %x : affichage hexadécimal d’une valeur fournie printf( "%x", 1234 ) → affiche « 4d2 », conversion hexadécimale de 1234 ⇒ Lectures arbitraires en mémoire %hn : écriture du nombre d’octet traité par printf à l’adresse fournie (sur 2 octets) printf( "%x%hn", 1234, 0x12345678 ) → affiche « 4d2 » (donc 3 caractères) → écrit la valeur « 0x0003 » à l’adresse 0x12345678 ⇒ Écritures arbitraires en mémoire – EXPLOITATION N°3 – Format String – Explication 2 problèmes → 2 solutions 1. Problème : Comment spécifier l’adresse où écrire, puisque les valeurs utilisées seront celles qui suivent sur la pile ? ⇒ Solution : « Direct Parameter Access » printf( "%3$x", 1, 2, 3 ) affiche « 3 » ⇒ Nos données aussi sont sur la pile : en donnant un numéro d’argument suffisamment lointain on peut retomber sur une valeur que l’on contrôle, comme si on contrôlait le Nième paramètre de printf. – EXPLOITATION N°3 – Format String – Explication 2 problèmes → 2 solutions 2. Problème : Comment écrire une valeur précise, puisque c’est le nombre d’octets traité par printf qui est écrit ? ⇒ Solution : Taille minimum printf( "%010x", 1234 ) affiche 00000004d2 ⇒ A partir de la valeur voulue, on peut spécifier une taille minimum pour ajuster le nombre d’octets traités par printf sur cette valeur – EXPLOITATION N°3 – Format String – Explication Une exploitation parmi d’autres : Injection d’un shellcode sur la pile et calcul de son adresse Recherche d’un pointeur de fonction utilisée après l’appel à printf Écrasement du pointeur de fonction par l’adresse du shellcode en 2 étapes : Adresse = 4 octets, or %hn = écriture de 2 octets Ajustement et écriture de la 1ère moitié Ajustement et écriture de la 2ème moitié ⇒ Lors de l’appel de la fonction écrasée, le programme saute à l’adresse du shellcode et l’exécute, croyant se trouver dans la fonction légitime ! – EXPLOITATION N°3 – Format String – Explication Chaine type pour l’exploitation : <addr1> <addr2> %<num1>x %<param1>$hn %<num2>x %<param2>$hn • <addr1> : adresse des 2 premiers octets du pointeur de fonction • <addr2> : adresse des 2 derniers octets du pointeur de fonction • <num1> : nombre pour l’ajustement de la valeur écrite, sur la 1ère moitié de l’adresse du shellcode • <param1> : numéro d’accès direct au paramètre pour <addr1> • <num2> : nombre pour l’ajustement de la valeur écrite, sur la 2ème moitié de l’adresse du shellcode • <param2> : numéro d’accès direct à <addr2> (généralement <param1>+1) – EXPLOITATION N°3 – Format String – Explication Où trouver notre pointeur de fonction ? ⇒ Dans la GOT – Global Offset Table PRINTF : appel de fonction push ebp mov ebp,esp push ebx call 0xb7e9828f add ebx,0x10db3b … MALLOC : push mov push call add … ebp ebp,esp ebx 0xb7ff9d0b ebx,0x68eb EXIT : push mov push push push … ebp ebp,esp edi esi ebx GOT printf → 0xb7ecb4b0 malloc → 0xb7ff8700 SHELLCODE : exit exit→→@SHELLCODE 0xb7eb0a30 \x90\x90\x90\x90 \xEB\x1A\x31\xC0 … … – EXPLOITATION N°3 – “In The Wild” – EXPLOITATION N°3 – “In The Wild” – Introduction Les programmes précédents sont faits pour être corrompus Qu’en est-t-il de « vrais programmes » ? Une multitude de programmes vulnérables utilisés tous les jours IE, Firefox, Adobe Reader, libc, Exim4, … – EXPLOITATION N°3 – “In The Wild” – Introduction Une cible pour la démonstration ? Les logiciels en IF : Logiciel Dernière version Vulnérabilité connue ? IE v8.0.6001.18999 v 9 beta Pas assez de place ici… ;) Firefox v3.6.10 v 3.6.13 (v 4 beta 10) Use After Free Notepad++ v5.8.1 v 5.8.6 DLL Hijacking Acrobat Reader v9.3.4 v 10.0 Buffer overflow Filezilla v3.3.4.1 v 3.3.5.1 (v 3.4.0 beta) Passwords en clair … – EXPLOITATION N°3 – “In The Wild” – Adobe Acrobat Reader Quelques informations sur le format PDF Une collection d’objets Un dictionnaire des références aux objets Peut être compressé, chiffré Médias embarqués : images, vidéos, flash, pièces jointes, … Le coté obscur : JavaScript : implémentation parfois douteuse OpenAction / AutomaticAction / Handlers – EXPLOITATION N°3 – “In The Wild” – Adobe Acrobat Reader La cible : Adobe Acrobat Reader … v. 9.0.0 La faille : mauvaise implémentation de la méthode JavaScript getIcon() → Stack Overflow L’exploitation : Ouverture d’un PDF malveillant – EXPLOITATION N°3 – “In The Wild” – Adobe Acrobat Reader PDF Le PDF : OpenAction JavaScript • Shellcode • Heap Spray • getIcon() Presque vide Un script JavaScript Appel du script à l’ouverture Appel de la fonction getIcon() – EXPLOITATION N°3 – “In The Wild” – Adobe Acrobat Reader La technique du « Heap Spraying » Adresse choisie 0x0c0c0c0c NOP + SHELLCODE NOP + SHELLCODE NOP + SHELLCODE NOP + SHELLCODE NOP + SHELLCODE Heap Saut à l’adresse choisie sur le tas NOP + SHELLCODE Un « NOP Sled » Un shellcode NOP + SHELLCODE Choix d’un adresse de retour sur le tas Allocation de nombreux blocs contenant : NOP + SHELLCODE NOP + SHELLCODE – CONCLUSION – – CONCLUSION – Facile de prendre le contrôle d’un programme à partir d’une erreur de codage Exploitations de plus en plus compliquées, mais de plus en plus fréquentes : Exploitations qui ciblent le français moyen Lecteurs PDF → ☠ PDF malveillant Navigateurs → ☠ Page Web malveillant Clients Mail → ☠ Email malveillant … – CONCLUSION – Sécurisation / Protection : Impossible à éradiquer : le processeur ne différencie pas « code » et « données » Moyens de protections alternatifs qui rendent l’exploitation plus compliquée : ASLR – Address Space Layout Randomization Bit NX – Page mémoire « Non eXecutable » DEP, SafeSEH, Kernel patches, … La meilleure des protection reste encore de coder proprement ⇒ impossible… – QUESTIONS ? – – LE MOT DE LA FIN – Intéressé par la sécurité ? La « Nuit Du Hack » 2011 18 juin à Paris entrée : 30 € – LE MOT DE LA FIN – Programme : Conférences Ateliers Challenge ! Exemple d’épreuves : Failles web : injection SQL et xpath, XSS, includes, … Wargame : overflow, format string, race conditions … Reverse : crackme android, nintendo DS, ARM, … CTF : attaque défense en équipe ! – LE MOT DE LA FIN – http://www.nuitduhack.com/