David Fernández Madrid - sidertia.com · David Fernández Madrid Estrategias de fuzzing...
-
Upload
duongkhuong -
Category
Documents
-
view
219 -
download
1
Transcript of David Fernández Madrid - sidertia.com · David Fernández Madrid Estrategias de fuzzing...
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
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
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.
David Fernández Madrid
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
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.
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
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.
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
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.
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
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:
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
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:
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
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.
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
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
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
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:
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
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:
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
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:
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
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:
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
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):
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
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:
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
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
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
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:
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
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.
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
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).
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
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.
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
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:
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
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:
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
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:
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
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.
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
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:
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
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).
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
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:
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
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.
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
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:
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
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.
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
31
DAVID FERNANDEZ MADRID
David Fernández Madrid
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
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
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.