David Fernández Madrid - sidertia.com · David Fernández Madrid Estrategias de fuzzing inteligente con Peach Fuzzer Consolidación de blogs escritos por el autor entre el 31 agosto

David Fernández Madrid

Estrategias de fuzzing inteligente con Peach Fuzzer

Consolidación de blogs escritos por el autor entre el 31 agosto y 23 septiembre de 2015

C/ del Aguacate 41, Bloque 3, PL-0 28054 Madrid. España Telf: (+34) 914.006.447 web: www.sidertia.com | email: [email protected]

Estrategias de fuzzing inteligente con Peach Fuzzer. David Fernández Madrid

1

Indice

Prólogo ............................................................................. 2

Capítulo 1 – ¿Que es y que no es el fuzzing?....................... 3

Capítulo 2 – Creación de un fuzzer ..................................... 9

Capítulo 3 – Modelado de Estados y Mutadores .............. 19

Capítulo 4 – Extensión del Core y creación de Tests ......... 25

Capítulo 5 – Conclusión ................................................... 30

http://www.sidertia.com/

mailto:[email protected]



2

Prólogo

Desde hace unos años, la aplicación de técnicas de fuzzing para la evaluación de riesgos de

seguridad ha pasado de ser coto exclusivo de empresas especializadas en auditoría a ser técnicas

ampliamente utilizadas por los propios desarrolladores de aplicaciones y soluciones. Así,

entidades como Microsoft y Google, realizan habitualmente dichas prácticas dentro de su ciclo

de desarrollo seguro de aplicaciones para tomar una posición proactiva en la identificación de

vulnerabilidades expuestas por sus productos o por los productos de terceros que utilizan.

En Sidertia utilizamos habitualmente diversas técnicas y herramientas de fuzzing durante la

realización de auditorías de seguridad y test de penetración, como complemento al análisis

manual en busca de vulnerabilidades y elementos que puedan suponer un riesgo para la

seguridad de los sistemas auditados.

Cuando el objetivo es auditar una aplicación web, herramientas como Burp Suite o CAT pueden

ser utilizadas en combinación con listas de palabras para descubrir ficheros o endpoints ocultos,

archivos de backup, enumerar usuarios u otros recursos de forma sencilla. Sin embargo, cuando

el objetivo es auditar la implementación de un protocolo o de un parser de archivos, es necesario

utilizar otras técnicas más avanzadas y complejas. Es lo que veremos en esta serie de artículos,

donde explicaremos el uso de Peach Fuzzer y como extenderlo, siendo éste nuestro framework

preferido para este tipo de pruebas, así como diversas técnicas orientadas a potenciar los

resultados y la efectividad de nuestras sesiones de fuzzing.






3

Capítulo 1 – ¿Qué es y que no es el fuzzing?

El fuzzing es una forma semi-automatizada de evaluar riesgos y vulnerabilidades, tanto ya

conocidas como 0day, y que consiste en la generación o mutación de un gran número de

entradas para ser consumidas por un sistema que procese dicha información. Es habitual el

realizar auditorías contra sistemas sin conocer a ciencia cierta su versión y/o nivel de parcheo y

no siempre es posible aplicar técnicas de fingerprinting para poder conocerla con seguridad.

Aunque así sea, herramientas como Nessus sólo son parcialmente efectivas y en cualquier caso lo

serán para la identificación de vulnerabilidades ya conocidas.

Mediante un fuzzing a una aplicación podemos dar respuesta a las siguientes preguntas:

¿Qué vulnerabilidades desconocidas (0day) pueden afectar a mi aplicación?

¿Con mi nivel actual de actualizaciones, puedo estar afectado por vulnerabilidades graves de

ejecución de código remota que supongan un compromiso total del sistema?

¿Con mi nivel actual de actualizaciones, puedo estar afectado por vulnerabilidades que

afecten a la disponibilidad del mismo?

¿Las actualizaciones de seguridad instaladas efectivamente protegen de las vulnerabilidades

que supuestamente corrigen?

¿Ha existido alguna regresión que pueda suponer un riesgo para la seguridad debido a la

instalación de alguna actualización u componente de terceros?

El fuzzing, al contrario de lo que muchos piensan, no es una herramienta automática de apunta y

dispara. Será necesario utilizar un framework de fuzzing flexible que nos permita implementar

tanto el protocolo a auditar como los diferentes tests a realizar para la búsqueda de

vulnerabilidades. Esto sólo será posible tras el estudio minucioso del protocolo y su

funcionamiento, para conocer detalles de su implementación y las posibles áreas donde sea más

probable encontrar vulnerabilidades.

Tampoco es una técnica que pueda sustituir al viejo arte del hacking manual para la realización

de auditorías o pentesting. Aunque pueden ser efectivas para la identificación de

vulnerabilidades en aplicaciones Web con fuzzers poco invasivos, donde es más útil es en la

identificación de vulnerabilidades que provoquen un efecto fácilmente medible sobre el servidor

(reinicio, cierre, consumo excesivo de memoria, lanzamiento de excepciones, etc.) y que

requieran un gran número de pruebas para su localización, por lo que su aplicación sobre

sistemas en producción se verá limitada a aquellos que puedan aceptar una suspensión temporal

del servicio.

Finalmente, no se pueden obtener garantías de encontrar resultados. Compañías especializadas,

investigadores independientes y hasta los propios desarrolladores a menudo utilizan técnicas de

fuzzing para encontrar vulnerabilidades que después son corregidas. El conseguirlo dependerá

más que de la minuciosidad a la hora de implementar el protocolo, de nuestra intuición sobre las

áreas a auditar y sobre todo sobre de los tipos de test a realizar y como realizarlos.





4

1.1 - ELEMENTOS DE UN FUZZER EFECTIVO

Un buen fuzzer debe contener los siguientes elementos o características:

Conseguir una buena cobertura de código (code coverage): los test a realizar deben estar orientados

a cubrir/auditar la mayor parte posible de código de la implementación, o por lo menos aquellas que

se consideren objetivo prioritario.

Conseguir los objetivos del fuzzing en un tiempo finito: de nada sirve mandar peticiones o respuesta

ininteligibles con la esperanza de provocar un comportamiento anormal en la otra parte. Se deben

minimizar los tests con nula o poca posibilidad de llegar a la funcionalidad que tienen como objetivo.

Combinar tests mutacionales y generacionales: los fuzzers mutacionales mutan/cambian una entrada

que suministremos a nuestro fuzzer, mientras que los generacionales crean/generan cada una de las

iteraciones de los tests a realizar a partir de un modelo o de unas reglas. Para lograr una mayor

efectividad, la mayor cobertura de código posible y tener un mayor control sobre que partes del

protocolo que vamos a someter a fuzzing, será necesario un fuzzer que combine ambos tipos de tests.

Permitir la implementación de estados: en determinados protocolos orientados a conexión, será

necesario la implementación de una máquina de estados que cambie los datos a generar por el fuzzer

en base a determinadas condiciones (Key Exchange, autenticaciones en varios pasos, etc).

Los resultados del fuzzer deben ser medibles y reproducibles: debido a que un fuzzer puede realizar

cientos de miles de peticiones, será necesario disponer de la funcionalidad de identificar y/o clasificar

los tests que han tenido éxito y poder reproducir exactamente la iteración del test de nuestro interés.

Debe ser extensible y reutilizable: un fuzzer debe poder extender las funcionalidades que implementa

y poder reutilizarlas para futuras sesiones u objetivos. Por otra parte, también debe permitir su

aplicación para diferentes productos que realicen implementaciones de un mismo protocolo, que

pueden verse afectadas por diferencias incluso aunque el protocolo sea un estándar.

1.2 - PEACH FUZZER

Uno de los frameworks para construir fuzzers más conocidos y flexibles es Peach Fuzzer, de la compañía

DejaVu Security. Aunque no es el único, es el preferido por nuestro equipo e implementa todas las

características deseables en un buen fuzzer vistas anteriormente:

Desarrollado en .NET con soporte adicional para módulos en Python o Ruby. Disponible para Linux,

OS/X y Windows.

Modelado XML: requiere el modelado de los datos del protocolo o formato de archivo en formato

XML.

Máquina de estados: permite definir diferentes estados en nuestro fuzzer que pueden ser

seleccionados en base a determinadas condiciones.

Posibilidad de evaluar la cobertura de código de las entradas a utilizar para el fuzzer y seleccionar un

set óptimo de las mismas.

Permite utilizar datos reales (ejemplos de tráfico o archivos reales, etc.), aplicar los datos al modelo

para después crear las diferentes iteraciones según como las hayamos modelado. Es por tanto

mutacional y generacional a la vez.



http://www.dejavusecurity.com/



5

Incluye numerosos mutadores útiles, que realizarán acciones sobre los elementos definidos en el

modelo o sustituirán su valor por datos que pueden provocar un comportamiento anómalo.

Dispone de diferentes publicadores, las entidades encargadas de enviar y recibir datos desde y hacia el

fuzzer, con soporte para diferentes protocolos. Permite también la generación de archivos y

lanzamiento de un programa para su parseo para realizar fuzzing de parsers de formato de archivo.

Por medio de agentes, locales y remotos, y monitores, permite comprobar el resultado de cada

iteración identificando crashes en el programa, consumos de memoria excesivos u otras condiciones

que marquemos como causantes de fallo.

Se puede dividir una sesión de fuzzing entre varias máquinas de forma sencilla para realizar un fuzzing

distribuido y acortar el tiempo de realización.

Fácil de extender: para crear un nuevo elemento del fuzzer bastará con crear una dll y colocarla en la

raíz de la carpeta de Peach. Al utilizarlo en nuestro XML, Peach lo cargará por reflexión.

A parte de todo esto, algo que para nosotros es imprescindible es que Peach Fuzzer se lanza en dos

versiones, una Professional y otra Community, donde se encuentra disponible el código fuente, necesario

como veremos si deseamos ejecutar modificaciones más profundas en el propio core de la aplicación.

En este artículo veremos cómo planificar, optimizar y ejecutar un fuzzer con la versión Community de

Peach Fuzzer sobre el protocolo HTTP. Aunque existe una documentación sobre el producto, ésta a

menudo es incompleta, desfasada o corta en explicaciones, siendo necesario mirar el código fuente de la

aplicación para poder entender mejor el producto. En este artículo no se describirán todos los elementos

del framework, tan sólo algunos de los más importantes y aquellos que se considera merecen una

explicación más extensa que la que aparece en la documentación oficial.

1.3 - PLANIFICACIÓN DEL FUZZER

Indispensable a la hora de desarrollar nuestro fuzzer es estudiar en detalle el protocolo a auditar, lo que

permitirá identificar posibles áreas en las que hacer más énfasis y por tanto ayudará a planificar los

objetivos del fuzzer. Para modelar con éxito el protocolo HTTP, sujeto de este fuzzer en particular,

deberemos por lo tanto conocer su sintaxis, reglas y actores y para ello no hay mejor fuente que las RFC

que describen el protocolo.

A la hora de estudiar un protocolo a auditar, prestaremos especial atención a determinados elementos

como los siguientes, que nos permitirán diseñar datos a generar por nuestro fuzzer que pueden provocar

una respuesta anormal del sujeto a auditar:

1. Identificar los tipos de datos o caracteres permitidos en campos determinados, ya que valores en dichos

campos con caracteres no permitidos puede generar excepciones.

2. Identificar campos que definan la longitud de otro y su tamaño, ya que habrá que comprobar la respuesta

del sujeto ante valores inválidos (negativos, menores que la longitud real del campo, etc).

3. Longitudes máximas definidas para los campos: el conocer los máximos de un campo nos dará una idea

de que límites deberemos buscar y nos permitirá reducir el número de iteraciones de nuestro fuzzer.

4. En sucesiones de elementos, conocer sus límites máximos y/o mínimos: realizar variaciones en el tamaño

de un array es algo que podremos hacer fácilmente con nuestro fuzzer.



http://sourceforge.net/projects/peachfuzz/

http://sourceforge.net/p/peachfuzz/code/ci/master/tree/

http://community.peachfuzzer.com/v3/PeachPit.html

http://www.w3.org/Protocols/



6

5. Identificar series de elementos que deban ser re-ensamblados en un orden determinado.

6. Buscar ejemplos de implementaciones de funcionalidades e intentar identificar posibles ataques contra

las mismas, ya que es posible que las implementaciones reales sean semejantes o iguales a dichos

ejemplos.

7. Identificar campos cuyos valores vayan a ser sometidos a una transformación antes de ser generados

como salida, ya que será necesario testear los diferentes pasos del proceso con datos anormales.

8. Identificar los posibles estados definidos por el protocolo, ya que será necesario auditar un flujo anormal

de estados diferente del esperado por la aplicación.

En el caso del protocolo HTTP, se trata de un protocolo no orientado a conexión, por lo que no es de

aplicación el punto 8 de los anteriores. Se trata también de un protocolo basado en texto donde los

campos no se delimitan por una longitud máxima o fija, si no que se delimitan por tokens como en el

siguiente ejemplo, que define las cabeceras HTTP con los dos puntos, tabuladores, espacios y retorno de

carro como tokens:

field-name:(Tab/SP)field-content(CLRF)

Por lo tanto, no encontraremos ejemplos relativos al punto 3, aunque si encontraremos varios ejemplos

del punto 2, por ejemplo el valor de la cabecera Content-Length. A parte de éste, también podemos

encontrar otros ejemplos como chunk-size, valor que define el tamaño de un chunk utilizado en la

codificación de transferencia chunked encoding utilizada en las peticiones o respuestas HTTP orientadas a

streaming:

En cuanto al punto 1, el protocolo permite la inserción de caracteres dígito en cualquier campo que defina

una longitud como los anteriores o en el valor de la cabecera Range, que define un rango o rangos de

bytes solicitados al servidor de un recurso en particular:





7

Por lo tanto, será interesante la generación de valores anómalos en dichos campos para comprobar la

respuesta del servidor, ya que al ser cadenas que deben ser convertidas a números por la aplicación,

pueden provocar excepciones. En cambio, con la excepción de tabuladores y retornos de carro,

prácticamente cualquier carácter está permitido como valor de un campo cabecera HTTP, por lo que más

allá de caracteres de control probablemente no será prioritario el probar variantes de cadenas mal

formadas en dichos valores.

Como ejemplos de los puntos 5 y 6, tenemos la codificación de transferencia chunked y el tipo de

contenido (Content-Type) multipart, donde una serie de fragmentos delimitados por una longitud o por

un límite (boundary) deberán ser ensamblados por el servidor o por los sistemas intermedios en la

comunicación HTTP (proxies, reverse proxies, sistemas IDS/IPS, etc.) antes de procesar su contenido, por

lo que deben ser objetivo de nuestro fuzzer.

Como vemos en el estándar, se definen diversas reglas o recomendaciones para sistemas intermedios en

relación al procesamiento que deben hacer de las peticiones o respuestas HTTP. Así, por ejemplo, en el

estándar se permiten una serie indefinida de cabeceras HTTP con el mismo nombre y diferentes valores,

que deberán ser ensambladas como una lista de valores en una única cabecera por sistemas intermedios.

En las propias RFC podemos encontrar un ejemplo del punto 6, donde se explica en pseudo-código una

implementación del procesamiento de los chunks de una codificación chunked:





8

Merecerá la pena comprobar el comportamiento del procesamiento de chunks si el valor de chunk-size es

anómalo como nulo, 0.1, valores negativos que puedan desbordar la variable o valores grandes de chunk-

data sin un CLRF y cabecera Last-Chunk que lo delimite.

Aparte de todo lo anterior y con el objetivo de identificar vulnerabilidades desconocidas y no parcheadas

(0day), pueden ser interesantes las siguientes recomendaciones específicas:

Auditar funcionalidades nuevas o de reciente aparición, ya que hay menos probabilidad de que ya

hayan sido testeadas.

Auditar funcionalidades poco conocidas y/o usadas u obsoletas, por la misma razón.

Comprobar el historial de vulnerabilidades descubiertas para productos similares en el mercado, ya

que es posible que afecten también al producto sujeto del estudio.

En relación al último punto, podemos encontrar que en los últimos años se han publicado numerosas

vulnerabilidades relativas al procesamiento de chunks y de peticiones con Content-Type Multipart en

Nginx, Apache y Apache Tomcat. También IIS ha sufrido de vulnerabilidades relacionadas con valores

anómalos de cabeceras, por lo que tras el análisis y comprobar dichos historiales, esas funcionalidades

parecen un buen objetivo a testear con nuestro fuzzer. Para ello, seleccionaremos diferentes peticiones

HTTP que utilicen dichas funcionalidades para que nuestro fuzzer las tome de ejemplo y genere o mute a

partir de ellas cada una de las iteraciones que las testearán y que podremos utilizar para hacer fuzzing

contra servidores HTTP o sistemas intermedios como los comentados.





9

Capítulo 2 – Creacion de un fuzzer

En este segundo artículo de la serie Estrategias de fuzzing inteligente con Peach Fuzzer veremos como

modelar los diferentes mensajes que puede intercambiar un protocolo. Para ello, definiremos un archivo

xml que contenga el esquema de los datos y que podremos usar para generar cada iteración del fuzzer y

para cargar datos en el modelo.

2.1 - ARCHIVOS PIT

Peach fuzzer utiliza unos archivos xml según un esquema propio para la definición de los diferentes

elementos de nuestro de fuzzer. Dichos archivos se llaman archivos pit y tienen la siguiente estructura:

Dentro del nodo raíz Peach, podemos definir módulos en Python a utilizar con el elemento Import o

definir valores por defecto para los atributos en la sección Defaults. Como vemos en la imagen, mediante

el elemento Include podemos importar otros archivos pit a los que podemos hacer referencia con un

prefijo definido por el atributo ns. De esa forma, podemos definir en otros archivos diferentes elementos



http://www.sidertia.com/Home/Community/Blog/2015/08/31/Estrategias-de-fuzzing-inteligente-con-Peach-Fuzzer-I



10

(DataModel, StateModel, etc.) que luego podremos utilizar en el principal haciendo referencia a ellos con

el atributo ref.

Podemos definir uno o más modelos de estado (StateModel), contenedores que agrupan un determinado

conjunto de estados (State), teniendo cada uno acciones que realizará nuestro fuzzer (enviar un tipo

determinado de petición, recibir la respuesta, etc.) en ese estado en concreto (no autenticado,

autenticado, etc.)

Tras la definición de los diferentes modelos, en el archivo pit se define uno o varios tests (Test), que

agrupan un modelo de estados, elementos a mutar o no (Exclude y Include), mutadores a utilizar

(Mutators), la estregia a utilizar (Strategy) y el tipo de publicador y logger a utilizar durante nuestra

sesión.

2.2 - ARGUMENTOS DE LA LÍNEA DE COMANDOS DE PEACH

Para ejecutar Peach, deberemos hacerlo especificando un archivo pit con las definiciones de los

diferentes elementos del fuzzer:





11

Algunas opciones de la línea de comandos que podemos utilizar con Peach son las siguientes:

--range [N,]M ejecutar las iteraciones del fuzzer desde N hasta M

--skipto N comenzar la sesión en la iteración N

-c cuenta las iteraciones que realizará el fuzzer

-a CANAL inicia un agente remoto en la máquina con el canal especificado (tcp, upd, etc.)

-p T,N realiza un fuzzer distribuido entre varias máquinas, siendo T el número total de máquinas y N el

número de máquina actual

Si nuestro archivo pit define diferentes tests al de nombre Default, podemos especificar el nombre del

test a ejecutar:

Peach fuzzer incluye varias utilidades de línea de comandos, entre ellas, peachminset, que nos permite,

dados un set de entradas a suministrar a nuestro fuzzer, seleccionar el conjunto óptimo de ellas a utilizar

para lograr una mayor cobertura de código de la aplicación especificada:





12

2.3 - MODELADO DE DATOS

Para definir la estructura de las diferentes peticiones y respuestas de la comunicación de un protocolo (o

de un formato de archivo), definiremos un modelo de datos (DataModel) en formato xml, donde

podremos especificar los elementos, tipos de datos, longitud y valores de los mismos, relaciones entre

ellos e información para los mutadores de Peach:

Tanto el elemento DataModel como el elemento Block, son contenedores de otros elementos, la

diferencia es que Block puede hacer referencia a un DataModel a usar como plantilla mediante su

atributo ref. Así, en la imagen anterior, vemos que el bloque Headers hace referencia a un DataModel

llamado Header-Field-Tpl que usa como plantilla:

De esa forma podemos usar un mismo DataModel como plantilla para modelar diferentes campos, no

sólo referenciándolos, sino también cambiando los elementos que lo componen. Los dos DataModel

anteriores pueden representar a cabeceras HTTP de la forma:

Header-Field: Header-Value

Pero si queremos usar el DataModel Header-Field-Tpl como plantilla, también podemos cambiar sus

elementos, incluso de tipo, con tan sólo referenciarlos por el mismo nombre:





13

Para la cabecera Range, usamos el mismo DataModel como plantilla, pero cambiamos el elemento Field-

Content de String a un Block con diferentes elementos como hijos. El resultado será que ese elemento

representa a una cabecera como la siguiente:

Range: bytes=10-20

2.4 - RELACIONES Y TRANSFORMACIONES

A parte de DataModel y Block, el esquema de Peach nos permite utilizar otros elementos como String,

Number, Flags, XmlElement, Choice, etc, que nos permitirán representar diferentes campos

correspondientes a entidades del protocolo o formato de archivo en cuestión. Pero no sólo podemos

representar elementos, sino también relaciones entre ellos, como offset, cuenta o tamaño de otro

elemento:

Al elemento Chunk-Size le hemos añadido una etiqueta Relation hija que define que el valor de dicho

campo será el cálculo del elemento Chunk-Data.

Para aplicar transformaciones a los datos, podemos añadir de igual manera etiquetas Fixup y

Transformer, que podemos utilizar para realizar conversiones de los datos o aplicarles funciones de

compresión, criptográficas o de hash:



http://community.peachfuzzer.com/v3/DataModeling.html

http://community.peachfuzzer.com/v3/Relation.html

http://community.peachfuzzer.com/v3/Fixup.html

http://community.peachfuzzer.com/v3/Transformer.html



14

Por ejemplo, el Fixup CopyValue, se encarga de copiar al elemento el valor de otro, en el caso de

Boundary-Suffix, copiará el valor definido como Header-Boundary-Suffix en la cabecera Content-Type, de

esa forma nos aseguraremos que ese valor sea el mismo al mutar los datos.

Con todos estos elementos, definiremos los diferentes mensajes intercambiados por nuestro protocolo

con un nivel de detalle a nuestra elección. A mayor detalle, más complejo será el modelo, pero a cambio

ganaremos más control sobre los datos que generará el fuzzer y la forma en la que deben mutar. Dado

que nuestro fuzzer está orientado a servidores HTTP, modelaremos nuestras respuestas con menos

detalle, tanto porque sólo nos puede interesar comprobar el estatus con el que contesta el servidor como

por evitar errores de parseo, ya que cada servidor responde de forma diferente, en particular en lo

relativo a los retornos de carro que rodean al contenido:

Nuestras peticiones HTTP en cambio las representaremos con un mayor nivel de detalle, ya que haremos

unos tests específicos según la cabecera y también según el tipo de contenido de la misma (chunked,

multipart, etc):





15

2.5 - ATRIBUTOS DE LOS ELEMENTOS

Algunos atributos que se pueden aplicar a todos los elementos son length, minOccurs, maxOccurs, occurs

y mutable. Con length definiremos la longitud del campo, siendo obligatorio para los elementos de tipo

Number y con minOccurs y/o maxOccurs convertiremos a nuestro elemento en un array de elementos. Si

incluimos el atributo minOccurs con el valor cero, estaremos haciendo nuestro elemento opcional. Con el

atributo mutable, cuyo valor por defecto es true, podemos hacer que no se apliquen mutaciones a dicho

elemento.

Para los elementos que no son contenedores como String o Number, podemos aplicar atributos como

value, que establece un valor por defecto para el elemento y token, que marca el elemento como token y

como veremos tiene mucha importancia en el cracking de datos en el modelo:





16

2.6 - CRACKING

El cracking de datos en un modelo es como los desarrolladores de Peach llaman a la asignación o parseo

de datos en los campos/elementos correspondientes de un modelo determinado. Ocurre el cracking de

datos cuando cargamos datos en un modelo utilizando la etiqueta Data:

De ese modo, se sustituirán los valores por defecto definidos en el elemento Request por los valores

especificados en los elementos Field. También podemos cargar datos en un modelo a partir de un archivo

o archivos con una petición HTTP que deseemos usar como fuente de datos:

Si la estrategia de fuzzing elegida en nuestra etiqueta Test es Random, podremos utilizar varios archivos

especificando el nombre de un directorio o comodines como *:

También ocurrirá un crackeo cuando Peach procese la respuesta del servidor e intenté asimilar los datos

en el modelo definido por nosotros como respuesta:

El proceso de crackeo de Peach es complejo y conviene entenderlo y depurarlo para asegurarnos de que

nuestros datos son consumidos correctamente por el modelo elegido, ya que si ocurre un error nuestro

fuzzer dará un error y se parará. Para que los datos sean consumidos correctamente, Peach tiene que

haber sido capaz de asignar todos ellos a los elementos definidos en el modelo y no quedar ningún

elemento obligatorio (sin minOccurs=”0”) sin valor asignado. Para ello, Peach por cada contenedor leerá

las longitudes de los elementos si existen y guardará los elementos marcados como token y su valor. Con

esas longitudes y delimitadores, intentará ir procesando elemento a elemento secuencialmente y





17

asignándole datos. Si es incapaz y el elemento es opcional, pasará al siguiente elemento, si es capaz,

pasará a asignar los siguientes datos en el buffer. Este proceso lo podemos depurar ejecutando Peach con

las opciones --debug y --trace:

Para los elementos marcados como token, comprobará el valor definido en su atributo value ya que lo

hemos marcado como un elemento que debe aparecer tal cual. Si hemos definido algún elemento como

un array (con minOccurs y/o maxOccurs), Peach intentará crackear datos en el elemento hasta

maxOccurs ocurrencias o hasta que el cracking falle, momento en el que pasará al siguiente elemento.

Debido a la naturaleza de HTTP, los tokens tendrán mucha importancia en nuestro fuzzer, ya que

prácticamente es la única manera que tendrá Peach de delimitar los campos al no tener la mayoría de

estos longitudes especificadas. Algo útil para evitar errores en el crackeo, sobre todo cuando utilizamos

modelos genéricos es utilizar constraint en los campos:

Mediante una expresión en Python que se evalue a true o false, podemos evitar que los datos sean

consumidos y hacer fallar el crackeo para ese elemento en concreto si no cumple alguna condición, así

podemos evitar que determinados campos se confundan según los datos de entrada que utilicemos.

Finalmente, un caso especial en el crackeo es el elemento contenedor Choice, que define varios bloques

que pueden ser válidos para un campo/elemento determinado:



http://community.peachfuzzer.com/v3/Choice.html



18

Si lo utilizamos para consumir unos datos, a la hora de crackear el elemento, Peach irá probando las

diferentes opciones/bloques secuencialmente hasta conseguir que uno de ellos consuma los datos,

bloque con el que se quedará como elegido. Es un elemento que puede ayudar a la hora de hacer

modelos genéricos que consuman diferentes tipos de datos de entrada (petición chunked, petición

multipart, etc.) no conocidos exactamente a priori. Si lo utilizamos sin datos que consumir, Peach irá

utilizando opciones definidas en cada iteración, utilizando todas las definidas en el elemento Choice.

En este enlace se puede descargar nuestro archivo http_base.xml creado, que forma la definición del

protocolo HTTP para nuestro fuzzer y que usaremos como componente para incluirlo en el archivo pit

principal del fuzzer. En el siguiente artículo, veremos como podemos modelar estados con Peach y el uso

y creación de mutadores de datos.



http://www.sidertia.com/media/f3649134-c480-40ef-a725-1dc09344eac9/2033290978/Blog/peach-fuzzer/http-fuzzer/http_base_xml



19

Capítulo 3 – Modelado de Estados y Mutadores

En este tercer capítulo de la serie Estrategias de fuzzing inteligente con Peach fuzzer veremos como

modelar estados en la comunicación que establecerá nuestro fuzzer, como usar los mutadores para

generar datos que provoquen un comportamiento anómalo en una aplicación y como crear nuestros

propios mutadores.

3.1 - MODELADO DE ESTADOS

Un protocolo puede tener una máquina de estados que represente diferentes niveles en la comunicación

y/o puede definir secuencias en las que se debe realizar un intercambio de información para cambiar a

otro estado (handshake tcp, autenticación ssl/tls, etc). Todo esto lo podemos representar también con

Peach y por lo menos, tendremos que definir un StateModel con un elemento State representando un

estado. En los estados con Peach, definiremos acciones con el elemento Action, que indican que el fuzzer

debe recibir (input) o enviar datos (output) a través de una conexión utilizando el publicador especificado

para el Test en cuestión:

Si definimos varias acciones, Peach las irá ejecutando secuencialmente en cada iteración, para volver a

comenzar en la primera en la siguiente. Si queremos alterar este flujo, podemos usar el atributo de la

acción when, para sólo ejecutarla cuando se dé una determinada condición (escrita en C#):

A parte de input y output, hay diferentes tipos de acciones como changeState, que permitirá cambiar a

otro estado si se da una condición. Otro tipo es slurp, que permite copiar un valor de un DataModel a

otro y que por ejemplo, puede ser usado cuando se necesita procesar y reenviar un valor (por ejemplo, el

sequence id tcp enviado por el servidor).



http://www.sidertia.com/Home/Community/Blog/2015/08/31/Estrategias-de-fuzzing-inteligente-con-Peach-Fuzzer-I

http://community.peachfuzzer.com/v3/StateModel.html

http://community.peachfuzzer.com/v3/Action.html

http://community.peachfuzzer.com/v3/when.html

http://community.peachfuzzer.com/v3/Action.html#_action_types



20

Debido a que podemos definir diferentes tipos de estados, acciones y modelos de datos asociados a cada

uno de ellos, tenemos gran control sobre qué datos enviará nuestro fuzzer y cómo los mandará. Si

estamos realizando un fuzzer de un protocolo que requiere una autenticación previa, podemos elegir no

hacer fuzzing de la secuencia de autenticación y sólo realizarlo después, ya que de otro modo sería

complicado realizar la secuencia con éxito. También podemos elegir hacer fuzzing de determinados pasos

en una secuencia o alterar el orden de los mismos, por ejemplo en una autenticación ipsec, si el objetivo

es auditar el propio proceso de autenticación.

En el caso de http y dado que es no orientado a conexión, definiremos diversas acciones con diferentes

peticiones a realizar tomando como modelo nuestro DataModel genérico Request y cargando en el

mismo los datos de peticiones HTTP reales que hayamos considerado como significativas o interesantes

para lograr una buena cobertura de código. De ese modo, sólo se realizará fuzzing de los campos

contenidos en cada petición de ejemplo y según el modelo definido por nuestro DataModel.

3.2 - MUTACIONES

En este punto es donde podemos dar a nuestro fuzzer un toque diferenciador, bien en la selección de

mutadores a utilizar, en los elementos a mutar o en la generación de nuestros propios mutadores.

Es importante recordar que normalmente hay un tiempo finito para realizar el fuzzing y que además, lo

realmente interesante no es mutar cada bit de una comunicación, sino sólo aquellas partes que realmente

puedan hacer que la petición pase por diversas funcionalidades que la procesen correctamente hasta

llegar a la funcionalidad que es objetivo del fuzzer, del test o de la iteración en concreto, para llegar a

cubrir el mayor número de funcionalidades posibles con nuestros tests.

Peach viene por defecto con 27 mutadores de aplicación según el tipo de elemento (numérico, array,

cadena de texto, blob, etc.). Estos mutadores realizan sustituciones de los valores definidos y/o

crackeados en el modelo con el objetivo de provocar una excepción en la aplicación al parsear los datos

(excepciones artiméticas y de conversión de datos, array out of bounds, null pointer access,

buffer/integer overflow, etc.). Algunos de los mutadores más interesantes son los siguientes:

ArrayNumericalEdgeCasesMutator: transforma los arrays añadiendo o sustrayendo miembros para

aumentar o reducir su longitud alrededor de minOccurs y/o maxOccurs.

BlobMutator: realiza diferentes transformaciones sobre un elemento blob (agrandar, encoger,

rellenar con ceros, etc)

DataElementDuplicateMutator: duplica elementos

DataElementRemoveMutator: elimina elementos

DataElementSwapNearNodesMutator: intercambia el orden de nodos adyacentes

NumericalEdgeCaseMutator: produce un rango de números alrededor de casos extremos según el

tamaño de elemento Number, incluidos números negativos. Con el Hint NumericalString también se

puede aplicar a elementos String.

StringMutator: produce un número bastante grande de cadenas que pueden ser útiles como datos

malformados.



http://community.peachfuzzer.com/v3/Mutators.html



21

ValidValuesMutator: este mutador usará como mutaciones los valores de una lista suministrada

separados por punto y coma.

Algunos mutadores permiten pasar información y configurarlos para cada elemento añadiendo Hints al

mismo:

Prácticamente todos los mutadores están activos por defecto para todos los elementos, tan sólo se

desactivarán si en la comprobación de su método supportDataElement el elemento no es del tipo

requerido por el mutador o su atributo mutable está establecido a false:

A la hora de marcar los elementos como no mutables, deberemos tener en cuenta que el elemento

también mutará si su contenedor (Choice, Block o DataModel) no tiene el atributo mutable desactivado.

Todo esto hace que por defecto, Peach tienda a mutar todos los elementos con todos los mutadores

disponibles, algo que puede generar cientos de miles o millones de iteraciones de nuestro fuzzer.

3.3 - CREACION DE MUTADORES

En Sidertia, preferimos usar mutadores que permitan activarlos para un elemento concreto, ya que,

aunque será necesario hacerlo por cada elemento, permitirá tener un control más fino sobre los datos a

generar por nuestro fuzzer y permite adaptar los tests al tiempo disponible para realizarlos. Crear un

nuevo mutador es sencillo, basta con coger uno de los incluidos en la versión Community y usarlo de

plantilla, vamos a ver cómo crear un mutador que genere varias cadenas largas a partir de una semilla con

el objetivo de encontrar vulnerabilidades de buffer overflow u off-by-one.

Primero, deberemos definir una clase y añadirle anotaciones con el nombre del mutador que usaremos

en el xml y los hints o parámetros que acepte como configuración:





22

Nuestro mutator se llamará StringOverflowMutator y aceptará dos Hints, OverflowLengths, que será una

lista de longitudes de cadena a generar separadas por punto y coma y Seed, una semilla opcional a usar

para construir las cadenas. En el método generateValues, leeremos las Hints con Hints.TryGetValue y

llamaremos a dos funciones generateString y generateOffByOneString que generarán cadenas de longitud

n y n+1 por cada valor n pasado como Hint a OverflowLengths, rellenando un array values con los valores

generados:





23

En cada DataElement, la propiedad Variant InternalValue almacena el valor interno del elemento, siendo

este el valor por defecto con sus respectivos Transformer y Fixup aplicados, si los hubiese. Ese valor

interno lo tomaremos como semilla en el caso de que no se haya suministrado ninguna en el Hint Seed.

Para activar nuestro mutator, pondremos como condición que el elemento sea un String, que tenga

activo el atributo mutable y que se haya definido el Hint OverflowLengths:

Finalmente, y una vez generado el array con las cadenas, crearemos dos funciones que serán llamadas por

Peach en cada iteración según la estrategia de mutación para cargar en la propiedad MutatedValue el

valor correspondiente del array:





24

Con compilar la clase como librería y ponerlo en el mismo directorio que los binarios de Peach, al usar el

mutador en nuestros archivos pit Peach se encargará de cargarlo por reflexión.

En el siguiente capítulo y último de la serie veremos cómo seleccionar elementos para ser mutables, como

generar Tests y como extender el propio core de Peach.



http://www.sidertia.com/media/cf19f2e3-16bf-4be6-b577-4cee05a66e99/-60922254/Blog/peach-fuzzer/http-fuzzer/StringOverflowMutator_cs



25

Capítulo 4 – Extensión del Core y creación de Tests

Dentro de cada elemento Test, podemos definir qué elementos van a ser excluidos o incluidos en

la mutación con las etiquetas Include y Exclude. Si incluimos la etiqueta Exclude sin atributos,

excluiremos todos elementos, pudiendo después incluir los que queramos mutar:

El problema es que Peach por defecto no permite la selección con Include de elementos hijos de

un elemento Choice, ya que se mueven a una colección específica (choiceElements). Tampoco

permite la selección de elementos array o de sus hijos si el array tiene definido e l atributos

minOccurs=”0”, ya que será necesario realizar el Include sobre la propiedad origionalElement

que alberga el elemento original. Para salvar este escollo, será necesario recompilar la librería

Peach.Core.dll con unas modificaciones a la clase PeachXpathNavigator.cs:





26

4.1 - INCLUSION / EXCLUSION DE MUTADORES

A parte de incluir y excluir elementos de las mutaciones para un test determinado, también

podemos hacerlo con los mutadores a utilizar en la etiqueta Mutators. Si utilizamos sólo el

atributo include, desactivaremos todos los mutadores menos los incluidos como hijos:

De esta forma, podemos segmentar mejor nuestros tests para realizar las mutaciones deseadas

sobre elementos específicos en base a un objetivo (test completo, test de memory corruption,

test de XSS, etc).





27

La inclusión del mutador StringMutator debe ser considerada con detalle, ya que genera un gran

número de iteraciones y no siempre será de utilidad según el test. Nuestro fuzzer http, para el

Test Overflow, con las peticiones seleccionadas como entrada, generará un total de 227.142

iteraciones con dicho mutador incluido, mientras que sin él, sólo generará 27.306. Usarlo o no

dependerá de nuestros objetivos y del tiempo del que dispongamos, dicho muta dor puede ser

interesante para buscar errores de parseo, pero si sólo nos interesan buffer overflows, el

mutador creado anteriormente StringOverflowMutator sería más eficiente.

4.2 - ESTRATEGIAS DE MUTACION

Por defecto, Peach utilizará la estrategia de mutación Random, que consiste en la inclusión a la

vez de un número de mutaciones (6 por defecto) en cada iteración y que contiene un número

infinito de iteraciones. Otras estrategias de mutación son Sequential y RandomDeterministic,

donde sólo se realizará una mutación en cada iteración, diferenciándose entre ellas en que en

RandomDeterministic lo hará en un orden aleatorio. En los casos de orden aletario, podremos

reproducir cualquiera de las iteraciones ejecutando Peach con el argumento --seed y el número

usado como semilla por el generador de números aleatorio.

Lo recomendable es realizar primero un fuzzing con la estrategia Sequential o

RandomDeterministic, ya que podremos saber el número de iteraciones que realizará nuestro

fuzzer ejecutando Peach con la opción -c. Si no hemos tenido éxito, o queremos hacer un fuzzing

más profundo, es recomendable ejecutar el test con la estrategia Random, ya que en algunos

casos, la combinación de mutaciones es lo único que puede provocar el comportamiento anormal

de la aplicación (p.ej. con la inclusión de dos campos muy largos adyacentes).

4.3 - PUBLICADORES

En Peach, los publicadores son los módulos encargados de enviar y recibir datos desde y hacia

nuestro fuzzer. Existen diferentes publicadores que usarán protocolos de transporte como tcp,

upd, ipv4, v4, v6, ipv6 y Ethernet donde los datos generados por el fuzzer se incluirán como

payload. También se incluye un publicador específico de HTTP, que puede ser útil cuando se

necesite un menor de detalle en el modelado y los objetivos sean por ejemplo hacer fuzzin g tan

sólo de cabeceras y query string.

A parte, también es posible hacer fuzzing de procesadores de archivos, donde en cada iteración

se generará un archivo y se lanzará el programa objetivo que lo consuma para monitorizar el

resultado. Finalmente, con los publicadores Com y Console, podremos hacer fuzzing de interfaces

Com o lanzar la salida del fuzzer a la salida estándar para poder ser consumida por otro programa

externo.

En nuestro fuzzer http, utilizaremos TcpClient como publicador, configurando los valores de la

máquina con el servidor http objetivo. Deberemos tener en cuenta que si existen sistemas

intermedios como proxies, IDS o IPS, la salida de nuestro fuzzer puede verse alterada antes de

llegar al objetivo real del fuzzing:



http://community.peachfuzzer.com/v3/MutationStrategies.html

http://community.peachfuzzer.com/v3/Publisher.html



28

4.4 - MONITORIZACIÓN Y REGISTRO

Igual de importante que encontrar vulnerabilidades tras miles de iteraciones es poder

registrarlas y poder reproducirlas. Para monitorizar el resultado de cada iteración, deberemos

inicializar un Agent, una entidad que puede albergar uno o varios monitores. Los agentes por

defecto son locales, funcionando en la misma máquina que alberga el fuzzer, aunque también es

posible utilizar agentes remotos, lo que, por ejemplo, permite realizar el fuzzing desde una

máquina Windows y monitorizar los resultados con depuradores específicos de Linux en el

sistema objetivo:

Existen 21 monitores diferentes en Peach, para Windows, Linux y OS/X. Algunos de los monitores

incluidos con Peach son los siguientes:

Windows Debugger Monitor: utiliza una instancia de Windows Debugger para monitorizar

excepciones y crashes en la aplicación. Opcionalmente permite reiniciar el proceso auditado

en cada iteración, lo que permite continuar con el fuzzing incluso aunque haya habido un

crash en el mismo.

Linux Crash Monitor: utiliza un script para detectar crashes en la aplicación.

Cleanup Registro Monitor: borrará las claves del registro que le suministremos en cada

iteración.

Cleanup Folder Monitor: borrará el contenido de un directorio antes de cada iteración. Útil

para iteraciones que creen archivos (FTP, HTTP, etc.) para evitar saturar el servidor.

Memory Monitor: controla que un determinado programa no exceda en el consumo de

memoria de un valor, algo útil ya que no todos los test con éxito provocan un reinicio del

servicio.

Ping Monitor: realiza un ping al objetivo, útil para comprobar el estado de dispositivos

(routes, switches, etc.) tras cada iteración.

Process Killer Monitor: mata un proceso especificado después de cada iteración.

SSH Monitor: conecta por SSH con un host y ejecuta un comando, permitiendo aplicar una

expresión regular a la respuesta para detectar si ha habido un fallo o no.

Vmware Monitor: controla una instancia de vmware, permitiendo iniciarla o incluso revertir

opcionalmente a una instantánea determinada.



http://community.peachfuzzer.com/v3/AgentsMonitors.html



29

Cuando uno de los monitores configurados detecte lo que interprete como fallo, Peach volverá a

ejecutar la iteración para confirmar el fallo y si se vuelve a producir , registrará la iteración y el

fallo con el logger configurado.

Como loggers, Peach tan sólo incuye un registrador por defecto, que registra a una archivo de

texto los resultados. Compañías como Microsoft, utilizan loggers más complejos, que, utilizando

también mini-debuggers especialmente diseñados, permiten clasificar las excepciones

provocadas, registrarlas en varios archivos separados y crear un hash de cada una para evitar

tener que revisar después una y otra vez la misma excepción:





30

Capítulo 5 – Conclusión

El fuzzing es una técnica que puede llegar a ser compleja para que de verdad sea efectiva, pero

hoy en día es muy recomendable tanto para pentesters como para programadores y es un arma

más que podemos utilizar para auditar la seguridad de los sistemas. Una adecuada planificación y

la extensión de frameworks flexibles como Peach serán factores que influyan decisivamente en la

efectividad de nuestros fuzzers, esperamos que este artículo haya servido como introducción al

proceso.

En éste enlace, se puede descargar un zip con todos los archivos pit, entradas del fuzzer y clases

C# utilizados en esta serie.



http://www.sidertia.com/media/5c2cc383-fd90-46b9-a878-2375b5236890/1661365869/Blog/peach-fuzzer/http-fuzzer/sdt_http_fuzzer.zip



31

DAVID FERNANDEZ MADRID


[email protected]

David Fernández Madrid desde inicios del 2014 hasta la actualidad desarrolla

tareas de, Consultor Senior de Seguridad, Analista Programador y Jefe de

Equipo en el Departamento de Desarrollo de Aplicaciones Seguras y Auditoría

Web de Sidertia Solutions S.L.

Desde su incorporación a la compañía, avalada por una sólida experiencia profesional previa y en

función de su formación multidisciplinar, le han permitido participar de forma activa en destacados

proyectos de seguridad, auditoría web, consultoría o formación experta.

A su capacitación técnica como Consultor Senior de Seguridad y Analista/Programador, añade una

interesante trayectoria en la gestión de proyectos y la dirección de equipos técnicos en múltiples

proyectos tanto en el ámbito nacional como internacional, donde en muchos casos se han

aprovechado sus capacidades de comunicación en múltiples idiomas, especialmente inglés y francés.

Durante este periodo algunas de sus múltiples actuaciones reseñables podrían ser las siguientes:

Intervención como Consultor Senior de Seguridad en auditorías de seguridad, seguridad web y

seguridad de aplicaciones móviles, así como auditorías de código seguro, todo ello para

compañías de relevancia como son Atos o empresas del grupo BNP Paribas, así como organismos

oficiales y fuerza de seguridad del Estado. En sintonía con lo anterior, actúa regularmente y de

forma destacada en proyectos relacionados con el análisis de software malicioso.

Participa en calidad de Programador, Analista Programador, Arquitecto de Software y Jefe de

Equipo en diversidad de proyectos de desarrollo para compañías de considerable relevancia

como las ya mencionadas u otras como el Grupo Unidad Editorial.

Imparte regularmente acciones de formación experta relacionadas con sus ámbitos de

conocimiento, como son el análisis de malware, el pentesting, la programación segura, entre

otros. En este sentido se podrían destacar sus intervenciones como docente en los planes de

formación experta para las áreas de ciberseguridad de distintos ejércitos del Estado Español.

En calidad de Consultor Senior de Seguridad participa de igual modo en proyectos y actuaciones

de análisis forense para compañías y entidades internacionales de carácter financiero líderes en

el sector. Lógicamente y como ventaja fundamental junto a su capacitación técnica es de

destacar su capacidad operativa hasta en 4 idiomas.

Junto a su dilatada experiencia profesional ya reseñada, es de destacar su inquietud

investigadora en el campo de la seguridad informática. Fruto de ella cuenta con más de catorce

vulnerabilidades 0day descubiertas y publicadas en Security Focus afectando a routers,

cortafuegos, servidores de correo, antivirus, navegadores, aplicaciones de Microsoft Windows y

aplicaciones CMS. De igual modo y gracias a ello, David publica regularmente artículos técnicos

de valor, destacando la generación de información técnica asociado a la ciberseguridad.

www.sidertia.com www.flu-project.com






32

Su alta capacitación y especialización técnica en múltiples vectores del ámbito de la seguridad

informática recogida en los apartados anteriores, sumado a su capacidad de gestión de grupos y

trabajo en equipo, a su experiencia en la coordinación de proyectos y alta capacidad autodidacta, le

convierten en un profesional estratégico en la operativa de Sidertia Solutions en proyectos y

actuaciones relacionada con la seguridad de los sistemas y la información.



Documents

David Fernández Madrid - sidertia.com · David Fernández Madrid Estrategias de fuzzing inteligente con Peach Fuzzer Consolidación de blogs escritos por el autor entre el 31 agosto