Exploting (II): Stack Overflow Simple (I)

La semana pasada pusimos un ejemplo de como podemos aprovechar una vulnerabilidad de Buffer Overflow para saltarnos un proceso de autenticación sin tener que acudir a sobreescribir la dirección de retorno en la pila. El de la semana pasada es probablemente uno de los casos más sencillos de Buffer Overflow, ya que es bastante inmediato ver que si podemos desbordar el buffer podemos tener control de todas las variables que se hayan declarado en las siguientes posiciones de memoria.

Esta semana vamos a dar un paso más allá y vamos a irnos al caso del Stack Overflow típico, es decir, hemos hecho un pequeño programa de ejemplo que contiene una vulnerabilidad de Buffer Overflow que puede ser aprovechada para ejecutar código en la máquina, y esto es lo que vamos a hacer.

El código de ejemplo, aunque se llama desde dentro de un código más amplio para favorecer un tamaño de pila adecuado para no complicar más las cosas, es el siguiente:

Como podemos ver, la variable buffer tiene una longitud de 10 caracteres (osea, 10 bytes). Sin embargo, se está obteniendo por teclado una cadena que está siendo guardada en esta variable sin ningún tipo de control de la cantidad de caracteres que se van a escribir. Por lo tanto, aquí tenemos una vulnerabilidad de Buffer Overflow de libro.

En este caso tenemos el código y podemos ver que la vulnerabilidad existe con total seguridad, pero en otras ocasiones no tendremos tanta suerte. En cualquier caso, vamos a olvidarnos que disponemos del código y vamos a realizar una prueba. Para ello llamamos al binario y cuando nos solicite que escribamos vamos a intruducir una cadena muy muy larga de A's, para comprobar si podemos realizar un Buffer Overflow que sobreescriba la dirección de retorno almacenada en la pila y provocar un casque (es lo que ocurre si hacemos saltar la ejecución del código a una dirección inválida).

Primero que nada, lanzamos el binario a través de OllyDbg y lo ejecutamos sin poner ningún tipo de breakpoint ni nada similar. Si sobreescribimos correctamente la dirección de retorno que está almacenada en la pila, cuando la función termine, la dirección de retorno va a ser "basura", por lo que la ejecución del software va a saltar a una dirección inválida. En OllyDbg, veremos algo así:

Como podemos ver, la ventana en la que veriamos las intrucciones de código aparece en blanco, y la ejecución del proceso se ha detenido con un EIP (puntero de instrucción, que apunta a la instrucción que se está ejecutando) claramente no válido "AAAA" (0x41 = "A").

Ahora que ya sabemos como reconocer cuando se ha producido un Buffer Overflow, vamos a lanzar la aplicación vulnerable a través de OllyDbg y vamos a dejar que se ejecute sin ninguna restricción. Cuando nos ofrezca la posibilidad de escribir, vamos a escribir una cantidad muy grande de A's, obteniendo el siguiente resultado:

Si nos fijamos en la información resaltada en la imagen, el EIP ahora es 0x41414141, es decir, la dirección de retorno de la función vulnerable que estaba almacenada en la pila ha sido sobreescrita con A's. Genial! Eso quiere decir que podemos empezar a jugar...

Vale, ya sabemos que podemos sobreescribir la dirección de retorno, pero nos interesa saber exactamente que A's están sobreescribiendo esa dirección de retorno, para así poder hacer saltar la ejecución a donde nosotros queramos. ¿Cómo hacemos eso? Pues está claro que poniendo todos los caracteres iguales seguro que no.

Para hacerlo, lo mejor es tener primero una aproximación de con cuantos caracteres sobreescribimos la dirección de retorno. Si hemos probado con 10000 A's, podemos probar ahora con 5000, si sigue funcionando entonces con 2500, luego con 1250, hasta que lleguemos a un punto suficientemente acotado (un rango de 2000 o 3000 es suficiente) como para poder utilizar la siguiente técnica que vamos a ver.

En este caso, la cantidad de A's es entre 50 y 100, así que lo que vamos a hacer es escribir 50 A's y a continuación 50 caracteres diferentes, que nos permitan reconocer al ver 4 de ellos (estarán en el EIP) en que posición están exactamente. Para generar estos caracteres utilizaremos una de las herramientas de la tremenda y fantastica Metasploit (miooo, mi tesoooroooo): pattern_create.rb

# cd /opt/msf3
# cd tools
# ./pattern_create.rb 50
Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab

Con esto, ya solo tenemos que concatenar 50 A's con esta secuencia y repetir el proceso. Como supongo que no quereis tener que escribir cada vez a mano 50 A's, lo mejor es hacerse un pequeño script. Yo por ejemplo me lo he hecho en perl:

#!/usr/bin/perl
# EXPLOIT DE PRUEBAS - jselvi

# PARTES DEL EXPLOIT
my $relleno = "A" x 50;
my $msfpatron = "Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8Aa9Ab0Ab1Ab2Ab3Ab4Ab5Ab";

# CONSTRUIMOS EXPLOIT
my $exploit = $relleno.$msfpatron;

# LANZAMOS EXPLOIT
my $file = "exploit.txt";
open( $FILE, ">$file" );
print $FILE $exploit;
close( $FILE );

print "Fichero exploit.txt creado\n";

Con este script podemos crear un fichero de texto que contenga el exploit y utilizarlo (de momento, como no hay caracteres "raros", podemos simplemente copiar y pegar). Si lanzamos de nuevo con OllyDbg igual que lo hicimos antes e introducimos ahora esta cadena, el resultado será el siguiente:

Como podemos ver, ahora el EIP ha sido sobreescrito por 0x61413361, que por ser el procesador un Intel (Little Endian), quiere decir que hemos sobreescrito el EIP con {0x61, 0x33, 0x41, 0x61}, es decir, con el patron "a3Aa".

Ahora que ya tenemos el patrón, sólo nos tenemos que ir de nuevo a Metasploit y utilizar la herramienta complementaria a la de antes: pattern_offset.rb

# ./pattern_offset.rb a3Aa 50
10

Así que tenemos 50 A's que hemos introducido a mano nosotros más 10 A's más que podemos seguir metiendo hasta alcanzar la dirección de retorno en memoria, y después de eso ya podemos introducir lo que queramos que sobreescriba la dirección de retorno. Hagamos una última prueba, vamos a escribir 60 A's seguidas de "BBBB" seguido de un patron "CCC1CCC2CCC3CCC4". Si todo va bien, el EIP acabará siendo BBBB y podremos ver en la memoria la cadena "CCC1CCC2...". Podemos generar todo el exploit modificando un poco el código perl de antes:

# PARTES DEL EXPLOIT
my $relleno = "A" x 60;
my $eip = "BBBB";
my $espacio = "CCC1CCC2CCC3CCC4";

# CONSTRUIMOS EXPLOIT
my $exploit = $relleno.$eip.$espacio;

Vamos a ver lo que pasa:

Parece que la cosa va MUY bien, ya sabemos cuantos bytes tenemos que escribir para sobreescribir la dirección de retorno, con lo que tenemos el control del EIP, y además podemos observar que la cadena "CCC1CCC2..." se encuentra apuntada por el registro ESP (puntero a la cima de la pila) después de salir de la función que hemos explicado. Lógico, pero interesante para nuestros propósitos, verdad?.

Lo tenemos chupado entonces, ¿no? Sólo tenemos que poner nuestro shellcode donde hemos puesto "CCC1CCC2..." y en el EIP de retorno almacenado en la pila sobreescribirlo con la dirección 0x0022C0D0, así cuando se salga de la función se recuperará este como EIP y saltará a ejecutar el shellcode que le pongamos.

En teoría, esto podría ser así, pero... no va a funcionar.
¿A alguien se le ocurre por qué?