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/