• Modelado de datos: Es el elemento que describe (normalmente a través de gramáticas) el formato de los datos, la secuencia de mensajes o la estructura del protocolo que utilizará el componente de generación de datos.
• Generación de datos.: Haciendo uso de la información proporcionada por el modelado de datos, se encarga de construir los casos de prueba que servirán como entrada para el sistema objetivo.
• Motor de fuzzing: Encargado de la ejecución de los casos de prueba de entrada producidos sobre el objetivo.
• Supervisión y generación de informes: Responsable de supervisar el sistema que se está poniendo a prueba e informar de cualquier incidencia que se produzca. De esta forma se conoce el estado y el caso de prueba que ha desencadenado la incidencia.

AFL (American Fuzzy Lop) es un fuzzer orientado a seguridad que utiliza instrumentación en tiempo de compilación y algoritmos genéticos para mejorar la cobertura de código y descubrir automáticamente casos de prueba interesantes que desencadenen nuevos estados internos en el programa. Cuando el código fuente del objetivo está disponible, la instrumentación se realiza por una herramienta complementaria que provee AFL y funciona como un reemplazo para el compilador, tanto para gcc como clang. Por ejemplo, si quisiéramos usar el reemplazo de clang:

• $ CC=/ruta/a/afl/afl-clang ./configure; make clean all

Por otra parte, cuando el código fuente no está disponible AFL ofrece la posibilidad de instrumentar el binario a través de una versión de QEMU funcionando en modo emulador de espacio de usuario, implementando la instrumentación sobre los bloques básicos que utiliza QEMU en la traducción. Para utilizar esta característica se debe añadir -Q en la línea de comandos a la hora de ejecutar afl-fuzz, habiendo descargado, configurado y compilado QEMU previamente ejecutando el script /ruta/a/afl/qemu_mode/build_qemu_support.sh.

A grandes rasgos el algoritmo general de AFL se puede resumir en 6 pasos:

• 1. Cargar los casos de prueba proporcionados por el usuario en la cola.
• 2. Coger el siguiente fichero de entrada de la cola.
• 3. Intentar reducir el caso de prueba en la mayor medida de lo posible sin alterar el comportamiento calculado del programa.
• 4. Mutar repetidamente el fichero utilizando una variedad equilibrada de estrategias de fuzzing tradicionales.
• 5. Si alguna de las mutaciones generadas resulta en una nueva transición de estado registrada por la instrumentación, añadir dicha mutación como nueva entrada en la cola.
• 6. Volver a 2.

Para empezar con el fuzzing primero se necesita un directorio de lectura con un conjunto inicial de casos de prueba y otro directorio para guardar los descubrimientos. Una vez esté todo listo podemos empezar ejecutando (en caso de que el programa lea por la entrada estándar):

• $ afl-fuzz -i dir_entrada -o dir_descubrimientos /ruta/al/programa

Una vez en funcionamiento, se mostrará el estado del proceso en consola como se puede ver en la imagen.

The post Analizando un framework de fuzzing appeared first on S3lab.

Para ilustrar el funcionamiento del fuzzing con un ejemplo muy simple, vamos a tomar como referencia el siguiente fragmento de código.

Como se puede ver, en la línea 4 se produce un bug cuando el valor de x contiene la cadena ‘aaa’, por lo tanto el objetivo consiste en proporcionar valores a x sucesivamente (i.e., ‘a’, ‘b’, …, ‘aa’, ‘ab’, …) hasta encontrar una entrada a partir de la cual se desencadene el bug y una vez descubierto, guardar todos los elementos necesarios para poder reproducirlo. La ventaja es que una vez que un fuzzer se pone en funcionamiento, se puede dejar durante días, semanas o meses en busca de errores sin necesidad de interacción.

Cabe destacar que, para un fuzzing efectivo, los datos de entrada proporcionados no deben ser simplemente malformados o aleatorios, sino que deben ser suficientemente válidos como para superar pruebas elementales de consistencia y no ser directamente rechazados, pero suficientemente excepcionales como para producir comportamientos inesperados. Dependiendo de como se crean los datos de entrada, se distinguen 3 tipos de fuzzing: los basados en mutaciones que crean los datos de entrada mutando «aleatoriamente» valores de entrada válidos, los basados en generación que generan los datos de entrada desde cero y el fuzzing evolutivo, que a partir de un conjunto de valores iniciales de entrada y utilizando un algoritmo evolutivo produce los valores que mejor se adaptan en base a una serie de propiedades.

Por otra parte, dependiendo del conocimiento del fuzzer sobre el formato de los valores de entrada, se distinguen 2 tipos: el dumb fuzzing, que como su nombre indica no necesita ningún conocimiento sobre el objetivo y el smart fuzzing, que es consciente de la estructura de entrada a través de modelos o grámaticas. La principal diferencia entre ambos tipos es la validez de los valores de entrada y la cantidad de trabajo necesario para generarlos, es decir, un dumb fuzzer generará casos de prueba con menos esfuerzo que un smart fuzzer pero la proporción de entradas válidas (casi) siempre será menor.

Actualmente el fuzzing es un área activa de investigación debido a su efectividad y buenos resultados, lo que también ha favorecido que las empresas lo adopten dentro del proceso de verificación de calidad en el ciclo de vida de desarrollo de software. Como muestra de su efectividad, Google anunció hace varios meses que su proyecto OSS-Fuzz había encontrado más de 1.000 bugs en 47 proyectos distintos de código abierto en un plazo de 5 meses.

The post Explicando las bases del fuzzing appeared first on S3lab.