Solución Wargame Buffer Overflow

Mirando un foro llamado Underc0de, específicamente la sección ‘Wargames y retos’ me percaté de un reto que me llamó bastante la atención, este fue publicado el año 2012 y posee tan solo dos ganadores.

El reto consiste en explotar una aplicación, lo cual es la capacidad de poder hacer que un programa vulnerable realice una acción que no estaba prevista.

Manos a la obra

Tras descomprimir el archivo RetoExploit.rar, visualizamos los siguientes archivos:

Si ejecutamos Reto.exe se visualiza el contenido de config.txt:

Por lo cual la finalidad de este programa es mostrar por consola el contenido del archivo config.txt.

¿Cómo funciona el programa?

Una rápida mirada a través de IDA nos muestra la función _main del programa:

Como es posible observar el programa abre el archivo config.txt por medio de la función:

fopen(‘config.txt’, ‘r’);

Posteriormente obtiene su contenido:

fgets(buff_fgets, sizeof(buff_fgets), ptr_file);

Y finalmente copia el contenido en un nuevo buffer:

strcpy(buff_archivo, buff_fgets);

La aplicación es susceptible a un buffer overflow debido a la función strcpy, la cual no posee un control del tamaño de la string que es copiada.

Cargamos la aplicación dentro de Immunity Debugger y con el script mona, verificamos las características del ejecutable por medio del comando:

!mona mod

Podemos ver que no posee ningún mecanismo de protección, pero a modo de demostración utilizaremos ROP Gadgets para evitar la protección de windows DEP.

A través de mona creamos un un pattern de 1000 caracteres:

Creamos el exploit por medio de un script en Python:

Ejecutamos Reto.exe desde el debugger y observamos que se produce una excepción:

Corroboramos con mona el desplazamiento necesario para la sobre-escritura de la estructura EXCEPTION_REGISTRATION_RECORD:

Por lo cual ya podemos crear la estructura base del payload:

[Junk][nSEH][SEH][NOPs][Shellcode]

Ahora queda buscar ROP Gadgets que logren redireccionar el flujo del programa (PC) desde SEH a nSEH y que estos no se encuentren contenidos en ejecutables, módulos o dll’s que tengan SafeSEH habilitado:

Dado que no se encontró ningún ROP Gadget en mi sistema, cambiaré de tipo de exploit BoF SEH a un BoF normal, pero antes por medio del argumento pattern_create de mona y el código generado por IDA hay que buscar el tamaño máximo de caracteres permitidos por el programa antes que se convierta en un BoF SEH.

Tras un par de comprobaciones descubrimos que el tamaño máximo caracteres son 175. Por lo cual tenemos un cantidad reducida de bytes para poder demostrar por medio de un PoC que la aplicación es vulnerable y al mismo tiempo lidiar con la protección DEP del sistema operativo.

Prueba de concepto (PoC)

El siguiente script crea una cadena de ROP Gadgets que ejecutan por medio de la API WinExec la calculadora de Windows:

No tan solo podemos limitarnos a la ejecución de una calculadora, si no que también podemos iniciar CMD:

Conclusión

Como conclusión podemos observar un sencillo reto de buffer overflow que pone a prueba la capacidad de ejecutar código arbitrario dentro de una aplicación con un buffer reducido de bytes. La aplicación de este tipo de vulnerabilidades en la vida real no tienen como finalidad la ejecución de una calculadora o una consola, si no que mas bien la ejecución de un potente payload como por ejemplo Meterpreter de Mestaploit, el cual podría poner en completo riesgo al sistema afectado.

Compartir

Agregar un comentario

Pwned Chile