elhacker.net cabecera Bienvenido(a), Visitante. Por favor Ingresar o Registrarse
¿Perdiste tu email de activación?.


 


Tema destacado: [AIO elhacker.NET 2015] Compilación herramientas análisis y desinfección malware


+  Foro de elhacker.net
|-+  Seguridad Informática
| |-+  Bugs y Exploits (Moderador: berz3k)
| | |-+  aprendiendo buffers overflows
0 Usuarios y 1 Visitante están viendo este tema.
Páginas: [1] 2 Ir Abajo Respuesta Imprimir
Autor Tema: aprendiendo buffers overflows  (Leído 8,020 veces)
fredi123

Desconectado Desconectado

Mensajes: 36



Ver Perfil
aprendiendo buffers overflows
« en: 13 Noviembre 2003, 10:44 »

buano, hola gente, salu2 desde montevideo uruguay.
estoy tratando de aprender esto de los buffers overflows leyendo distintos textos encontrados en ezines o por la red, y en varios textos he encontrado algunos errores en comun.
1- por lo general para desbordar el buffer de un programa vulnerable q aparezca en un texto tengo q poner mas "A" de las q aparecen en el mismo para desbordarlo, por ej si el buffer es de 180, en mi caso no se desborda con "A"x"184" como en un texto de la revista disidents sino con "A"x"204" para q salga el segmentiont fault.
2- cuando el buffer se desborda nunca pude ver eso del core dump, parece q no me lo encuentra, la verdad no entiendo del tema y no puedo seguir adelante con el aprendizaje.
ej
bash-2.05b$ gdb vulner core --quiet
/home/jorge/stacks/core: No such file or directory.
(gdb)
ok, por ahora no voy a preguntar mas nada para no atomizar mucho.
gracias y espero una respuesta
En línea

nitr0us

Desconectado Desconectado

Mensajes: 208


#rm -fr /


Ver Perfil WWW
Re:aprendiendo buffers overflows
« Respuesta #1 en: 13 Noviembre 2003, 22:50 »

holas......
xialex...... después de no se cuantos meses... algún post interesante :D

a mi me pasa lo mismo a veces... o sea, es que cuando escriben las zines, pues los ejemplos han sido probados en las pcs de los que la escriben (o sea, no todas las pcs son iguales).

Ya que pues... cada pc... puede ser diferente MICROPROCESADOR.. memoria..... formade ordenamiento BIG ENDIAN O LITTLE ENDIAN --> o sea, no es lo mismo un RISC... a un INTEL.

me pasaba igual... al meter el string en la stack pues no se desbordaba como deciá la zine.... le tenia que meter unos mas.. a veces los otros 4..

o sea, pero pues lo que si he probado y si es seguro ES QUE A FUERZA !..... METERLE 8 BYTES MAS.... O SEA, 4 DE EBP Y LOS OTROS 4 DE EIP y con eso si me ha rulado siempre.

mira este ejemplo.. anduve jugando con el bajo command.com (windows me) .. lo compilé en TURBO C 3.0..... y puies está medio pendejo !! le metes 4 bytez de mas=segmentation default......... 8 de mas y me aparecen mamadas en pantalla.. se hace infinito, no se desborda :D

MIRA.. ESTÁ MEDIO PENDEJO , KITALE LOS COLORCITOS.. ES NADA MAS PARA ALUMBRARLO :P.. mira, si t das cuenta el argumento 1 aki está como argv[2].. no tengo ni pinche idea por que... se supone que argv[0] es el nombre del programa y el argv[1] es el argumento 1...... pero por mas HICE PRUEBAS Y NADA.... EL PRIMER ARGUMENTO SE VA A argv[2]..... y pues lo hize asi......CREO QUE ES POR EL COMPILER YA QUE USÉ TURBO C... Y DESDE LINUX PUES NORMAL con argv[1].

salu2

#include<stdio.h>
#include<string.h>
#include<conio.h>
#include<graphics.h>

int main(int argc,char *argv)
{
   char buffer[8];
   int k;
   clrscr();
   if(argc!=2)
   {
      textcolor(3);
      gotoxy(10,10);
      cprintf("El programa necesita un parametro extra\n");
      gotoxy(10,13);
      cprintf("Ejemplo:\n\n");
      gotoxy(10,15);
      cprintf("%s argumento (el argumento es una cadena de texto)",argv[0]);
      getch();
      clrscr();
      return(0);
   }
   clrscr();
   gotoxy(1,5);
   printf("Simple Stack Buffer Overflow By Nitrous\n\n");
   printf("Esto es lo que escribiste: %s\n",argv[2]);
   printf("Tiene un total de %d bytes\n\n",strlen(argv[2]));
   strcpy(buffer,argv[2]);
   printf("Esto es lo que hay en el buffer:\n%s\n",buffer);
   printf("Tiene un total de %d bytes\n\n",strlen(buffer));
}
En línea

Rojodos
Colaborador
***
Desconectado Desconectado

Mensajes: 3.535



Ver Perfil WWW
Re:aprendiendo buffers overflows
« Respuesta #2 en: 16 Noviembre 2003, 08:58 »

Weno, lo del buffer es porq no lo estas haciendo bien...

Plz, postea el codigo vulnerable que usas para las pruebas.
En línea

fredi123

Desconectado Desconectado

Mensajes: 36



Ver Perfil
Re:aprendiendo buffers overflows
« Respuesta #3 en: 17 Noviembre 2003, 05:55 »

he leido varios textos en los q se me ha presentado el mismo problema con esto del core dump por lo q voy a poner un ejemplo citado desde el texto "buffer overflows para kiddies" y luego pondre lo q me pasa a mi "

esto es lo q esta en el texto:
------------------------------------------------------------------------------------------------
-------\ kid.c \

#include <stdio.h>

int main() {
  char kidbuffer[1024];

  if (getenv("KIDVULN") == NULL) {
    fprintf(stderr, "Grow up!\n");
    exit(1);
  }
   
  /* Mete los datos de la variable de entorno en el buffer */
  strcpy(kidbuffer, (char *)getenv("KIDVULN"));

  printf("La variable de entorno KIDVULN es:\n\"%s\".\n\n", kidbuffer);

  printf("No es la vida maravillosa en una guarderia?\n");

  return 0;
}
 
-------\

export KIDVULN=`perl -e '{print "A"x"1030"}'

/bin/kids
Environment variable KIDVULN is:  
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
 AAAAAAAAAAAAAAAAAAA....

No es la vida maravillosa en una guarderia?
Segmentation fault (core dumped)
[root@localhost teleh0r]# gdb -c core /bin/kids
GNU gdb 19991004
Copyright 1998 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 "i386-redhat-linux"...
Core was generated by /bin/kids'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libc.so.6...done.
Reading symbols from /lib/ld-linux.so.2...done.
#0  0x4000af9a in _dl_sysdep_output (fd=2,
    msg=0x40108f8b <Address 0x40108f8b out of bounds>) at dl-misc.c:95
95      dl-misc.c: No such file or directory.
(gdb) info register esp
esp            0xbffff720   -1073744096
(gdb) quit
-------------------------------------------------------------------------------------------
bueno, esto es lo q pasa en el texto ahora veamos lo q me pasa as mi:
--------------------------------------------------------------------------------------------
bash-2.05b$ export KIDVULN=`perl -e '{print "A"x"1038"}'`
bash-2.05b$ ./kid
La variable de entorno KIDVULN es:
"AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
.
 
No es la vida maravillosa en una guarderia?
Segmentation fault
bash-2.05b$ gdb -c core /bin/kids
GNU gdb 5.3
Copyright 2002 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 "i386-slackware-linux".../bin/kids: No such file or directory.
 
/home/jorge/stacks/core: No such file or directory.
(gdb)
---------------------------------------------------------------------------------------------
el core no se genera, quisiera mas informacion acerca del core y cualquier ayuda para esto, tambien si nesesitan mas detalles con gusto se los dare
gracias
En línea

Rojodos
Colaborador
***
Desconectado Desconectado

Mensajes: 3.535



Ver Perfil WWW
Re:aprendiendo buffers overflows
« Respuesta #4 en: 17 Noviembre 2003, 08:20 »

Hay un sigsev pero no hay core.... uhm....

Weno, vayamos por partes, de lo que se...

Antes de nada, seguramente el ejecutable ejemplo fue generado en 1999 y seguramente con un GCC < 3.X

Y tu, el *.c lo compilas, casi seguro, con gcc > 3.X

A partir del gcc 3.x, se añaden a los buffers unos bytes de "alineamiento" , debido a que los registros de memoria deben ser pares.... weno, es un rollazo de arquitectura de computadores, te toca investigar...

No son mas de 3bytes, de todas formas...

Otra cosilla, creo que al compilar, debes poner alguna opcion para que si se ejecuta y hace sigsev, falle, y haga core...

De todas formas, te remetire a donde casi siempre --> www.undersec.com

Hay excelentes textos sobre el tema..

Salu2
En línea

fredi123

Desconectado Desconectado

Mensajes: 36



Ver Perfil
Re:aprendiendo buffers overflows
« Respuesta #5 en: 18 Noviembre 2003, 06:18 »

por si a alguien le interesa o le pasa lo mismo q a mi (no se generaba el core) consegui la respuesta a esto, se debe hacer ulimit -c 30000 y se genera perfectamente.
ahora, tengo un problema con los offset, no los entiendo, nesesitaria algun link con mas detalles o ver como se hace para buscar estos offset ya q por ejemplo y siguiendo con el texto de bof for kids, hay un programa q se llama bah.sh para buscar offset para el programa vulnerable kid.c.
en mi caso el programa no encuantra ningun offset por lo q no lo puedo explotar.
cualkier ayuda con este tema sera muy agradecida.
salu2 y me gusto mucho q el tema siga en pie en este foro.
En línea

T3400

Desconectado Desconectado

Mensajes: 7



Ver Perfil
Re:aprendiendo buffers overflows
« Respuesta #6 en: 18 Noviembre 2003, 17:26 »

Nass. Lo del ulimit -c venia en 1 texto de buffer overflows en undersec, eso te pasa x leer textos de donde no debes jeje (es broma). Otra razon para que no haga core logicamente es porque lo ejecutes en un directorio donde no tienes permisos de escritura.

Lo del argv[2] lo + probable es porque declaras argv como un puntero a char, cuando deberia ser un puntero a punteros (o array de punteros) a char. Resumiendo, si lo declaras char *argv siendo el valor de argv = 0x00000000:

argv[2] = 0x00000002

Si lo declaras como char *argv[] siendo argv = 0x00000000:

argv[2] = 0x00000008

Me imagino que sera x algo de eso por lo que no te funcione lo del argumento correctamente. En cuanto a buscar los offsets no hay un metodo claro. Puedes usar el metodo chapucero que es un usar un bucle y ejecutar el exploit con todos los valores posibles hasta que funcione, o puedes usar otros metodos mas refinados, como debuggear primero el programa vulnerable desde el propio exploit usando ptrace(), para analizar la memoria y encontrar el offset correcto. Puedes leer un texto en NetSearch Ezine #8 muy interesante sobre el tema que trae un exploit para el linuxconf que usa ese metodo, por ejemplo no usa ni un solo 'nop'  ;D.

Luego ya si te quieres meter en profundidad puedes analizar aparte tambien la estructura ELF del programa vulnerable para encontrar direcciones de llamadas a funciones, y debuggear con ptrace(), sacar direcciones de retorno, y todo lo que te apetezca. Por supuesto la mayoria de la gente no hace eso y usa lo tipico de './exploit offset', pero queda muy chulo un exploit local sin nops y sin offsets. Un saludo.

T3400
En línea

Rojodos
Colaborador
***
Desconectado Desconectado

Mensajes: 3.535



Ver Perfil WWW
Re:aprendiendo buffers overflows
« Respuesta #7 en: 19 Noviembre 2003, 00:02 »

Bajo mi humilde opinion, creo que antes de meterse con el ptrace() explicado por RaiSe, deberia hacerlo lo mas sencillo, para comprender como funciona, y luego ya pues desarrollar dichas tecnicas (o otras, el JMP-CALL en la scode, que te ahoras un offset, gt_sp para sacar ESP que te puedes aorrar otro,....)

Creo que lo mejor seria que debugeara el programa vulnerable, y vieras en la pila los valores de los offset directamente (aunq no son los mismos en ejecucion normal que en debug..) y lo explotaras....

argv siempre tiene que ser declarado como **argv o *argv[], sino al menos te da warning al compilar (al menos a mi)

Recuerda que argv[0] es el nombre del exploit o del programa, en argv[1] es donde esta el parametro (normalmente el offset)....

Salu2
En línea

fredi123

Desconectado Desconectado

Mensajes: 36



Ver Perfil
Re:aprendiendo buffers overflows
« Respuesta #8 en: 19 Noviembre 2003, 05:03 »

gracias de nuevo por todo ire probando todo de a poco y luego les cuento, la pagina de undersec q me decian ayer no estaba disponible por eso aun no he leido ningun texto de ahi pero hoy ya esta bien por lo cual les hare caso y leere lo mas q pueda de ahi.
un saludo para todos .
En línea

fredi123

Desconectado Desconectado

Mensajes: 36



Ver Perfil
Re:aprendiendo buffers overflows
« Respuesta #9 en: 19 Noviembre 2003, 10:12 »

empece a leer un documento sacado de undersec y ya tengo una duda , en el texto dice:
------------------------------------------------------------------------------------------------
raise@apolo formats]$ cat > codigo4.c
<++> formats/codigo4.c $fd032eadce0a74f3450fb2aa7ca5902b
#include <stdio.h>

main()
{
char pepe = "hola%n";
printf(pepe);
}
<-->

[raise@apolo formats]$ gcc -g -o codigo4 codigo4.c
[raise@apolo formats]$ gdb -q codigo4

[hacemos break justo antes del printf]

(gdb) c
Breakpoint 1, 0x804840c in main () at codigo4.c:7
7       printf(pepe);

(gdb) x/2xw $esp
0xbffff854:     0xbffff874      0x00000000
(gdb) x/1s 0xbffff874
0xbffff874:      "hola%n"


Bueno, analicemos.. Teoricamente el programa intentara escribir un 4 en la
posicion de memoria siguiente, es decir 0x00000000, que al estar fuera del
segmento actual producira un segv fault. Veamos si es correcto..


(gdb) c
Continuing.
Program received signal SIGSEGV, Segmentation fault.
0x4005fdd7 in vfprintf () from /lib/libc.so.6

(gdb) x/1i 0x4005fdd7
0x4005fdd7 <vfprintf+2103>:     mov    %ecx,(%eax)

(gdb) info reg eax
eax            0x0      0
--------------------------------------------------------------------------------------------
a m i me sucede esto:
---------------------------------------------------------------------------------------------
bash-2.05b$ gcc -g -o codigo4 codigo4.c
codigo4.c: In function `main':
codigo4.c:5: warning: initialization makes integer from pointer without a cast
codigo4.c:6: warning: passing arg 1 of `printf' makes pointer from integer without a cast
bash-2.05b$ gdb -q codigo4
(gdb) disass main
Dump of assembler code for function main:
0x8048328 <main>:       push   %ebp
0x8048329 <main+1>:     mov    %esp,%ebp
0x804832b <main+3>:     sub    $0x8,%esp
0x804832e <main+6>:     and    $0xfffffff0,%esp
0x8048331 <main+9>:     mov    $0x0,%eax
0x8048336 <main+14>:    sub    %eax,%esp
0x8048338 <main+16>:    mov    $0x804839c,%eax
0x804833d <main+21>:    mov    %al,0xffffffff(%ebp)
0x8048340 <main+24>:    sub    $0xc,%esp
0x8048343 <main+27>:    movsbl 0xffffffff(%ebp),%eax
0x8048347 <main+31>:    push   %eax
0x8048348 <main+32>:    call   0x8048268 <printf>
0x804834d <main+37>:    add    $0x10,%esp
0x8048350 <main+40>:    leave
0x8048351 <main+41>:    ret
End of assembler dump.
(gdb) break *0x8048347
Breakpoint 1 at 0x8048347: file codigo4.c, line 6.
(gdb) r
Starting program: /home/jorge/stacks/codigo4
 
Breakpoint 1, 0x08048347 in main () at codigo4.c:6
6         printf(pepe);
(gdb) x/2xw $esp
0xbffff8d4:     0x40156234      0xbffff8e8
(gdb) x/1s 0x40156234
0x40156234 <__DTOR_END__+4>:     "H?\022"
(gdb)

-------------------------------------------------------------------------------------------
algo esta mal, probe distintas direcciones pero no logre tener nada parecido a lo del texto.
en fin si alguien sabe q es lo q estoy haciendo mal le agradeceria cualquier ayuda ya q estoy muy interesado en el tema.
En línea

Páginas: [1] 2 Ir Arriba Respuesta Imprimir 

Ir a:  
Aviso Legal - Powered by SMF 1.1.21 | SMF © 2006-2008, Simple Machines