failles applicatives

FAILLES APPLICATIVES – INTRODUCTION & EXPLOITATION –

Projet “Tutorat Réseau / Sécurité”

INSA de Lyon – 2011

Lucas Bouillot Gaétan Bouquet

Arnaud Kleinpeter Xavier Paquin

– INTRODUCTION –

– INTRODUCTION –

Qu’est ce qu’une “faille applicative” ? « 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 »

Dans notre cas : 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

code du programme .Text

.Heap

.Data

.Bss

.Stack adresses hautes

adresses basses

données statiques et globales initialisées

données statiques et globales non-initialisées

données allouées dynamiquement

Variables locales, contexte de fonction

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 –

Quelques notions d’assembleur

– RAPPELS & PRE-REQUIS –

Appel de fonction : gestion de la pile

adresses hautes

adresses basses

Sens de la pile

ESP

EBP

Contexte

d’exécution de

main()

– RAPPELS & PRE-REQUIS –

Appel de fonction : gestion de la pile

Contexte

d’exécution de

fonction()

SEIP

SEBP

Contexte

d’exécution de

main()

1. Empilement des arguments

2. Sauvegarde d’EIP (SEIP) sur la pile

3. EIP ← adresse de la fonction à appeler

4. Sauvegarde d’EBP (SEBP)

5. EBP « remonte » au niveau d’ESP

6. Création d’espace pour le contexte de la fonction

2, 3

5

4

adresses hautes

adresses basses

Argument 1

…

Argument N

1

6

ESP

EBP

– RAPPELS & PRE-REQUIS –

Appel de fonction : gestion de la pile

1. Suppression du contexte de la fonction

2. Restauration d’EBP (depuis SEBP)

3. RET = POP EIP = Restauration d’EIP (depuis SEIP)

2

1

3 Contexte

d’exécution de

fonction()

SEIP

SEBP

Contexte

d’exécution de

main()

adresses hautes

adresses basses

Argument 1

…

Argument N

ESP

EBP

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

– RAPPELS & PRE-REQUIS –

Outils pour l’exploitation

– EXPLOITATION N°1 –

Buffer Overflow

« buffer » ? Zone de mémoire (ex : tableau d’éléments, structure

de donnée, zone allouée avec malloc, …)

« overflow » ? 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 – Introduction

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

– EXPLOITATION N°1 –

Buffer Overflow – Explications

AAAAAAAA

AAAAAAAA

AAAAAAAA

AAAAAAAA

AAAAAAAA

AAAAAAAA

@SHELLCODE

AAAAAAAA

SHELLCODE :

\x90\x90\x90\x90

\xEB\x1A\x31\xC0

…

adresses hautes

adresses basses

ESP

EBP

Contexte

d’exécution

actuel

SEIP

SEBP

adresses hautes

adresses basses

ESP

EBP

– EXPLOITATION N°2 –

Integer Overflow

Opération mathématique qui produit une valeur numérique supérieure au maximum stockable

Limites :

– EXPLOITATION N°2 –

Integer Overflow – Introduction

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 ]

…

Exemple : avec un char

– EXPLOITATION N°2 –

Integer Overflow – Introduction

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

Exemple : avec un unsigned int

– EXPLOITATION N°2 –

Integer Overflow – Introduction

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

4 *

= 4 294 967 296 = 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 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 0 0 1

1 073 741 824

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°2 –

Integer Overflow – Explications

– EXPLOITATION N°3 –

Format String Attack

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

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 – Introduction

Contexte

d’exécution de

printf()

SEIP

SEBP

Contexte

d’exécution de

la fonction

appelante

adresses hautes

adresses basses

ESP

EBP

%x

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] );

– EXPLOITATION N°3 –

Format String – Explication

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

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 :

– EXPLOITATION N°3 –

Format String – Explication

• <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)

<addr1> <addr2> %<num1>x %<param1>$hn %<num2>x %<param2>$hn

Où trouver notre pointeur de fonction ? ⇒ Dans la GOT – Global Offset Table

– EXPLOITATION N°3 –

Format String – Explication

MALLOC :

push ebp

mov ebp,esp

push ebx

call 0xb7ff9d0b

add ebx,0x68eb

…

EXIT :

push ebp

mov ebp,esp

push edi

push esi

push ebx

…

PRINTF :

push ebp

mov ebp,esp

push ebx

call 0xb7e9828f

add ebx,0x10db3b

…

SHELLCODE :

\x90\x90\x90\x90

\xEB\x1A\x31\xC0

…

printf → 0xb7ecb4b0

malloc → 0xb7ff8700

exit → 0xb7eb0a30

…

GOT

appel de fonction

exit → @SHELLCODE

– EXPLOITATION N°3 –

“In The Wild”

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 :

– EXPLOITATION N°3 –

“In The Wild” – Introduction

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

…

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

Le PDF :

Presque vide

Un script JavaScript

Appel du script à l’ouverture

Appel de la fonction getIcon()

– EXPLOITATION N°3 –

“In The Wild” – Adobe Acrobat Reader

PDF

JavaScript

OpenAction

• Shellcode

• Heap Spray

• getIcon()

La technique du « Heap Spraying » Choix d’un adresse de retour sur le tas Allocation de nombreux blocs contenant :

Un « NOP Sled » Un shellcode

Saut à l’adresse choisie sur le tas

– EXPLOITATION N°3 –

“In The Wild” – Adobe Acrobat Reader

Heap

NO

P +

SH

ELLC

OD

E

NO

P +

SH

ELLC

OD

E

NO

P +

SH

ELLC

OD

E

NO

P +

SH

ELLC

OD

E

NO

P +

SH

ELLC

OD

E

NO

P +

SH

ELLC

OD

E

NO

P +

SH

ELLC

OD

E

NO

P +

SH

ELLC

OD

E

NO

P +

SH

ELLC

OD

E

Adresse choisie

0x0c0c0c0c

– 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 malicieux

Navigateurs → ☠ Page Web malicieuse

Clients Mail → ☠ Email malicieux

…

– 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/