Buffer overflow, Votre première exploitation

# Author : fr0g
# Website : http://hwc-crew.com
# Date : 02/02/2012
# Thank's : Storn( bsoddigital.fr ), int_0x80( big-daddy.fr )


Hello all, avant que les esprits ne s'échauffent, je tiens à préciser qu'il est préférable, pour ne pas dire nécessaire voire "indispensable", d'avoir des connaissances sur le fonctionnement d'un processeur, l'Assembleur, et une connaissance théorique des failles de type "Stack Overflow" afin de pouvoir suivre ce tutoriel en le comprenant correctement, je vais procéder à l'exploitation d'un programme "bidon" en vous expliquant les étapes au fur et à mesure, toutefois, je vais essayer de me montrer le plus explicite possible .

NOTE : les mots suivis d'un "*" (exemple : BOF*) sont expliqués en bas de l'article

Analysons le programme qui va être exploité :

Afin de rendre notre exécutable vulnérable, on va le compiler de la manière suivante :
(afin de désactiver la détection des Buffer overflow)

Passons un coup notre programme à execstack pour savoir si l’exécution de la stack est possible :
(Pour installer execstack (sous Debian) : sudo apt-get install execstack)

Afin de savoir si le programme est vulnérable on fait :

Ceci nous signifie que la pile n'est pas exécutable, pour y remédier, execstack nous propose une fonction magique qui est :

On regarde à nouveau ? allez, soyons fous :

Yeaaah, il ne nous reste plus qu'a désactiver l'ASLR*, grâce à :

Trêve de futilités mondaines, passons à l'exploitation

Afin de déterminer à combien d'octets notre buffer va déborder, je vous invite à utiliser ce script:

On le lance avec le nom de notre application en paramètres :

On sait donc qu'a partir de 264 Octets, notre programme va planter : un petit test à l'ancienne :

Comme on le voit ici, le programme se ferme correctement à 263 octets, mais si on lui en donne 264, il plante. Maintenant, désassemblons notre exécutable avec cet outil magique qu'est le Gnu DeBugger, puis on va placer quelques octets (précisément des NOP (\x90)) dans l'argument sur lequel va travailler le programme, (dans le cas présent, j'en ai mis 270)


Si on regarde de plus près, l'adresse renvoyée par gdb : 0x08009090, on voit que les 2 derniers octets de l'adresse sont 9090 (90 est la valeur hexadécimale correspondant à l'instruction NOP en Assembleur)

Afin d'être certain que ce n'est pas une coïncidence, essayons avec deux NOP en plus:

BINGO !!!, Maintenant, un peu de calcul (rien de difficile ^^)

Je m'explique, l'adresse renvoyée par gdb correspond à ce que contient le registre EIP (qui est censé contenir en permanence l'adresse de la prochaine instruction à exécuter), autrement dit, il va falloir retirer au nombre de NOP entrés en paramètre, le nombre d'octets que l'on voudra placer dans EIP, afin qu'il pointe sur notre shellcode.

Donc : 272-4 = 268 NOPS

Essayons comme ceci :


EIP contient maintenant 0x44434241, ceci correspond à BCDA en hexadécimal,

Pourquoi est-ce à l'envers ?

Tous les détails ici : http://en.wikipedia.org/wiki/Endianness

c'est pareil pour les octets de l'adresse que l'on va placer dans la pile, pour connaître cette adresse, on observe les registres du processeur après avoir fais planter le programme avec la dernière commande :

EIP contient bien les octets que l'on à placé après les nops, allons jeter un œil au registre esp :

Il ne nous reste plus qu'à noter une adresse qui tombe dans les NOP : 0xbffff800

Allez, on repars dans un petit calcul, le Shellcode que l'on va utiliser est un simple /bin/sh de 24 octets :
( Source : http://big-daddy.fr/repository/C0dz/binsh%28Djo%29.txt )

Comme précédemment, il faut retirer au nombre de NOP le nombre d'octets composants shellcode, soit :

268 - 24 = 244
Notre exploit va se constituer de la manière suivante :

les 244 NOP + le shellcode + l'adresse de retour, il ne reste plus qu'a essayer, on lance l'exploit :

Je rappelle que notre adresse doit être écrite afin de correspondre à l'endiannes, donc 0xbffff800 = bffff800 = \x00\xf8\xff\xbf
ce qui donne :


Hmm, la fatigue me prends, une erreur de calcul manifestement, on voit clairement que l'adresse que l'on a placée dans l'argument avec les NOP et le shellcode n'est pas correctement placée dans EIP, mais cela n'est pas très grave, ajoutons un NOP histoire de la décaler, ce qui donne cet exploit :


Cette fois, ça devrait fonctionner, on quitte gdb, et on lance l'application avec notre exploit en paramètre :

Notre shellcode s'est éxécuté, et a correctement appelé le /bin/sh

Voilà, j'espère que j'ai été assez clair, bien que j'ai précisé que ce tutoriel s'adresse principalement aux initiés en langage Assembleur .

Cordialement, fr0g.

################################################################################

Lexique :

BOF : Abréviation de Buffer Overflow
ASLR : "Address space layout randomization" : permet de rendre aléatoir les adresses de pile


################################################################################