Fuzzing: las claves del método de prueba au­to­ma­ti­za­do

El fuzzing, también conocido como fuzz testing, es un método au­to­ma­ti­za­do ideal para descubrir puntos débiles en el software. Descubre en este artículo de qué trata este pro­ce­di­mie­n­to y qué ventajas y de­s­ve­n­ta­jas presenta este método, así como las di­fe­re­n­tes he­rra­mie­n­tas de fuzzing que existen.

El fuzzing o fuzz testing es un método de­sa­rro­lla­do por el cie­n­tí­fi­co Barton Miller para poner a prueba de una forma si­s­te­má­ti­ca los puntos débiles de los programas. En este método no se intenta in­te­r­pre­tar el código fuente del programa; de hecho, el software se considera una caja negra y su contenido se considera dado. Se accede a todas las in­te­r­fa­ces de la in­tro­du­c­ción de datos de forma au­to­ma­ti­za­da y se alimentan con datos alea­to­rios. Este proceso puede durar, en función del tamaño del proyecto que estamos in­s­pe­c­cio­na­n­do, horas e incluso días.

El objetivo del fuzz testing es de­te­r­mi­nar si se dan las reac­cio­nes ne­ce­sa­rias en el programa para todas las variantes posibles de entrada. Las entradas que no tengan sentido o que sean erróneas deberían ser de­te­c­ta­das en la mayor medida posible por las rutinas de solución de errores. Si estas rutinas no están di­s­po­ni­bles para de­te­r­mi­na­das entradas, o si no funcionan co­rre­c­ta­me­n­te, puede pro­du­ci­r­se una caída del programa. El pro­ce­di­mie­n­to técnico de comprobar todas las eve­n­tua­li­da­des del programa forma parte integral de los entornos de de­sa­rro­llo desde hace ya tiempo en el campo del de­sa­rro­llo web. Por ejemplo, muchas apli­ca­cio­nes web se co­m­prue­ban desde hace ya años mediante cross browser testing para verificar su fu­n­cio­na­li­dad en distintos clientes web y versiones de na­ve­ga­do­res.

A grandes rasgos, se puede di­s­ti­n­guir entre las si­guie­n­tes tres variantes de fuzzing:

Mediante este enfoque de fuzz testing, se evalúan funciones como los botones y los campos de in­tro­du­c­ción de programas gráficos u opciones de programas basados en línea de comandos. Para ello, el objetivo es acceder a funciones con una fre­cue­n­cia poco natural o rápida o se rellenan los campos de in­tro­du­c­ción con co­n­te­ni­dos demasiado grandes.

Para el in­te­r­ca­m­bio de datos, se utilizan pro­to­co­los, como el protocolo de tra­n­s­fe­re­n­cia de hi­pe­r­te­x­to (HTTP) de la web. Los datos tra­n­s­fe­ri­dos deben estar en un formato de­te­r­mi­na­do. El fuzzing de pro­to­co­los sirve para comprobar el co­m­po­r­ta­mie­n­to en el caso de los envíos de co­n­te­ni­dos con un formato in­co­rre­c­to. Para ello, es es­pe­cia­l­me­n­te im­po­r­ta­n­te que no se in­te­r­pre­te de forma ac­ci­de­n­tal el contenido tra­n­s­fe­ri­do como comandos y que luego se ejecuten en un servidor.

Las he­rra­mie­n­tas de fuzzing que siguen este enfoque generan archivos de­fe­c­tuo­sos para que los procesen los programas que se van a examinar. Los archivos tienen no­r­ma­l­me­n­te un formato no­r­ma­li­za­do, como, por ejemplo, .jpg en el caso de los archivos de imagen, para que puedan ser in­te­r­ca­m­bia­dos entre distintas apli­ca­cio­nes. Si el archivo abierto no se co­rre­s­po­n­de con el formato esperado, puede ocasionar problemas. En una versión avanzada, también se pueden examinar funciones im­ple­me­n­ta­das, como pro­ce­di­mie­n­tos de co­m­pre­sión para archivos de vídeo.

Resulta muy laborioso realizar el se­gui­mie­n­to del modo de fu­n­cio­na­mie­n­to de un software. No­r­ma­l­me­n­te consta de varios miles de líneas de código fuente escritas en algún lenguaje de pro­gra­ma­ción. Las ra­mi­fi­ca­cio­nes y las funciones in­te­gra­das hacen que sea demasiado confuso. Además, después de la co­m­pi­la­ción, el código fuente se debe re­s­ta­ble­cer (de­s­co­m­pi­lar), lo que no siempre es posible.

Por ese motivo, el fuzzing adopta otro enfoque: genera todos los datos alea­to­rios ima­gi­na­bles de un tipo es­pe­cí­fi­co. De esta forma, se deberían cubrir la mayor cantidad de variantes de entrada posible. Para ello, el fuzzing co­n­s­ti­tu­ye la interfaz para la in­tro­du­c­ción au­to­ma­ti­za­da. Esto puede rea­li­zar­se a di­fe­re­n­tes niveles. En el caso del fuzzing de apli­ca­cio­nes, por ejemplo, se imitan distintos tipos de datos y se tra­n­s­mi­ten a un programa. También se pueden probar las posibles lo­n­gi­tu­des y los formatos de datos de las in­tro­du­c­cio­nes. En el fuzzing de pro­to­co­los, se utilizan paquetes de datos de ge­ne­ra­ción propia. Otra po­si­bi­li­dad sería la de in­te­r­ce­p­tar co­n­te­ni­dos, ma­ni­pu­lar­los y volverlos a enviar. El fuzzing de formatos de archivo funciona con archivos de prueba generados de forma aleatoria. Algunos de los factores que se someten a prueba son el tamaño, la es­tru­c­tu­ra o los ma­r­ca­do­res es­ta­ble­ci­dos (flags).

El ámbito de apli­ca­ción principal del fuzzing es el control de calidad en el de­sa­rro­llo de software. Gracias al alto grado de au­to­ma­ti­za­ción, es posible comprobar software de forma periódica en un entorno de prueba preparado. Este entorno se puede integrar en el caso de un de­sa­rro­llo ágil de software en procesos ya di­s­po­ni­bles. Sin embargo, también se puede probar software que ya haya sido publicado en el marco de una auditoría de seguridad, como, por ejemplo, para comprobar que cumple según qué fines re­la­cio­na­dos con la seguridad.

Ob­via­me­n­te, el fuzzing puede ayudar a detectar exploits, sin embargo, solo se pueden encontrar indicios sobre errores en las funciones del programa, ya que las he­rra­mie­n­tas de fuzzing no tienen acceso a las es­tru­c­tu­ras internas de los programas que in­s­pe­c­cio­nan.

Existen en el mercado una gran cantidad de he­rra­mie­n­tas de fuzzing, tanto gratuitas como de pago, con distintas gamas de funciones. Aquí te ofrecemos un resumen:

• American Fuzz Lop. Puede de­s­co­m­pi­lar por sí misma el código fuente y después probarlo; por este motivo, el programa también se incluye en la categoría de “fuzzer de caja gris”. Si el código fuente no está di­s­po­ni­ble, genera una emulación mediante QEMU (abre­via­tu­ra de Quick Emulator).
• Fuzzino. Ofrece una bi­blio­te­ca para la ge­ne­ra­ción de datos de entrada con la que se pueden probar apli­ca­cio­nes (orie­n­ta­das a los pro­to­co­los).
• LibFuzzer. Bi­blio­te­ca que forma parte de la in­frae­s­tru­c­tu­ra del co­m­pi­la­dor LLVM.
• Clu­s­te­r­Fu­zz. Entorno de pruebas de­sa­rro­lla­do en su momento por Google para probar el navegador Chrome.
• Sulley. Ofrece una co­m­pi­la­ción de he­rra­mie­n­tas en el lenguaje de pro­gra­ma­ción Python; es es­pe­cia­l­me­n­te apto para casos de prueba sencillos, como la ge­ne­ra­ción de datos alea­to­rios.
• Peach. Solución am­plia­me­n­te au­to­ma­ti­za­da para el fuzz testing de hardware y software.
• Po­we­r­fu­z­zer. Ofrece distintos es­ce­na­rios de ataques, como in­ye­c­cio­nes SQL; se maneja mediante una interfaz de usuario gráfica basada en la web.

En función del fin de la apli­ca­ción, existen al­te­r­na­ti­vas de fuzz testing que siguen otros enfoques y con las que se consiguen otros re­su­l­ta­dos. A co­n­ti­nua­ción, hemos resumido bre­ve­me­n­te las más im­po­r­ta­n­tes para ti.

Para los in­ve­s­ti­ga­do­res de seguridad, la in­ge­nie­ría inversa es una de las he­rra­mie­n­tas estándar. Con ella, se busca la co­m­pro­ba­ción después de la de­s­co­m­pi­la­ción (tra­du­c­ción al lenguaje de pro­gra­ma­ción original) o después del des­en­sa­m­bla­je (tra­du­c­ción al lenguaje cercano a la máquina del en­sa­m­bla­dor). Se trata de un proceso muy laborioso y muy propenso a errores. En caso de éxito, se pueden de­te­r­mi­nar todos los detalles de la fu­n­cio­na­li­dad del programa.

Por de­pu­ra­ción, o debugging, se entiende el proceso de búsqueda de errores en el marco del de­sa­rro­llo de software. Los programas se ejecutan de forma temporal antes de su fi­na­li­za­ción en el entorno de de­sa­rro­llo. El de­sa­rro­lla­dor puede es­ta­ble­cer puntos de in­te­rru­p­ción (brea­k­poi­nts) en los que el programa se detiene. Ahí, puede leer el contenido de las variables uti­li­za­das y comprobar que sean correctas. La de­pu­ra­ción también se puede llevar a cabo en el marco de la in­ge­nie­ría inversa.

Los programas complejos se suelen generar de forma modular. En estos casos, una práctica co­n­so­li­da­da es la co­m­pro­ba­ción de co­m­po­ne­n­tes in­di­vi­dua­les ya en el marco de las de­no­mi­na­das pruebas unitarias en los co­rre­s­po­n­die­n­tes entornos de prueba.

Los errores y los fallos de seguridad en el software vienen aco­m­pa­ña­dos la mayor parte de las veces de una pérdida de prestigio y de confianza en los de­sa­rro­lla­do­res. La carencia absoluta de errores es una utopía, algo que deberían saber también la mayoría de los usuarios de los programas. Sin embargo, el fuzzing es una potente solución con la que cuenta el de­sa­rro­lla­dor para encontrar errores antes de que otros lo hagan. En cualquier caso, el método pro­po­r­cio­na más es­ta­bi­li­dad y seguridad en el software. Un buen motivo para integrar el fuzzing en los controles de calidad.