El Dr. David Brumley, profesor de la Universidad Carnegie Mellon y director ejecutivo de ForAllSecure, explica qué es Fuzzing y cómo las empresas pueden usarlo para mejorar la seguridad de las aplicaciones y acelerar su ciclo de vida de desarrollo de program.
El concepto de fuzzing o fuzz screening tiene décadas de antigüedad, pero no es muy conocido fuera de los círculos de seguridad cibernética. Eso necesita cambiar. Afortunadamente, el Dr. David Brumley, uno de los mejores en el negocio de la seguridad digital, tuvo la amabilidad de darme una lección básica no hace mucho tiempo, y puedo compartirla con ustedes.
El Dr. Brumley es profesor en la Universidad Carnegie Mellon y director ejecutivo de ForAllSecure. También construyó la tecnología fuzzing que ganó el DARPA Cyber Grand Obstacle. En esta exclusiva lección de seguridad cibernética de TechRepublic, el Dr. Brumley explica qué es el fuzzing y cómo las empresas pueden usarlo para ayudar a mejorar sus procesos de seguridad de aplicaciones y ciclos de desarrollo de application. La siguiente es una transcripción del video clip editado para facilitar la lectura.
¿Qué son las pruebas de fuzzing o fuzzing?
Bill Detwiler: Entonces, David, gracias por acompañarme, y vayamos directo al grano. ¿Qué es fuzzing?
Dr. David Brumley: Bueno, como dijiste, fuzzing se nombró hace unos 25 años. La historia es que el profesor Bart Miller y sus estudiantes graduados estaban observando la confiabilidad de las aplicaciones de Unix, Microsoft y Apple y notaron algo un poco divertido. Cuando daban a estas aplicaciones una entrada aleatoria, podían hacer que aproximadamente un tercio de ellas fallaran. Un bonito número de cerdo. ¿Correcto? Realmente period como los proverbiales monos escribiendo en un teclado.
Invoice Detwiler: Correcto.
Dr. David Brumley: Pero en lugar de crear Shakespeare, encontraron serios problemas de seguridad.
Dr. David Brumley, profesor de ingeniería eléctrica e informática en la Universidad Carnegie Mellon y director ejecutivo de ForAllSecure
Crédito: ForAllSecure
Bill Detwiler: Eso es peor, ¿verdad?
Dr. David Brumley: Es peor. Es mucho peor. Así que déjame explicarte cómo funciona el fuzzing y usaré una analogía aquí. Así que piensa en un programa como un laberinto, ¿verdad? Y entonces sabemos que cuando un programador está desarrollando código, tiene diferentes cálculos dependiendo de lo que le dé el usuario. Así que aquí el programa es el laberinto y luego tenemos, solo pretendamos, un pequeño robotic aquí arriba y la entrada al programa serán las instrucciones para nuestro robot a través del laberinto.
Entonces, por ejemplo, podemos darle al robotic las direcciones, lo voy a escribir aquí, abajo, izquierda, abajo, derecha. Y tomará dos derechos, lo que significa que irá a la derecha dos veces. Y luego caerá un montón de veces. Entonces, puedes pensar en darle a nuestro pequeño robot esta entrada y el robotic tomará eso como instrucciones y tomará este camino a través del programa. Va a bajar, a la izquierda, primero a la derecha, segundo a la derecha, luego un montón de bajadas.
Y cuando miras esto, tuvimos un pequeño mistake aquí. Pueden verificar que esto esté realmente bien. No hay ningún mistake real aquí. Y esto es lo que sucede cuando un desarrollador escribe una prueba unitaria. Entonces, lo que están haciendo es generar una entrada y asegurarse de que obtenga la salida correcta.
Ahora, un problema es que, si piensas en este laberinto, solo hemos comprobado un camino a través de este laberinto y hay otros errores potenciales al acecho. Entonces, lo que hace el fuzzing es que realmente automatiza la plan de generar una entrada y ejecutar el programa y ver si encontramos un error.
Entonces, por ejemplo, si pensamos en cambiar estas direcciones un poco, tenemos abajo, izquierda, abajo, pero en lugar de tomar dos derechos, solo tomamos uno a la derecha, y luego bajamos y algunas direcciones más. El robot puede tomar esta ruta distinct a través del programa hacia abajo, a la derecha, y en lugar de ir dos, solo bajará uno, digamos que viene aquí, y encontramos que el programa falla.
Ahora, lo que Bart encontró originalmente, por supuesto, era proporcionar información aleatoria, por lo que no estaba estructurado como este. Las entradas aleatorias en realidad podrían hacer que las aplicaciones se bloqueen, con bastante frecuencia. Ahora, estamos en nuestra tercera generación de técnicas de fuzzing. Ya no son monos escribiendo en un teclado. Hay mucha más tecnología detrás de esto, aunque la idea sigue siendo la misma. Vamos a generar entradas automáticamente. Vamos a ver si el programa falla o no. Y aquí está lo genial. Puede ser completamente automatizado. Al hacer que la computadora haga esto, en lugar de que el desarrollador escriba la prueba unitaria, puede realizar miles de estas iteraciones en un solo segundo.
Permítanme contrastar esto con el análisis estático, porque sé que mucha gente piensa en el análisis estático y el fuzzing y se pregunta cuál es la diferencia entre ellos. Entonces, cuando piensa en el análisis estático, lo que hace el análisis estático es mirar el programa. En realidad, nunca lo ejecuta. Y está diciendo, bueno, puede haber un problema aquí, quizás un problema aquí, quizás ya sabe que esto está bien, quizás hay un problema que piensa aquí y así sucesivamente, pero nunca se ha probado realmente que haya un problema.
VER:
Tutorial de DevSecOps: ¿Qué es y cómo puede mejorar la seguridad de las aplicaciones?
(TechRepublic)
Invoice Detwiler: Entonces, ¿busca patrones en el código?
Dr. David Brumley: Solo busca patrones. Entonces, si realmente miras este laberinto, bien, puedes decir, bueno, el análisis estático marcó esto, pero no hay forma de que un pequeño robot pueda llegar allí. Está bloqueado. Y cuando piensa en el análisis estático, potencialmente puede encontrar más errores, pero debe contratar a alguien que lo revise manualmente. Lo que está haciendo fuzzing es explorar gradualmente el programa para encontrarlos, para encontrar montones de problemas. Por ejemplo, Google tiene un proyecto en el que están comprobando Google Chrome y muchas de las bibliotecas de código abierto que usa Google y encontraron 25.000 errores de forma completamente automática con cero falsos positivos durante los últimos tres años.
«data-credit =» «rel =» noopener noreferrer nofollow «>
También quiero dejar de lado la seguridad y decir, ¿cómo puede esto beneficiar al desarrollador? Porque la seguridad no siempre tiene un costo. De hecho, puede beneficiarse. Todos sabemos que cuanto mejor probamos un programa, más confiable será en el campo. Y también sabemos que a los desarrolladores no les gusta especialmente escribir casos de prueba. Entonces, al usar fuzzing para generar diferentes entradas que ejecuten todas estas rutas, en realidad son solo casos de prueba y puede hacer eso para hacer pruebas de regresión a lo largo del tiempo. Por lo tanto, uno de los beneficios más allá de la seguridad del fuzzing es que puede usarlo para acelerar el ciclo de vida del desarrollo de application y producir un código más confiable y de mejor calidad.
Cómo empezar a usar fuzzing o fuzz tests
Bill Detwiler: Entonces, ¿cómo pueden las empresas empezar a utilizar el fuzzing como técnica y cuáles son algunos de los fuzzers reales que existen? Hablemos de eso.
Dr. David Brumley: Si. Así que comencé diciendo que esto fue inventado o acuñado hace 25 años por el profesor Bart Miller y realmente estamos en nuestra tercera generación. Entonces, el conjunto primary de fuzzers period lo que llamamos fuzzers de caja negra y generaban entradas, tal vez al azar o con algún algoritmo, y simplemente ejecutaban el programa y veían si fallaba o no.
Invoice Detwiler: Una y otra y otra vez. Bueno.
Dr. David Brumley: Una y otra y otra vez. Ahora, el problema con eso es que si solo está generando una entrada aleatoria, es posible que no lleve al robotic a ninguna parte. Por ejemplo, no desea generar una entrada que haga que el robotic baje y retroceda y retroceda, y así sucesivamente. Entonces esa fue la primera generación. Estas técnicas todavía funcionan hoy en día, generando aleatoriamente, pero no tan bien.
La segunda generación son los que llamamos zumbadores basados en protocolo o gramática. Y lo que hacen es que alguien genere manualmente una plantilla sobre cómo crear esas entradas. Entonces, en nuestro ejemplo, aquí, alguien puede escribir una plantilla que diga siempre ir hacia abajo y luego ir hacia abajo o hacia la derecha, ir hacia la izquierda o hacia la derecha a continuación, ir después tal vez hacia abajo o hacia arriba nuevamente y así sucesivamente.
Y si piensa en lo que está haciendo, está restringiendo el conjunto de cosas que va a explorar. Entonces, por ejemplo, si escribe este protocolo o gramática, puede terminar sin darse cuenta verificando solo una parte del programa porque en realidad no ha dicho que es posible ir tan lejos. Entonces esa es una segunda generación. Grandes productos hoy en día.
La tercera generación es lo que llamamos fuzzing guiado por instrumentación. Y lo que hace el fuzzing guiado por instrumentación es generar una entrada y observa cómo los robots ejecutan la ruta y aprende de eso para generar la siguiente entrada. Y a veces esto se califica como fuzzing de IA. No lo considero IA, pero es aprendizaje. Cuanto más se ejecuta, aprende qué caminos ya ha examinado y cuáles son los nuevos lugares que existen.
Monthly bill Detwiler: Así que es un poco de lo mejor de ambos mundos, ¿verdad? Tiene un proceso restringido, pero no está perdiendo la mitad de las vulnerabilidades potenciales.
Dr. David Brumley: Creo que sí. Y creo que si nos fijamos en las tiendas de desarrollo modernas, las personas como Google y Microsoft que invertirían toneladas de dinero en esto, se han decidido por el fuzzing guiado por instrumentación por una razón.
