¿Por qué molestarse y gastar dinero y recursos en seguridad? ¿Por qué molestarse en organizar un ciclo de vida de desarrollo de seguridad (SDL)? ¿Por qué integrar fuzzing en el proceso de desarrollo? ¿Por qué molestarse con el conocimiento sobre varios fuzzers como AFL, libfuzz, etc.? Después de todo, puede "simplemente" convertir la búsqueda de vulnerabilidades en sus productos en una tortura continua y hacer una vida "dulce" para los investigadores y atacantes. ¿Quieres saber cómo hacer esto? Entonces bienvenido a Kat!
Descargo de responsabilidad: ¡ Este artículo debe tomarse con cierto humor e ironía!Recientemente, más y más trabajos se han dedicado al tema de AntiFuzzing. AntiFuzzing es una acción que reduce la efectividad y el uso de fuzzing para buscar vulnerabilidades en las soluciones de un desarrollador.
Este artículo se centrará en las aplicaciones binarias fuzzing escritas en C \ C ++ que pueden implementarse localmente y tratar de encontrar vulnerabilidades relacionadas con la corrupción de memoria en ellas.
Hoy en día, una gran cantidad de acciones están dirigidas contra AFL fuzzer, como el representante más llamativo, conocido y reputado del enfoque de fuzzing basado en comentarios.
Después de estudiar el problema, identificamos posibles técnicas AntiFuzzing:
- Desordenar los resultados del trabajo de fuzzer es la técnica más excéntrica que algunos desarrolladores están adoptando sin darse cuenta) Consiste en el hecho de que para que el programa sea más seguro, debe agregar más errores allí ... Sí, desafortunadamente, no podemos responder la pregunta es cuántos de nuestros errores ya están en el programa y qué tan peligrosos son, ¡pero podemos diluirlos con un montón de errores que son inútiles para el atacante!
- La detección de un proceso difuso es todo del alcance de jailbreak_detect, root_detect. La aplicación determina de forma independiente (y el desarrollador escribe una serie de comprobaciones) que no solo funciona, sino que está en fases y, como resultado, se niega a funcionar. La industria de la seguridad de la información ha pasado por esto un millón de veces. Este código se busca y excluye de la aplicación con bastante facilidad, y la técnica lleva al título de "el más inútil y poco sofisticado".
- Retrasando el proceso de fuzzing: dentro de nuestra empresa llamamos a estas cosas "esconder errores en los gastos generales". Incluso ahora, algunos programas funcionan mal, no solo bajo fuzzing, por lo que buscar vulnerabilidades se convierte en una tarea psicológicamente difícil para los investigadores)
- La creación de zonas de puntos ciegos es la dirección más interesante, que, en nuestra opinión, impulsará la evolución de los fuzzers. Entonces, en el trabajo presentado en BlackHat 2018, AFL plantea el problema de las colisiones en shared_mem, que lo utiliza para determinar las secciones cubiertas de código. Es decir, se crean áreas donde el fuzzer no cae durante su funcionamiento.
Por lo tanto, AntiFuzzing tiene ventajas y desventajas obvias:
- "-" Quizás el enturbiamiento de la mente de los desarrolladores de software que están poco versados en algunos aspectos de la seguridad de la información y el proceso difuso.
- "+" La evolución de los fuzzers, que en el futuro comenzarán a superar los mecanismos AntiFuzzing implementados y proporcionarán una mayor cobertura en primer lugar, si hay mecanismos AntiFuzzing implementados; segundo, cuando hay elementos en el software que simulan funciones AntiFuzzing.
¿Por qué usar este enfoque para garantizar una seguridad estúpida y dañina? El desarrollo de un enfoque AntiFuzzing de alta calidad y su aplicación a software real es comparable en complejidad al desarrollo del algoritmo en sí mismo para aumentar la cobertura del código con fuzzing basado en retroalimentación. La dificultad es que, además de insertar estructuras inhibidoras de fase en los lugares correctos, es necesario asegurarse de que no tengan un patrón claro que pueda distinguirse y luego simplemente excluirse. AntiFuzzing no aumenta la seguridad de la aplicación en sí ... Es bueno que mientras la investigación de AntiFuzzing se lleve a cabo solo en un entorno académico. Al mismo tiempo, hay empresas que, por el contrario, se centran en simplificar la búsqueda de errores. Por ejemplo, Mozilla proporciona una compilación especial de su navegador para este
blog.mozilla.org/security/2018/07/19/introducing-the-asan-nightly-project !
El aumento del interés en AntiFuzzing fue causado principalmente por el DARPA Cyber Grand Challenge 2016. Esta es una competencia donde las computadoras sin ayuda humana buscaron vulnerabilidades, las explotaron y las repararon. Puede que haya adivinado que la mayoría de los sistemas de búsqueda se basaban en AFL Fuzzer, y todos los objetivos en la competencia eran aplicaciones binarias. Todo esto puede estar dirigido a contrarrestar los sistemas automáticos, y no a las personas.
Este artículo se basa en trabajos que puede estudiar usted mismo:
- "Escapar del Fuzz Evaluar las técnicas de Fuzzing y engañarlas con AntiFuzzing" , tesis de maestría en redes y sistemas informáticos
2016 - Chaff Bugs: disuadiendo a los atacantes haciendo que Buggier sea software , 2018
- “El punto ciego de AFL y cómo resistir el fuzzing de AFL para binarios arbitrarios de ELF” , BlackHat USA 2018
- También le recomendamos que lea el artículo de los chicos del Grupo NCC "Introducción a Anti-Fuzzing: A Defense in Depth Aid" de 2014 (el primer lanzamiento de AFL acaba de aparecer y aún no ha ganado un gran amor de la comunidad, y 2 años más antes de la final de DARPA CGC).
PD: a menudo trabajamos con AFL (+ libfuzz) y sus modificaciones cuando investigamos software e implementamos SDL para nuestros clientes. Por lo tanto, en uno de los siguientes artículos, hablaremos más sobre el fuzzing usando AFL y por qué cada vez más personas lo usan en los programas de prueba y cómo esto aumenta el nivel de seguridad del desarrollo.