• Ahora la dirección de retorno es “0xffffd5c0” como se muestra en el cuadrado amarillo
coincidiendo con la dirección de la pila elegida.
• Continuamos con la ejecución del programa mediante el comando en la ventana gdb
continue
• El exploit funciona llamando al shellcode. Es decir, tenemos un exploit de código en
funcionamiento, que ejecuta una shellcode (llama a la función exit() para salir del
programa) tras aprovecharse de la vulnerabilidad que contiene.
• Salimos del entorno de gdb
quit
17. Actualización del programa
Este exploit de código funciona únicamente con la compilación actual del programa. Si este
programa tuviera una actualización en la que se ha tenido que volver a compilar, deberíamos
de volver a cambiar nuestro exploit con una nueva dirección de retorno y ver si sigue siendo
igual de vulnerable.
• En una nueva terminal ejecutamos los comandos necesarios para copiar el archivo que
contiene el programa “name.c” a uno nuevo llamado “name2.c”
cp name.c name2.c
nano name.c
• Actualizamos el programa cambiándole el mensaje de salida “Listo!” por “Fin!” y
guardamos.
Uray Calvo Rodríguez 22
• Compilamos el código del programa en 32 bits sin protecciones, comprobamos que esta
en 32 bits y lo ejecutamos con el argumento “uray”.
gcc name.c -o name -fno-stack-protector -m32 -g -z execstack -no-pie
file name
./name uray
18. Prueba exploit 3 de la actualización
Localizamos una nueva dirección de retorno para ejecutar el exploit en la actualización
del programa mediante los registros del entorno de depuración gdb y así, modificarlo en
nuestro exploit y ejecutarlo.
• En una nueva terminal ejecutamos los comandos necesarios
gdb -q name
Uray Calvo Rodríguez 23
break 10
run $(cat sal4)
info registers
x/32x $esp
• Debemos modificar la dirección actual del exploit “0xffffd5c0” indicada en el cuadrado
amarillo por una nueva y adecuada en medio de algún NOP slide. En este caso,
“0xffffd120” seria una buena opción indicada con el cuadrado rojo.
• La dirección de retorno deberá estar al revés estilo Little Endian quedando:
\x20\xd1\xff\xff
• Salimos del entorno de depuración gdb, copiamos el fichero “exp2” en un nuevo
fichero llamado “exp3”, y modificamos la dirección de retorno del exploit con los
comandos
quit, y
cp exp2 exp3
nano exp3
Uray Calvo Rodríguez 24
• Guardamos y ejecutamos el exploit para comprobar si sigue siendo vulnerable en el
entorno de depuración gdb con los comandos
./exp3 > sal5
gdb -q name
run $(cat sal5)
• Se demuestra como la actualización del programa sigue siendo vulnerable al exploit
de desbordamiento de pila.
• Probamos también el shellcode fuera del entorno de depuración gdb con los
comandos en una nueva terminal
./name $(cat sal5)
• El exploit provoca la salida inmediata del programa sin mostrar el mensaje de salida
“Fin!”.
Uray Calvo Rodríguez 25
19. Posible solución vulnerabilidad
Una posible solución a la vulnerabilidad del programa consiste en cambiar la función
vulnerable que provoca el desbordamiento de pila strcpy().
• La función strcpy() no verifica la longitud del búfer y puede sobrescribir la zona de
memoria contigua al destino previsto.
• Una de las formas de mitigar esta vulnerabilidad es cambiarla por la función strncpy()
que combate el desbordamiento al exigir ponerle una longitud como parámetro.
• Modificamos el programa creando un nuevo fichero llamado “name3.c”. Para esta
función, mitigaremos el exploit mediante un condicional y el cambio de la función.
• Compilamos el programa en 32 bits y probamos mediante los comandos
gcc name3.c -o name3 -m32
./name3 A
./name AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Uray Calvo Rodríguez 26