#LookingForA0Day – The Turing Machine

#WelcomeLittleRabbits

Buenos días amigos de lo desconocido, lo que vengo hoy a presentar es una herramienta a medio terminar para hacer búsqueda de vulnerabilidades no conocidas, lo que se conoce como «Fuzzear».

Fuzzear consiste en enviar un montón de «entradas» pseudo aleatorias o alteradas a un programa, el cual, si contiene algún tipo de fallo en el código, provocará una excepción. Dicha excepción es el objetivo del Fuzzeo. La explotación y comprobación de explotabilidad vendrá después, pero primero hay que saber dónde mirar.

Aún recuerdo cuando mi profesor de programación me dijo «si algo existe ya, no lo hagas». Herramientas de fuzzeo hay muchas, pero la verdad, que para algunas necesitas un curso completo de cómo utilizar dicha herramienta. Ésta no pretende ser diferente, pero para mí, el curso ha sido crearla. Siempre digo que hay que saber como funcionan las cosas, y saber como funciona un fuzzer es indispensable para usarlo.

Yo soy «muy de hacerme» mis tools, ya que creo que es como en realidad se aprende, además de que siempre puedes añadir opciones que echaras en falta en otras tools que utilices. Está claro que el trabajo es mas duro que aprender algo que ya existe, pero hemos venido a aprender, no a «usar».

Por eso, mi intención con esta entrada, no es que utilicéis dicha herramienta, sino animaros precisamente a hacer lo contrario, programaros vuestras propias tools, es como mejor se aprende 🙂

Os dejo el enlace del github dónde está el código de mi máquina de Turing. Nombre en homenaje a esa gran persona, a la que debemos tanto y se le conoce tan poco.

https://github.com/shargon/TuringMachine

Deciros que quizás no soy el más indicado para publicar una herramienta con una finalidad didáctica, pues no soy de documentar el código (If it was hard to write, it should be hard to understand) una muy mala práctica que poco a poco voy abandonando.

 

#OrganizaciónDelProyecto

El proyecto de Turing Machine está ideado para realizarse en paralelo en múltiples equipos o máquinas virtuales. Consta a grandes rasgos de 3 ejecutables, cada uno encargado de una función concreta a la hora de fuzzear.

TuringMachine.exe

Es el control de mando, recibe cada una de las respuestas positivas de los agentes, y centraliza la información recibida. Es un panel sencillo e intuitivo que sólo necesita ser iniciado, añadir las configuraciones y entradas, y esperar resultados 🙂

 

 

En la parte de la izquierda añadiremos las posibles entradas que serán enviadas «alteradas» a nuestro agente. A la derecha, tenemos las configuraciones para realizar las alteraciones que serán utilizadas (todas elegidas de forma aleatoria). Mientras que en la parte inferior, obtendremos los positivos obtenidos (dignos de examinar), nos creará un archivo de mutación que cada vez que se ejecute, provocará el crash.

 

 

Los archivos recibidos del panel inferior serán el objetivo de toda la investigación, ya que pueden esconder una grave vulnerabilidad digna de estudio.

Una vez nos vayan apareciendo los resultados satisfactorios de los fallos, recibiremos unos archivos comprimidos con el siguiente contenido: el dump de memoria, el resultado de «!exploitable», las regla utilizada y la secuencia original.

 

 

Además, el propio programa te permite generar una secuencia acorde al patrón elegido, para poder replicar el ataque desde la línea de comandos.

 

TuringMachine.Agent.exe

Dicho ejecutable es el propio programa que realizará la acción del fuzzeo, es el que colocaremos en la máquina virtual (o en múltiples máquinas virtuales) e irá conectado al central. Se encargará de ir proporcionando los resultados, de forma que no tengamos que estar pendientes de cada uno de los nodos de fuzzeo.

 

 

Configurarlo es quizá lo mas abstracto de todo el proyecto (lo sé). Es necesario pasar por parámetros: la librería (dll) que contiene la lógica de la ejecución, el nombre de la clase que se instanciará de dicha librería, la dirección del servidor, el número de tareas simultáneas y segundos para reintentar conectar con el servidor.

Los parámetros obligatorios que deberán ser definidos a la hora de ejecutar el proceso del agente son los siguientes:

// Servidor de TuringServer a utilizar
Server=127.0.0.1,7777

// Número de segundos para cada reintento de conexión al servidor o si algo sale mal (por defecto 5)
RetrySeconds=5

// Número de tareas en paralelo (por defecto 1)
NumTasks=10

// Ruta de la librería con la lógica
AgentLibrary=MiLibreria.dll

// Nombre del objeto a instanciar de dicha librería
AgentClassName=NombreDeMiClase

// Archivo Json para deserializar el objeto de la librería y así poder configurarlo de manera externa
AgentArguments=RutaDeConfiguracion.json

Y en el caso del archivo json, un ejemplo para el vulnserver (lo veremos más adelante) sería el siguiente:

{
 "Process":
 {
   "FileName": "D:/Fuzzing/vulnserver/vulnserver.exe",
   "Arguments": "9{Task000}"
 },
 "ConnectTo": "127.0.0.1,9{Task000}"
}

Podemos ver la ruta del ejecutable, los argumentos del mismo y la dirección dónde se conectará para realizar el envío. Si os fijáis en el comodín {Task000}, este comodín será remplazado en tiempo de ejecución de cada tarea, por el número de tarea, para poder así ejecutar en paralelo 10 o 20 procesos, y que no fallen por la apertura del socket (listener).

 

TuringMachine.Generator.exe

Es el encargado de generar las configuraciones de alteración de las secuencias de entrada, sirve para crear los patrones a utilizar.

#CreandoPatronesDeAlteración

 

Quizá la parte más importante a la hora de disponerse a realizar cualquier tipo de fuzzeo, es configurar de forma adecuada cada regla a utilizar. De ésta y no de otra parte, depende el éxito o fracaso del tiempo empleado. Como bien decía Abraham Lincoln «si me dieran seis horas para cortar un árbol, emplearía las cuatro primeras para afilar el hacha».

Como bien decíamos, fuzzear consiste en modificar una entrada. Entendemos por entrada cualquier tipo de información que recibe una aplicación, ya sea un argumento desde la línea de comandos, datos por un socket (tcp/udp …), una imagen … ¿Y que le hacemos a dicha entrada?

Bien, pues hay que modificarla, y a la hora de modificarla existen generalmente los siguientes tipos de mutaciones:

TuringMachine de momento contempla el Mutacional y el Random. Aunque está pensado realizarse un ModelBased en un futuro (que es bastante mas complejo y el que mejores frutos suele dar). Os recomiendo ver los vídeos de Charlie Miller «https://www.youtube.com/watch?v=Xnwodi2CBws» si estáis interesados en el mundo del fuzzeo.

La parte centrada en la realización de patrones de alteración reside en «https://github.com/shargon/TuringMachine/tree/master/TuringMachine.Generator» cuyo ejecutable es «TuringMachine.Generator.exe»

Al abrir la aplicación, podemos configurar una alteración mutacional de cualquier tipo de entrada.

 

 

Grosso modo, una configuración (o patrón) tiene un número de mutaciones, y una mutación un número de cambios.

En la parte «1» de la imagen superior podemos observar el nombre del patrón que estamos creando, de tipo (Mutacional). Si pinchamos en las mutaciones, se nos abrirá la parte número «2» de la imagen.

En esta lista podemos añadir una serie de mutaciones dónde configuramos aspectos como: el % de probabilidad (en este caso de 0 a 4%), el tipo de % (si es por cada byte o general a la entrada), máximo números de repeticiones para dicho cambio, así como desde que offset se puede activar dicho cambio a lo largo de la entrada recibida (siempre a nivel de byte).

Cada mutación tiene una serie de cambios posibles que serán seleccionados de manera aleatoria, siempre acorde al peso (Weight) de cada uno. En este caso, podemos ver que dentro de dicha mutación se encuentra la posibilidad de hacer 3 cambios. Podemos ver también que uno de esos cambios, es la alteración de un byte por otro cualquiera.

 

 

También se podría hacer un testeo de buffer overflow, añadiendo bytes desde el valor decimal 32 a 126 (0x20-0x7E), con un tamaño desde 10 a 10K bytes (eliminando el byte en curso).

 

 

La última opción de dicha mutación se trata de una comprobación de un integer overflow: eliminamos 4 u 8 bytes y añadimos de 4 a 8 bytes 0xFF.

Una vez guardada la configuración, se creará un archivo «fmut» que será el utilizado como patrón de alteraciones para cualquier tipo de entrada. Podéis ver el archivo resultante en la dirección: https://github.com/shargon/TuringMachine/blob/master/Samples/Configs/IOF%20-%20BOF%20-%20SWITCH.fmut

 

#DemoTime

Uno de los mejores ejemplos que conozco para empezar a fuzzear o con la explotación, es el vulnserver.

Se trata de una aplicación vulnerable creada únicamente para el estudio y el aprendizaje, el enlace original es http://www.thegreycorner.com/2010/12/introducing-vulnserver.html , pero por si algún día lo quitan he replicado el contenido del mismo en el propio proyecto de Github en https://github.com/shargon/TuringMachine/tree/master/Samples/Vulnserver . Dicha carpeta contiene además las configuraciones y entradas que usaremos en el ejemplo de uso.

Cómo muchas veces se aprende más rápido con un vídeo, he decidido grabar uno para poder ver exactamente el funcionamiento del proceso de fuzzeo con TuringMaching. ¡Espero que os guste!

 

 

Recordad que fuzzear no consiste en explotar, como mucho valorar la «explotabilidad» del fallo, ya que la explotación sería otro proceso que no está contemplado en esta entrada. Cabe decir que TuringMachine combina el !exploitable de Microsoft, un plugin del WinDbg para valorar como de explotable puede ser una excepción. Aunque honestamente funciona un poco «allá que te va» ya que muchas veces dará falsos positivos. Pero se pone uno tan contento cuando aparece una línea 🙂 que eso no tiene precio jaja

 

#CasosDeÉxito

He de decir (y no es por presumir), que la primera vez que puse a probar en un entorno real, los resultados de las horas de esfuerzo empleadas para el desarrollo de esta aplicación, fue con MySql.

Desconocía los tiempos e intentos que se tenía que hacer en estos casos, soy nuevo en el tema. Pero en tan sólo 2 horas apareció un fallo explotable (según !exploitable) y se está gestionando un posible CVE. Aún falta la parte de la explotación, que posiblemente (si se confirma su explotabilidad por gente mas experta en este sector) resulte en otra entrada de este blog 🙂

Ésta tarea se la he delegado a DiaLluvioso por ser una persona sabia en el tema, humilde y un gran maestro.

 

El fallo encontrado reside en la suit de MySql  5.6 y 5.7, (pero no en la 5.5), fué comunicado al departamento de seguridad de oracle y están siguiendo el problema.

 

Espero que os haya servido de utilidad la herramienta, el código, la entrada, o el tiempo empleado para leerla, siendo cualquiera de estos un SÍ, será suficiente para sentirme contento 🙂 ¡DISFRUTAD DE LAS VACACIONES!