Muchas compañías aún no son plenamente conscientes de las ventajas de usar fuzzing al desarrollar sus productos de software. Pero la seguridad del producto debe ir junto con el desarrollo. Porque corregir lo que ya se ha hecho requiere mucha mano de obra y es mucho más costoso que hacer el bien de inmediato.
Y esto a pesar del hecho de que conceptos como el Ciclo de vida de desarrollo de seguridad (SDLC), y relativamente recientemente como DevSecOps o SecDevOps, han aparecido en el mundo del desarrollo durante mucho tiempo, pero no todos usan estas técnicas. Tienen una esencia: implementar enfoques para mejorar la seguridad desde las primeras etapas de desarrollo, y es mejor comenzar con la capacitación de los empleados. Y, por supuesto, es importante prestar atención a la seguridad del producto contra ataques durante todo su ciclo de vida. Para más detalles, bienvenido a cat.
Uno de los pasos más importantes para un desarrollo seguro es la confusión. Fuzzing es una técnica de prueba de software, cuya esencia es la detección automática de errores de implementación mediante el envío de datos a sabiendas incorrectos y el análisis de la reacción del programa a ellos.
Justo cuando escribía un artículo en Twitter, las notas parpadeaban sobre el uso de fuzzing de Dmitry Vyukov.
Simplemente llama la atención sobre el hecho de que al usar fuzzing puede detectar una gran cantidad de errores en el código, que de lo contrario no desaparecerán incluso después de un lapso de tiempo.
Por lo general, el fuzzing completa el proceso de desarrollo, pero el fuzzing también puede separar las funciones del producto desarrollado.
Ventajas de difuminar sobre otros métodos de prueba:
- Puede iniciar fuzzer y olvidarse de él hasta el final de la prueba, y trabajar con los resultados;
- las pruebas automatizadas pueden identificar aquellos errores que no se pudieron encontrar mediante pruebas manuales, debido a la mayor cobertura del código;
- le permite recopilar una idea general de la seguridad del código probado.
Uno de los casos sensacionales en que fuzzing hizo su buena acción es el descubrimiento de cincuenta CVE en Adobe Reader en 50 días. Los investigadores pudieron encontrar tantas vulnerabilidades sin acceso al código fuente, y es difícil imaginar cuántas de ellas habrían sido descubiertas si tuvieran la fuente.
Si busca fuentes abiertas para obtener información sobre el uso de fuzzing entre los desarrolladores, Microsoft será el primero. Esta empresa es una de las pioneras en la difusión del SDLC. Tienen Detección de riesgos de seguridad , un servicio que permite a los usuarios descargar archivos binarios para su difuminación. El usuario decide qué datos se enviarán a la entrada. El resultado del fuzzer son los errores encontrados y los datos que los generaron.
Google también usa fuzzing, y tienen muchas herramientas en el dominio público. El más interesante de ellos es OSS-Fuzz . Su esencia es que cualquiera puede hacer una solicitud de extracción con su fuzzer. Por lo general, estos son fuzzers, una vez creados por los desarrolladores para sus pequeños proyectos. Además de estos fuzzers, Google usa ClusterFuzz para detectar errores en Chrome. Durante varios años, se descubrieron más de 16 mil vulnerabilidades en el navegador y más de 11 mil en 160 proyectos de código abierto.
Algunas compañías que desarrollan software proporcionan a todos asambleas nocturnas para difuminar. También lo hacen Mozilla y VLC . Cualquiera puede descargar el ensamblado e intentar buscar errores y vulnerabilidades en él.
Por supuesto, muchos desarrolladores de software propietario guardan silencio sobre cómo aumentan la seguridad de sus productos. Pero el hecho de que muchos de ellos no presten la debida atención a la seguridad de sus productos es evidente en la cantidad de vulnerabilidades detectadas. Por lo tanto, decidimos realizar una encuesta de muestra a los desarrolladores para conocer su actitud frente al fuzzing.
Hicimos las siguientes preguntas:
¿Utiliza fuzzing en su proceso de desarrollo de productos?
Un tercio de los encuestados respondió esta pregunta positivamente.
Si no está usando, ¿por qué? ¿O qué, en su opinión, generalmente le impide incorporar la fase fuzzing en el proceso de desarrollo del producto?
Posibles respuestas:
- Nada que difuminar
- La seguridad del producto no es una prioridad.
- No hay herramientas adecuadas.
- No hay especialistas relevantes.
- Falta de infraestructura apropiada
- Otros
Los encuestados podrían elegir varias razones para negarse a usar fuzzing en el proceso de desarrollo.
El diagrama muestra el porcentaje de relevancia de las razones para rechazar la confusión en el proceso de desarrollo.
La razón más común para NO usar fuzzing fue la falta de empleados calificados en esta área. Pero no siempre es necesario tener sus propios expertos en seguridad de la información, puede atraer a expertos externos que auditarán los productos desarrollados.
Algunos de los encuestados que eligieron la opción de respuesta "Otro" dieron respuestas detalladas interesantes. Estas son algunas de las razones para rechazar el fuzzing:
- el departamento de seguridad de la información no agradeció la iniciativa de uno de los desarrolladores para escribir su fuzzer;
- falta de técnicas de búsqueda de vulnerabilidad FSTEC.
Entre las respuestas se encuentran aclaraciones sobre el uso de fuzzers AFL y libfuzzer , lo cual es una buena noticia .
Nosotros, como expertos en seguridad, le aconsejamos que no descuide el desarrollo seguro, incluido el uso de fuzzing, para aumentar la seguridad de sus productos.