Como en la entrada anterior vimos el proceso para poder explotar un stack buffer overflow a partir de un fuzzing sobre una pequeña aplicación desarrollada para el ejemplo, en ésta entrada realizaremos la explotación de un software real llamado SLMail v5.5.0.

Para este módulo necesitaremos descargar el SLMail sobre la máquina con Windows 7 que venimos utilizando, además el ollydbg (que ya lo vimos en la entrada anterior) y copiar el siguiente script en el Kali:

Por si lo quieres descargar, se tiene el repositorio de la serie en el GITHUB del blog, que estará todos los scripts de la serie que se desarrollen ;). GITHUB SNIFERL4BS

1- El mismo pueden crearlo ejecutando nano, vi, o su editor favorito con la extensión .py.

(ej) nano pop3-fuzz.py

2- Una vez creado le damos permisos de ejecución.

chmod 755 pop3-fuzz.py

3- Instalemos ahora en el windows 7 el SLMail por defecto dándole todo aceptar y siguiente, una vez que termine nos va a pedir reiniciar, reiniciamos.

Cuando volvió a levantar el windows, vamos a inicio->todos los programas->SL Productos->SLmail Configuration y lo ejecutamos como administrador. Vamos a la pestaña Control  para verificar que esté corriendo el servicio

4- Para corroborar que tenemos el servicio del POP3 corriendo podemos realizar dos cosas.

A - Desde el cmd de windows ejecutar netstat

B - Desde el kali correr un nc a la ip y puerto (como hemos visto anteriormente)

5- Si ya estamos seguros que tenemos el SLMail corriendo y el puerto 110 abierto, levantamos el Ollydbg como administrador en el windows y nos attacheamos al proceso SLMail  file->attach

6- Una vez realizado en attach el Ollydbg mantendrá pausado el SLMail, por eso damos click en el botón superior de play y veremos como cambia el mensaje en el extremo inferior derecho de ‘Paused’ a ‘Running’.

7- Vamos al kali y ejecutamos el script anteponiendo python + nombre del archivo

8- Vamos rápidamente al windows para ver como nuestro exploit comienza a llenar de peticiones con el string ‘A’ sobre el campo PASS el SLMail hasta que desborda el buffer y termina crasheando la aplicación mostrando un ‘Access violation when executing 41414141’ sobre el EIP (extended instruction pointed)

9- Nos paramos sobre el ESP, damos click secundario y elegimos ‘Follow in Dump’ veremos la dirección de memoria donde ha desbordado el buffer.

Como siempre, cualquier duda o consulta, estamos por aquí.

Regards, @balderramaeric