
Un fuzzer multiplataforma para sondear binarios de espacio de usuario, clientes y servidores de red.
Un fuzzer multiplataforma para probar binarios en espacio de usuario, clientes y servidores.
Ha encontrado errores en más de 50 aplicaciones y bibliotecas de empresas importantes y código abierto.
Configuración simple para comenzar a fuzzear en Linux, Mac y Windows.
Litefuzz está diseñado para cumplir un propósito: fuzzear y hacer triage en todas las plataformas principales, soportar aplicaciones CLI/GUI, clientes y servidores de red para encontrar errores relacionados con la seguridad.
Simplifica el proceso y facilita el descubrimiento de fallos de seguridad en muchos objetivos diferentes, en múltiples plataformas, haciendo solo algunas concesiones honestas.
No está construido para velocidad, escalabilidad ni para ganar premios académicos. Aplica técnicas simples desde varios ángulos para obtener resultados. Para fuzzing de archivos por consola, probablemente deberías usar AFL. Tiene un rendimiento superior, capacidades de instrumentación (y ejecuciones no instrumentadas más rápidas), escalabilidad y puede generar jpegs de la nada. Para fuzzing de red, el mutiny fuzzer también funciona bien si tienes PCAPs para reproducir, y frizzer parece prometedor. Pero si quieres probar este, puede fuzzear ese tipo de objetivos en todas las plataformas con una sola herramienta.
./ y dale a tu objetivo... un lite fuzz.``` $ sudo apt install -y latex2rtf
$ ./litefuzz.py -l -c "latex2rtf FUZZ" -i input/tex -o crashes/latex2rtf -n 1000 -z --========================-- --======| litefuzz |======-- --========================--
[STATS] run id: 3516 cmdline: latex2rtf FUZZ crash dir: crashes/latex2rtf input dir: input/tex inputs: 1 iterations: 1000 mutator: random(mutators)
@ 1000/1000 (3 crashes, 127 duplicates, ~0:00:00 remaining)
[RESULTS]
completed (1000) iterations with (3) unique crashes and 127 dups
check crashes/latex2rtf for more details
Este es un objetivo local simple que AFL++ es perfectamente capaz de manejar y que se da solo como un ejemplo rápido. Litefuzz fue diseñado para hacer mucho más en cuanto a fuzzing de red y GUI, como verás una vez que profundices.
## por qué
Sí, otro fuzzer y uno que no sigue muy bien las tendencias y convenciones actuales. Se hicieron concesiones para abordar ciertos requisitos. Estos requisitos son un fuzzer que funcione por defecto en múltiples plataformas, fuzze tanto objetivos locales como de red y sea muy fácil de usar. No se intenta convencer a nadie de nada, pero proporcionemos algo de contexto. Algunos objetivos requieren mucho esfuerzo para integrar fuzzers como AFL en la cadena de compilación. Esto no es un problema, ya que este fuzzer no requiere instrumentación, sacrificando la cobertura precisa obtenida por la instrumentación por la facilidad y portabilidad. AFL tampoco soporta fuzzing de red de forma nativa, y aunque hay proyectos basados en él que sí lo hacen, están lejos de ser sencillos de usar y generalmente requieren más modificaciones de código y arneses para funcionar (historia similar con [Libfuzzer](https://llvm.org/docs/LibFuzzer.html)).
No hace fuzzing paralelo, ni soporta nada como las mejoras de velocidad vertiginosas que [el modo persistente](https://lcamtuf.blogspot.com/2015/06/new-in-afl-persistent-mode.html) puede proporcionar, por lo que no puede escalar ni cerca de lo que pueden hacer los fuzzers con tales capacidades. Nuevamente, este no es un fuzzer de última generación. Pero no requiere código fuente, configurar correctamente una compilación o ciertas características del SO. Incluso puede fuzzear algunas GUI de clientes de red y aplicaciones interactivas. Vive de lo que ofrece el sistema en muchos aspectos y muchas de las características, como los mutadores y la minimización, se escribieron desde cero.
Fue diseñado para 'simplemente funcionar' y se ha invertido esfuerzo en automatizar la configuración e instalación de las pocas dependencias que necesita. Este fuzzer fue escrito para cumplir un propósito, proporcionar valor en muchos escenarios y entornos de objetivos diferentes y, lo más importante, y por lo que todos los fuzzers deberían ser juzgados en última instancia: la capacidad de encontrar errores. Y **encuentra** [errores](https://github.com/sec-tools/beta/blob/main/README.md#trophies). No presupone que exista código fuente del objetivo, por lo que puede cubrir software cerrado bastante bien. Puede ejecutarse como parte de automatización con poca modificación, pero está orientado a ser divertido de usar para investigadores de vulnerabilidades. Sin embargo, es más útil pensar en él como un proyecto de I+D más que como un producto completamente terminado. Además, no hay una configuración complicada donde esté ligeramente roto desde el primer momento o necesite más trabajo para funcionar en sistemas operativos modernos.