Encontrar vulnerabilidades con file format fuzzing

En este artículo vamos a ver como encontrar vulnerabilidades en aplicaciones que manejan ficheros. Vamos a ponernos en situación.

Lo primero que debemos pensar cuando fuzzeamos este tipo de aplicaciones es qué vamos a fuzzear. No es lo mismo fuzzear un fichero .zip, que un .pdf, que un .pls o un .mp3 cada uno tendrá una estructura interna distinta y por tanto un fuzzing distinto.

Recuerdo una charla de fuzzing de la NCN del año pasado en la que contaban algo sobre fuzzing y decían fuzzear? eso es meter mierdaza a las aplicaciones esperando a que peten. y eso es lo que vamos a hacer. Vamos a generar una lista de ficheros con "mierdaza" en ellos para ver como responde la aplicación cuando los abre y monitorizar el estado de la misma para encontrar un fallo que sea explotable.

Tras testear diversos maneras voy a explicar la que me ha parecido más rápida e interesante.
Lo primero que debemos hacer es descargar todo lo que necesitamos:

En primer lugar ¿como vamos a generar esos archivos y le vamos a meter la basura? La respuesta es: usaremos sulley. Alguno pensara? por que no spike? lo que queráis, el objetivo ya sabemos cual es: generar una serie de ficheros con basura dentro de ellos. Podemos descargar el ejecutable de sulley de la siguiente dirección: http://www.fuzzing.org/wp-content/Sulley%20Fuzzing%20Framework.exe.

Ahora debemos realizar un script en python para usar sulley con el que podamos generar una lista de ficheros con la basura insertada en ellos pero antes debemos pensar qué aplicación queremos fuzzear. Yo usaré un ejemplo simple como puede ser la aplicacion Easy RM to MP3 para la cual ya hay varios exploits en exploit-db (http://www.exploit-db.com/exploits/14550/):

Como vemos el crash esta en los ficheros .m3u por lo que queremos un fuzzer de ficheros m3u. Quizás un m3u es muy sencillo ya que se trata de un fichero de texto plano en que se almacena una ruta desde la que se carga una lista de música pero nos sirve para entender los conceptos

Un fichero legitimo de listas de música .m3u seria así:

Por lo que queremos ficheros que sean así pues manos a la obra¡¡

Aquí lo tenemos:

#!/usr/bin/env python
import sys      #importaciones importantes
import os
sys.path.append("C:\sulley")  #define donde tienes instalado sulley para mutaciones
from sulley import *               #importa todo lo que haya en sulley

s_initialize("M3U")  #Nombre del fuzzer

#definimos la gramatica del fuzzer
#s_string --> queremos fuzzear esto como un string
#s_static --> no queremos fuzzearlo
#s_byte --> fuzzear enteros (no hace falta) 

s_string("#EXTM3U\n")
s_static( "#EXTINF:")
s_byte(348, format="string")
s_static(",Mr. Scruff - Kalimba")
s_static("C:\Users\Public\Music\Sample Music\Kalimba.mp3") 

print "Se van a realizar: " + str(s_num_mutations()) + " mutaciones" 
i=0

while s_mutate():
    test_cases = open("m3u_test\prueba-%i.m3u"%i, "w")
    test_cases.write(s_render())
    test_cases.close()
    i = i+1
print "Finalizado"

Ejecutamos el Script en python y vemos que efectivamente se nos crean los ficheros de pruebas:

Bueno y si os dijera que tenemos que ir uno a uno probándolos en el Olly o el inmunity? Evidentemente no¡¡ Por eso nos vamos a descargar el windbg de Microsoft que además dispone de una interfaz de comandos facilmente automatizable para realizar el proceso un poco menos tedioso:

Lo podemos descargar de aquí: http://msdn.microsoft.com/en-us/windows/hardware/gg463009.aspx

Una vez que lo tenemos vamos a instalar un plugin que se llama exploitable. ¿Qué hace este plugin? Nos indica de una manera muy certera si el crash que ha encontrado es explotable tras analizarlo él por su cuenta.

Lo descargamos de: http://msecdbg.codeplex.com/, descomprimimos e instalamos en la ruta del Windbg pero en la carpeta winext copiamos la dll MSEC.dll. Con esto si accedemos al windbg y ejecutamos !load /winext msec.dll cargaremos dicho modulo. Pero además de esto el windbg tiene comandos muy utiles y que vamos a usar como:

.logopen fichero.log --> Abre un fichero en el que va a loguear todo el crash
.g --> Arranca el binario
.!exploitable -m --> Devuelve el resultado del crash en formato legible y parseable
.logclose --> cierra el fichero de log
.q --> cierra el windbg

Por supuesto tenemos más archivos pero con esto nos vale. Bueno vamos a automatizar y a encontrar el crash de una vez:

FOR /L %i in (inicio,incremento,fin) do @"[ruta de Windgb]\cdb.exe -amsec.dll -c ".logopen crash%i.log; g; !exploitable -m; .logclose" [ruta app vulnerable] [comandos_applicacion][ficheros_vuln]

Con esto arrancamos la aplicación vulnerable "atacheada" con windbg y almacenando el crash en un fichero que posteriormente veremos.
Por otro lado dejaremos otro script que vaya matando el cdb.exe (nuestro windbg) para  matar la aplicación y que se vuelva abrir de nuevo de la siguiente manera:

FOR /L %i in (0,0,0) do @wmic process where (name="cdb.exe") delete && ping -n [delay] localhost > nul

Tras observar la ayuda vemos que nuestra aplicación vulnerable carga los archivos de la siguiente manera:

RM2MP3Converter.exe /cf "C:\Documents and Settings\xxxxx\Escritorio\m3u_test\prueba-x.m3u"

Por lo que nos quedaría el siguiente comando (Nota:1186 ficheros generados por el fuzzing):

FOR /L %i in (0,1,1186) do @"C:\Archivos de programa\Debugging Tools for Windows (x86)\cdb.exe" -amsec.dll -c ".logopen crash%i.log; g; !exploitable -m; .logclose" "C:\Archivos de programa\Easy RM to MP3 Converter\RM2MP3Converter.exe" /cf "C:\Documents and Settings\xxxxx\Escritorio\m3u_test\prueba-%i.m3u"

Y nuestra función de matar el proceso cdb cada 7 segundos:

FOR /L %i in (0,0,0) do @wmic process where (name="cdb.exe") delete && ping -n 7 localhost > nul

La aplicación se va parando y arrancando automáticamente y almacenando un fichero.log del crash:

 El plugin de !exploitable nos habrá echo el trabajo ya que da tres clasificaciones según la explotabilidad del crash:

• Unknow --> Se desconoce
• no_signal_exception --> no ha dado ningun problema
• exploitable --> Explotable¡¡ :)

Podemos ahora buscar con la herramienta para windows de lineas de comandos findstr o como queramos la cadena EXPLOITABLE y obtendremos los crashes explotables:

Con esto podemos ir al fichero del mismo numero y por ejemplo realizar el proceso manualmente para verlo cojamos al azar por ejemplo el crash 133. Por lo que abrimos el olly y arrancamos nuestro easy_mp3. Cojemos el fichero explotable (el crash número 133) y lo abrimos y vemos que mete muchisimos 1.
Ahora vamos al olly lo cargamos en nuestra aplicación que previamente hemos dejado abierta con el olly y vemos que sobrescribe eip con 31313131:

Ese 31313131 es el carácter ASCII 1 en hexadecimal por tanto hemos sobrescrito EIP. Por lo que hemos detectado por fuzzing un Stack Buffer Overflow.

Mas adelante veremos  una manera de hacer esto un poquito más rápido y automatizado.

Un saludo¡