otsmr/blackbox-fuzzingFuzzing de dispositivos IoT usando el router TL-WR902AC como ejemplo
Esta es la versión HTML de mi trabajo académico, que se puede descargar como PDF aquí.
El fuzzing se ha convertido en "una de las formas más eficaces" de encontrar errores en el software. Con esta o afirmaciones similares, muchos artículos actuales relacionados con el fuzzing comienzan [google-scholar]. El objetivo principal de nuestro último trabajo académico sobre el tema "Internet of Vulnerable Things" era encontrar un error relacionado con la memoria y luego escribir un exploit para esa vulnerabilidad. Pudimos encontrar una vulnerabilidad mediante la ingeniería inversa del firmware, pero no se encontraron errores relacionados con la memoria. Encontrar un desbordamiento de búfer mediante la ingeniería inversa manual de un binario no solo consume tiempo, sino que también requiere mucha experiencia. Al mismo tiempo, el fuzzing pretende ser la "forma más eficaz" de encontrar este tipo de vulnerabilidades relacionadas con la memoria. Google, por ejemplo, introdujo OSS-Fuzz, que fuzzea continuamente software de código abierto y ya ha encontrado más de 10 000 vulnerabilidades en 1 000 proyectos [oss-fuzz].
El objetivo de este trabajo académico es, de nuevo, encontrar una vulnerabilidad relacionada con la memoria, pero esta vez mediante fuzzing. La vulnerabilidad objetivo debe ser explotable a través de la red sin conocimiento de las credenciales de administrador. Este documento describe el camino para lograr este objetivo. Para ello, el documento se divide en dos partes. La primera parte se centra en cómo encontrar un objetivo potente, qué herramientas se pueden utilizar y en qué debe consistir un buen objetivo de fuzzing. La segunda parte describe cómo desarrollar y depurar un harness capaz de fuzzear una función específica de un binario. Luego, el harness desarrollado se usa con AFL++ para fuzzear la función objetivo. A continuación se ofrece un breve contexto y se describe cuál es el estado del arte actual en lo que respecta al fuzzing de dispositivos IoT.
Todos los archivos creados en el contexto de este trabajo académico se publican íntegramente en GitHub y se pueden acceder mediante la siguiente URL: otsmr/blackbox-fuzzing.
Fuzzear dispositivos IoT no es tan fácil como fuzzear un proyecto de código abierto. A menudo, el código fuente es propietario, lo que hace imposible el fuzzing de caja gris, que instrumenta el código fuente para obtener el mejor rendimiento de fuzzing, [afl-persistent]. Además, la arquitectura de CPU a menudo no es compatible de forma nativa con los fuzzers, lo que requiere un emulador como QEMU [qemu], que además ralentiza la velocidad de fuzzing [afl-persistent]. Otro problema son los periféricos de hardware, lo que complica el desarrollo de un enfoque general. El artículo "Embedded Fuzzing: A Review of Challenges, Tools, and Solutions" [embedded-fuzzing] ofrece una visión general de diferentes estrategias de fuzzing, como el fuzzing embebido basado en hardware. La mayoría de estas estrategias necesitan el código fuente del programa objetivo, como cuando se porta el código fuente del fuzzer, como AFL, a dispositivos IoT basados en ARM para ejecutar el fuzzer en el hardware IoT. Ejecutar el fuzzer en el hardware del dispositivo también tiene problemas de rendimiento, porque a menudo tienen CPU de bajo nivel, que son más lentas que las CPU de escritorio normales. Otro enfoque presentado en este artículo es el fuzzing embebido basado en emulación, donde se ejecuta en un emulador un único programa objetivo para realizar fuzzing guiado por cobertura, o bien el sistema completo.
Los enfoques mencionados anteriormente apuntan directamente a un binario mediante un emulador o instrumentando
el código fuente. Estos enfoques requieren una configuración de fuzzing que a menudo debe estar diseñada específicamente
para un único dispositivo IoT y son difíciles de generalizar. Para ello, los investigadores crearon un programa,
IoTFuzzer que pretende ser un framework de fuzzing automatizado orientado a "encontrar vulnerabilidades de corrupción de memoria
sin acceso a sus imágenes de firmware
[iotfuzzer]." IoTFuzzers
se basa en la observación de que la mayoría de los dispositivos IoT tienen una aplicación móvil para controlarlos, y dichas aplicaciones
contienen información sobre el protocolo utilizado para comunicarse con el dispositivo. El programa luego
identifica y reutiliza la lógica específica del programa para mutar los casos de prueba y así probar eficazmente
los objetivos IoT [iotfuzzer].
Un harness describe una secuencia de llamadas API que procesan las entradas proporcionadas por el fuzzer. A diferencia de una aplicación normal, que a menudo no necesita un harness, una biblioteca que implementa funciones reutilizables debe ser llamada con los parámetros correctos y también en la secuencia correcta, para que el estado entre múltiples llamadas a funciones compartidas pueda ser invocado. Fuzzear aleatoriamente la biblioteca sin construir la máquina de estados es poco probable que tenga éxito y, por el contrario, creará muchos falsos positivos de fallos cuando no se respetan las dependencias de la biblioteca. Esto puede ocurrir cuando, por ejemplo, el fuzzer omite una comprobación del tamaño del búfer, lo que produce un desbordamiento de búfer espurio.
En este artículo se fuzzearán aplicaciones normales, pero debido a las dependencias de hardware del uso de sockets y del multiproceso, también necesitamos crear un harness para ellas. El harness se carga en el contexto del binario y puede llamar a funciones internas del programa objetivo, como se muestra en Código 10.
El término "corpus" describe muestras de entrada válidas o casos de prueba y sirve como referencia fundamental para generar nuevos datos de entrada durante el proceso de fuzzing. En Código 10 esto sería, por ejemplo, una petición HTTP. Los fuzzers aprovechan este corpus para crear casos de prueba mutados o diversificados, lo que ayuda a la detección de vulnerabilidades de software mediante la exploración de varios escenarios de entrada.
