Esta vez me he dicho "... Fare9, ¿por qué no leer un libro de exploiting?", y dije "Verdad es, pues vamos".
Así que me pongo manos a la obra y leo el primer capítulo, y pienso en escribir sobre ello, así que aquí va un poco del primer capítulo para llegar de 0 a exploiting.
###############################################
Antes de seguir vamos a dar un concepto que teneis que seguir antes de empezar cada sesión de exploiting:
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
Para volver a activarlo, ejecutar el comando (como root):
echo 2 > /proc/sys/kernel/randomize_va_space
Ahora para compilar los programas (en esta primera entrega no hace falta, pero bueno mejor ir aprendiendolo):
gcc -g -fno-stack-protector -z execstack codigo.c -o programa
Esto quitará las protecciones que tienen de pila los sistemas operativos actuales, no es muy realista, pero nos vale para ir empezando
###############################################
Bien amigos, el primer concepto que vamos a meter es el Buffer Overflow, o también llamado Stack Overflow ( aquí tenemos un enlace que es de las primeras, y seguramente la primera respecto a buffer overflow: Smashing the stack for fun and profit ).
Que es esto del Stack overflow, un buffer en lenguajes como C o C++, es lo que se suele conocer como array, estos tienen un tamaño fijo en memoria, y tenemos funciones que copian valores a estas buffers, una de ellas y de máxima problemática de seguridad es "strcpy", puesto que no copia mirando cuanto mide el buffer, sino que copia una cadena hasta encontrar un \0, byte null, el ese que a veces pones al final de una cadena como cadena[strlen(cadena)-1] = '\0'.
Bien, pues pueden pasar cosas malas si llenamos demasiado ese buffer.
Vamos a verlo con un ejemplo de código:
Vemos aquí un buffer o array de caracteres dentro de la función func, al cual luego se le copia un argumento el cual es dado por el usuario como primer argumento del programa.
Ahora este programa podemos compilarlo con gcc, o vuestro compilador favorito e introducimos por ejemplo: ./ejemplo1 Fare9 . Obtendremos la siguiente salida:
Como vemos nada malo ocurre. Bien, ahora vamos a intentar desbordar la pila, vamos a intentar ser como esos Hackers que vemos en las pelis, y vamos a causar una denegación en el programa, o Fallo de segmentación debido a un acceso de memoria a la cual no tenemos acceso.
Vamos a meter un montón de 'A' y ver cuando peta, podemos empezar por 33, así como los más chungos, como sólo admite 32, pues con 33 petará.
Para esto vamos a ayudarnos de python y su parámetro -c (así no escribimos 33 'A's):
Vaya, parece ser, que no pasó nada... Podemos retirarnos de este mundillo que no valemos...
TRANQUILOS, si volvemos a los apuntes de Rico, vemos que la memoria se suele gestionar de maneras un poco "genéricas", bien, el programa intentará reservar una cantidad X de memoria un poco mayor al tamaño del buffer por si acaso, puede ser 34, puede ser 53 (bueno dejemos que es más de 32).
Pues probemos con más, probemos con 128 (así por probar).
Bien como vemos, ahora a petado. Podemos usar gdb, para ver un poco mejor por qué ha petado.
Vemos que hay una señal recibida desde el programa, por fallo de segmetanción y nos da una dirección 0x41414141, pero 0x41 es el ASCII de.... 'A' . Ahora las cosas empiezan a tener algo de sentido, parece ser que el programa intentó ir a una zona de memoria referenciada por 0x41414141, y no está mapeada por el sistema operativo para este programa, por tanto, fallo de segmentación.
Bien hasta aquí hemos aprendido un poco que es esto del stack overflow, la semana que viene tendremos la explicación de por qué pasa esto (con imágenes por supuesto).
Como tarea os voy a pedir, que por favor, en los comentarios me dejeis a partir de cuantas 'A', empieza a petar el programa.
Hasta aquí la primera parte (espero que de muchas) de 0 a exploiting.
