Antes de nada, aquí vamos con los preparativos que diré siempre:
###############################################
Desactivar la aleatoriedad en las direcciones de la pila, para ello debeis ejecutar el comando (como root):
echo 0 > /proc/sys/kernel/randomize_va_space
Compilar (hoy si) con:
gcc -g -fno-stack-protector -z execstack codigo.c -o programa
###############################################
El otro día os dejé con una pregunta a partir de cuantas 'A's el programa empezaba a petar.
Vamos a explicar hoy el por qué peta (hoy toca algo de teoría) , pues es uno de los conceptos más importantes en el exploiting.
SOBREESCRIBIR EL REGISTRO EIP
Empecemos por el procesador, un elemento del ordenador el cual procesa datos e instrucciones, para finalmente realizar cálculos para lo cual se suele usar una ALU (Unidad Aritmético-Lógica). Los procesadores pueden guardar los datos en diferentes sitios, para ello pueden usar unas cosas llamadas "registros" los cuales tenemos algunos de proposito general AX,BX,CX,DX , tenemos otros que apuntan a los segmentos dentro de la memoria SS,CS,DS... (Para más información teneis el libro Arquitectura de Computadores de Hennessy y Patterson). Además de los registros, para guardar datos tenemos la memoria (la memoria recuerda cosas....).
De los registros tenemos uno de suma importania, IP o Instruction Pointer o Program Counter. Este registro se encarga de ir apuntando la siguiente dirección de memoria , como el código suelen ser saltos a funciones, condiciones, rutinas ... Pues necesitamos un registro que guarde la siguiente dirección de memoria a ejecutar. Bien en el programa de ejemplo del otro día hacíamos una llamada a una función, eso en ensamblador se convierte en un "Call", el cual es una de las pocas funciones que pueden modificar IP, al volver de la función el programa debe saber donde volver, por tanto guarda en una memoria específica (llamada la Pila a partir de ahora) el valor de IP antes de llamar a la función. En la pila se guardan los argumentos de las funciones, IP, variables locales... Esto permite la recursividad en programación.
Veamos un ejemplo de la llamada a la función del otro día en ensamblador (la cual tenía un argumento):
push arg ;mete argumento en la pila
call func ;llama a la funcion mete valor IP en la pila
Bien una vez dentro de la función debemos reservar como una "Pila" propia de la función para las variables de la función, esto es lo que se llama marco de pila, tenemos un registro llamado BS que apuntará al principio de esa pila, y tenemos SP que apunta siempre al final de nuestra pila. Pues un marco de pila se crea algo como así:
push bs ;guardamos el valor de bs (para no cargarnoslo), luego lo recuperaremos
mov bs, sp ; metemos el valor de sp, en bs (ya tenemos la base de nuestra pila)
sub sp, X ;restamos X al valor de sp, asi agrandamos nuestra marco de pila
Os preguntareis ¿Por qué restas X, en vez de sumar? si lo que queremos es agrandar, bien la pila va desde las direcciones de memoria más altas, a las más bajitas, por tanto para crecer, tenemos que restar (Imaginaos la pila como un hombre algo rata, nos deja unas direcciones lejos de la dirección más baja de la pila, una alta, y para reservar memoria en la pila, tenemos que quitarle direcciones, pues restamos).
Bien pues veamos un dibujo de como quedaría la pila, y a donde apuntarían ahora BS y SP.
Bueno vemos que en los registros antes ponemos una 'E', esto significa que es un procesador de 32 bits, y en lugar de guardar 16 bits en el registro, guardamos 32 (un sistema operativo de 32 bits, sus direcciones tienen 32 bits).
Como vemos arriba del todo (las direcciones más altas) tenemos un marco de pila de otra función (por ejemplo main), y seguido metemos unos argumentos, luego la dirección a la que volveremos después, seguido el valor de BP para volver a cogerlo al acabar la función, vemos que EBP, al realizar el mov ebp,esp , ahora ebp apunta a donde se puede ver, seguido se haría sub esp,32 , para guardar la variable nombre, por tanto ahora esp apunta al final del buffer nombre.
Ahora viene lo siguiente la...
¿Por qué? , por que mientras que el buffer Nombre, se reserva para abajo, crece para arriba, y nosotros al meter un gritón de 'A's, llenabamos el buffer, luego llenabamos el valor guardado de EBP y finalmente el valor guardado de EIP, por tanto al acabar la función en donde estaba el valor de EIP ahora hay "AAAA", y el procesador intentaba saltar a la dirección "0x41414141", la cual no está mapeada en nuestras direcciones de memoria.
Y por eso el programa petaba.
Ahora vamos una vez acaba la teoría, con la parte práctica.
¿Qué vamos a aprender?
- Encontrar manualmente cuantos bytes necesitamos para petar el programa.
- Encontrar automáticamente cuantos bytes necesitamos para petar el programa.
- Explotar este fallo para conseguir una shell.
Bien para realizar esto, vamos a utilizar el debugger: edb-debugger (Descargable aquí: https://github.com/eteran/edb-debugger ).
Para empezar vamos a ejecutar nuestro programa con este debugger y vamos a meter como argumento por ejemplo nuestro nombre y ver como se ejecuta:
En el centro tendremos bien en grandote tenemos el códigooooo (de momento pasad de este, por que no nos vale para nada).
Y finalmente tenemos los registros, los 4 primeros son registros de proposito general, tenemos EBP, ESP que apunta justo a la cima de nuestra pila (imagen de arriba de la Stack), ESI y EDI (ahora mismo no nos interesan mucho). Y finalmente uno que nos interesa mucho EIP, el cual vemos que está apuntando al principio del código que tenemos (imagen de arriba de código).
Como vemos está apuntando ahora mismo a una librería, todavía no es nuestro código. Por tanto para establecer todo al principio de nuestro main ejecutaremos: F9 .
Ahora tenemos otro código diferente y los registros también han cambiado su valor (en concreto EIP ahora apunta a la primera instrucción de nuestro código). Vamos a intentar reconocer un poco lo que se está haciendo. Lo primero que vemos es un lea (siglas de load effective address) a insertar un valor en ecx, ese valor es [esp+4]. Esto en ensamblador es una forma sencilla de meter en ecx el valor de esp + 4. Luego se realiza una operación lógica and, seguido de un push, el cual vale para insertar datos en la pila como hace push con [ecx-4] es coge el valor de ecx restale 4 y accede a la dirección de memoria que es igual a ese valor de la resta, y lo metes en la pila. Bien no es un curso de ensamblador para cualquier cosa podéis ir a las referencias de abajo.
Vamos a algo más clave, un cmp (código para compare), compara un valor que guarda la dirección de memoria guardada en eax, con 2 (igual que hacíamos en nuestro programa) estamos comparando argc con 2, en caso de ser iguales (jz [jump if zero] es igual a je [jump if equal]) y vemos que si son iguales salta a0x0804501 (un poquito más abajo).
Para poder avanzar en edb debugger tenéis F7 y F8 , la diferencia entre ambos es que F8 si encuentra un call (o función) la ejecuta y pasa por encima, y F7 NO.
Pues ejecutemos hasta realizar el salto:
Si vamos observando la pila veremos que al llegar al call, lo que tendremos es Fare9.
Y vamos a ver el código que tenemos:
En ensamblador al llamar a una función tenemos que meterle en la pila sus argumentos, los cuales los meteremos de derecha a izquierda, por tanto al meter [ebp+8] metemos el argumento que pasamos antes ("Fare9"), con lea eax,[ebp-40] , estamos haciendo que eax apunte al principio del buffer (40 bytes más abajo), seguido lo metemos en la pila y finalmente llamamos a strcpy. Ahí es donde vendrá nuestra oportunidad de insertar datos y datos. Iremos llamando ahora con F8 hasta llegar al call:
Hemos aprendido entonces como ver cuantos bytes necesitabamos para petar el programa manualmente.
2. Encontrar automáticamente cuantos bytes necesitamos para petar el programa.
ahora seremos más rápidos, sabemos que con gdb al ejecutar el programa y petarlo con tropecientas 'A's, nos decía gdb, el programa ha petado por intentar acceder a la dirección 0x41414141, bien¿ y si metemos "AAAABBBBCCCCDDDDEEEE...."?, depende de con qué sobreescribamos EIP nos dirá que ha petado con otra letra o conjunto de ellas, y después pues calcular "si he metido tropecientas letras en la cadena, y ha petado en la 'E', y cada letra eran 4 veces repetidas..." Bueno si no quereis hacer calculos podéis usar los programas "Pattern_create.rb" y "Pattern_offset.rb" de Metasploit los cuales uno te genera una cadena de caracteres aleatorios, y el otro le dices la cadena y el hexadecimal (creo) de dónde ha petado, y te dice bytes para petar el programa. Peeeero, si queréis un poco que pueda seguir con estas entradas, os pido useis mi versión PatternPetater . Un script en python que te hace las dos cosas a la vez.
En principio vamos a ejecutar el patternpetater, para ello : python randomGenerator.py .
Primero llamamos a gdb, seguido dentro de gdb ejecutamos run junto con la cadena que generó PatternPetatter, finalmente tuvimos un error con lo de la dirección : 0x77526846 (se cortó en la imagen). Bien copiamos esta cadena y la pegamos en PatternPetater, que estaba esperando por nosotros:
Bien con esto sacamos automáticamente cuantos bytes tenemos hasta petar el programa y sobreescribir EIP, esto nos será importante para saber que payload (lo explicaré en la siguiente entrega), podemos insertar, ya que 44 bytes no es mucho, por ejemplo un Meterpreter no podríamos.
3. Explotar este fallo para conseguir una shell.
Ahora vamos a crear un primer exploit en python, con lo cual uniremos un payload que se mostrará en el código, junto con purrelez que tenemos que meter para llegar a 44 bytes, más la dirección de retorno que guardaremos en donde estaba EIP, que será el principio del buffer, para que se ejecute nuestro código que insertamos:
Como vemos, al ejecutar el exploit, se llamó al printf que teníamos después de strcpy, hizo caplof, y por arte de magia (ir al gif de magic), nos devolvió una SHELL, para poder ejecutar nuestras cosas de Hackers y todo eso, por ejemplo podríamos dejar una shell a la escucha con netcat o aún mejor ncat cifrada con clave pública.
--------------------------------------------------------FIN
Como vemos hoy hemos aprendido mucho, mucho. Vimos como sacar manualmente el número de bytes para petar el programa, vimos como utilizar herramientas para conseguir esto, y además creamos un primer exploit (no digais que Fare9 no enseña cosas pa' aburrir) .
Ya sabeis que podeis encontrarme en Twitter ( como Fare9 ), o podeis escribir en comentarios e intentaré responderos lo antes posible.
Nos vemos en el siguiente "de 0 a exploiting"
Referencias:
Más información en los apuntes de laboratorio de este hombre: http://atc2.aut.uah.es/~rico/docencia.htm
