Abuser de scanf avec un shellcode ASCII

[Docteur Lalla]

Tuturu !

J'ai écrit un code en C tout ce qu'il y a de plus mignon utilisant un scanf :

#include <stdio.h>

void function()
{
    printf("You got me !");
}

int main()
{
    char str[5];
    scanf("%s", str);

    return 0;
}

Comme vous pouvez le voir, il existe une fonction "function", mais celle-ci n'est jamais appelée par le programme. Mon but est de l'exécuter au moyen d'un shellcode que j'injecterai dans le scanf. J'ai déjà une idée du code de mon shellcode, mais je n'arrive pas à l'utiliser. Je sais qu'il me faut faire un buffer overflow, mais malgré ça, je ne parviens pas à "rendre le shellcode exécutable". Est-ce que mon code est vulnérable à l'attaque que je veux faire ? (c'est peut-être ça aussi) Sinon, comment dois-je m'y prendre ?

Je vous remercie de votre lecture et vous fais des bisous.

[comaX]

Je ne connais pas le C, mais je crois comprendre ton code. Tu as une variable de 5 caractères, à laquelle tu vas en faire passer plus afin de produire un dépassement de tampon et réécrire les piles ?
Quand tu dis que tu as déjà une idée de ton shellcode (en fait, plutôt "code propriétaire" ou "arbitraire" comme j'ai pu le lire ailleurs puisque un shellcode est un code qui te donne accès au shell, non ?), c'est que tu as déjà repéré dans le débugger quelle endroit de la pile allait être réécrit, et comment tu pouvais la modifier ?

Comme je ne sais pas comment est compilé le C, est-ce que le fait que ta fonction ne soit jamais appelée n'est pas un problème ?

De façon générale pour ce qui est du buffer overflow, tu devrais trouver ton bonheur les liens que j'ai postés là :
http://hackademics.fr/showthread.php...ull=1#post6543

En toute logique, scanf est vulnérable, donc il n'y a pas de raison que ton code ne le soit pas !

[Docteur Lalla]

Bah en fait, le shellcode est tout simplement un code en langage machine que l'on injecte dans un programme déjà existant. Effectivement, à l'origine c'était fait pour ouvrir un shell, et accessoirement en root, mais on peut faire un peu n'importe quoi avec.
Ma fonction est aussi compilée, c'est juste que les instructions qui la composent ne seront jamais atteintes. Et le but, oui, ce serait de modifier les registres (principalement EIP) pour arriver sur cette fonction. C'est là que je bloque, je ne sais pas trop où aller chercher à partir du scanf pour atteindre EIP.
Je l'ai modifié manuellement avec GDB pour voir, une fois, et ça a parfaitement marché, il faut juste que j'apprenne a le faire avec un shellcode maintenant, d'où mon problème. ^^

[comaX]

Aaaaahhhh ! Bah si tu y es arrivé manuellement, tu n'es qu'à un pas. Suis le tuto de lupin, je l'ai trouvé très bien fait et j'ai réussi à exploiter des buffer overflow tout seul sur des applications (que je savais buggées hein, je suis pas fou... C'était de l'entraînement).

[Docteur Lalla]

J'ai justement fait des recherches et j'ai pu trouver quelques articles plutôt intéressants. Malheureusement, il ont toujours la manie de présenter la solution sans donner le problème. Donc on ne sait jamais quelle est la faille étudiée (arguments du main, bête accès à un pointeur douteux, I/O...) et ils en deviennent inutilisables. J'ai trouvé myriades de textes et je vais écumer tout ça mais as-tu une quelconque source à proposer ?

Je te remercie par avance.
Bisou.

[comaX]

Eh bien oui, niveau source, je te propose celles de Lupin. Il développe séparément les stack-based, heap spray, etc. Perso ça fait longtemps que je n'y ai pas touché et déjà que je n'étais qu'en initiation, je suis maintenant rouillé.

Pour ce qui est de la faille étudiée, je ne suis pas sur de comprendre ce que tu veux dire. Dans ton cas elle me semble évidente non ? Tu dépasse le tampon et réécrit le pointeur pour renvoyer vers du code proprio. Pour les autres cas étudiés, je ne saurais m'avancer. Tu n'as pas tellement besoin de connaitre l'origine d'une faille pour pouvoir l'exploiter. D'après les exemple que j'ai vu, c'est toujours du contenu non signé (pas checké quoi...) qui en est à l'origine.

Si tu n'as pas de problème avec l'anglais (ce dont je ne doute pas), tu devrais trouver ton bonheur dans les article de Lupin et Sickness. L'un est admin des forums Backtrack et contributeur (si je dis pas de connerie) et l'autre est carrément développeur de BT... A priori, ils savent de quoi ils parlent et ne sont pas allés sucer le truc ailleurs.

Enfin, si quelqu'un avec un peu plus de connaissances pouvaient intervenir, ça serait cool !

[Docteur Lalla]

Tuturu !

Je viens de réussir mon coup en récoltant des informations, notamment sur l'organisation de la pile.
J'obtiens bien mon "You got me !", mais je trouve la façon d'y arriver un peu bizarre. Je m'explique :

Mon buffer fait 5 octets. On le complète pour en avoir 8, jusque là ok. On rajoute 8 octets (en x86 en tout cas), pourquoi ?
J'ai donc accès à 16 caractères au lieu de 5. Normalement, on doit reprendre 4 octets (qui sont EBP), pour ma part, j'ai du n'en prendre qu'un.
Ensuite viennent les 4 octets qui forment EIP, pas de soucis à ce niveau.

Sachant que ma fonction cachée est à l'adresse 0x0804842C, mon shellcode aurait du être :
\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x2c\x84\x04\x08
soit : 20 fois \x90 (ou n'importe quoi d'autre) + \x2c\x84\x04\x08

Pour une raison obscure, je me retrouve alors avec :
\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x2c\x84\x04\x08
soit : 17 fois \x90 (ou n'importe quoi d'autre) + \x2c\x84\x04\x08

J'ai écrit ce shellcode dans un fichier via perl -e 'print "\x...."' puis j'ai exécuté mon programme en redirigeant l'entrée, soit :

perl -e 'print "\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x90\x2c\x84\x04\x08"' > input
./vulnerable < input

You got me !
Erreur de segmentation

Quelqu'un aurait-il une réponse à mes humbles questions ?
Bisou.

[comaX]

"Mon buffer fait 5 octets. On le complète pour en avoir 8, jusque là ok. On rajoute 8 octets (en x86 en tout cas), pourquoi ?
J'ai donc accès à 16 caractères au lieu de 5. Normalement, on doit reprendre 4 octets (qui sont EBP), pour ma part, j'ai du n'en prendre qu'un."

Je ne vois pas pourquoi tu "complètes" ton buffer. Tu as une différence de trois NOP entre tes deux input, et bizarrement, tu as voulu compléter ton buffer de 5 octets pour arriver à 8, ce qui nous fait une différence de trois octets ! Ton buffer est de 5, tu le dépasses donc dès que tu es au-dessus de 5 normalement.

Encore une fois, je suis rouillé, mais ça me semble venir de là.

[Docteur Lalla]

Ce que tu dis est parfaitement logique et j'aimerais y croire, pourtant si j'écris 16 caractères (5+3+8) et que je les envoie à gets, il ne bronche pas, aucune segfault.
Après, si c'est ça, c'est super, c'est pas trop dur à comprendre. ^^

[comaX]

Hmm, j'ai essayé de le faire moi-même... sur un système 64 bits... Youhou ! Quand j'aurais pas la flemme, je retest ça dans une VM de WXP32b... (si tu pouvais m'envoyer une version compilée... je n'ai pas de quoi faire pour le 32bits).

Ca me paraît bizarre ce que tu me dis là ! Mais enfin si ça fait ce que tu dis, il doit y avoir un raison, et j'entends bien la trouver !