litefuzz

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

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. Ha sido probado funcionando en Ubuntu Linux, Mac y Windows y viene con scripts completamente funcionales que hacen casi todo por ti para configurar un entorno listo para fuzzear. **Una vez que el script de configuración se completa, solo toma unos minutos comenzar a fuzzear un montón de objetivos diferentes.** ## cómo funciona **Litefuzz soporta tres modos diferentes: local, cliente y servidor.** Local significa apuntar a binarios locales, que en Linux/Mac se lanzan mediante subprocesos con soporte automático de clasificación (triage) mediante GDB y LLDB respectivamente en caso de fallos, y mediante [WinAppDbg](https://github.com/MarioVilas/winappdbg) en Windows. Los fallos se escriben en un directorio local de fallos y se ordenan por tipo de fallo, como AV de lectura/escritura o SIGABRT/SIGSEGV, junto con los hashes de los archivos. Todos los fallos únicos se clasifican a medida que se fuzzea y estos datos, junto con la salida del objetivo (cuando esté disponible), también se capturan y se colocan como artefactos en el mismo directorio. También es posible reproducir fallos con `--replay` y proporcionando el archivo causante. En el modo `local` cliente, el directorio de entrada debe contener un saludo del servidor, respuesta u otros datos que un cliente esperaría al conectarse a un servidor. Por ahora, solo se ha implementado un 'disparo' para fuzzing de red sin soporte de sesiones complejas. El cliente se lanza desde la línea de comandos y se depura de la misma manera que cuando se fuzzean archivos. Se configura un listener para soportar este escenario, sí, es lento y casi trabajo manual, pero funciona. Si se detecta un fallo, se reproduce en gdb para obtener los detalles de clasificación. En el modo `remote` cliente, esto funciona igual, excepto que no hay depuración local / clasificación de fallos. En el modo *local* servidor, es similar al modo local cliente, y para el modo `remote` servidor, simplemente se conecta a un objetivo especificado y envía datos de muestra mutados que el usuario especifica como entradas, pero solo se proporciona una clasificación simple de '¿todavía podemos conectar? Si no, probablemente falló en el último'. Hay algunas funciones de mutación escritas desde cero que principalmente hacen mutaciones aleatorias con una selección aleatoria de entradas especificadas por la bandera `-i`. Para fuzzing de archivos, simplemente selecciona el modo local y pásale la línea de comandos del objetivo con FUZZ indicando dónde espera la aplicación el nombre del archivo para analizar, por ejemplo, `tcpdump -r FUZZ` junto con un directorio de entrada de 'buenos archivos' para mutar. Para fuzzing de cliente de red, es similar al fuzzing local, pero también proporciona detalles de conexión mediante `-a`. Y si quieres fuzzear servidores, usa el modo servidor y proporciona un `protocolo://dirección:puerto` igual que para los clientes. Fuzzea tan rápido como el objetivo pueda consumir los datos y salir, como es el caso de la mayoría de las aplicaciones CLI, o durante el tiempo que hayas determinado que necesita antes de que la ejecución local o la conexión de red se agote, lo que puede ser mucho más lento. No hay trucos sofisticados de exec o kernel aquí. Pero, por supuesto, si escribes un harness que analice la entrada y salga rápidamente, cubriendo una parte específica del objetivo, eso también ayuda. Pero en ese punto, si puedes acercarte tanto al objetivo, probablemente sea mejor que uses el [modo persistente](https://lcamtuf.blogspot.com/2015/06/new-in-afl-persistent-mode.html) o características similares que otros fuzzers pueden ofrecer. En resumen... ### lo que hace - funciona en linux, windows y mac y soporta py2/py3 - fuzzea binarios CLI/GUI que leen de archivos/stdin - fuzzea clientes y servidores de red, de código abierto o propietarios, disponibles para depurar local o remotamente - diferencias (diffs), minimización, reproducción, ordenación y clasificación automática de fallos - cosas varias como soporte TLS, fuzzing de binarios golang y algunos extras para Mac - muta la entrada con varios mutadores incorporados + pyradamsa (Linux) ### lo que no hace - instrumentación nativa - escalar con trabajos concurrentes - fuzzing de sesiones complejas - monitoreo remoto de cliente y servidor (solo verificaciones básicas, ej. conectar) ## soporte Probado principalmente en **Ubuntu Linux 20.04** (22.04 y 21.04 ligeramente probados), **Windows 10** y **Mac OS 11** (12 ligeramente probado). El fuzzer y los scripts de configuración pueden funcionar en versiones ligeramente más antiguas o más nuevas de estos sistemas operativos también, pero la mayor parte de la investigación, pruebas y desarrollo ocurrieron en estos entornos. Python3 es compatible y se hizo un esfuerzo para hacer el código compatible con Python2 también, ya que es necesario para fuzzing en Windows a través de [WinAppDbg](https://github.com/MarioVilas/winappdbg). Las pruebas de plataforma ocurrieron principalmente en hardware basado en Intel, pero las cosas parecen funcionar mayormente también en la plataforma M1 de Apple (excepciones notables: en Linux, el plugin exploitable para GDB probablemente no sea compatible, ni Pyradamsa). También hay scripts de configuración en setup/ para automatizar la mayoría o todas las tareas e instalación de dependencias. Generalmente puede fuzzear binarios nativos en cada plataforma, que a menudo están compilados en C/C++, pero también atrapa fallos para binarios Golang (experimental). ### versiones de python Python3 es compatible para Linux y Mac, mientras que Python2 es necesario para Windows. ¿Por qué Py3 para Linux y Mac? Pyautogui, Pyradamsa (solo Linux), mejor soporte de sockets en Mac. ¿Por qué Py2 para Windows? Winappdbg requiere Py2. ### linux GDB para depuración y [exploitable](https://github.com/jfoote/exploitable) para clasificación de fallos. Si es OSS, puedes construir e instrumentar el objetivo con [sanitizers](https://fuzzing-project.org/tutorial2.html) y demás, de lo contrario hay algunos [depuradores de memoria](https://en.wikibooks.org/wiki/Linux_Applications_Debugging_Techniques/Heap_corruption) que podemos cargar en tiempo de ejecución. Esta instalación, junto con las dependencias de python y otras cosas útiles, se ha automatizado con [setup/linux.sh](https://github.com/sec-tools/litefuzz/blob/main/setup/linux.sh). El SO recomendado es Ubuntu 20.04, ya que allí ocurrió la mayoría de las pruebas. ### mac En lugar de gdb, usamos lldb para depurar en OS X, ya que viene incluido con las herramientas de línea de comandos de XCode. Ser administrador o estar en el grupo de desarrolladores debería permitirte usar lldb, pero este comportamiento puede variar según los entornos y versiones, y es posible que necesites ejecutarlo con privilegios sudo si todo lo demás falla. Lo único que tendrás que hacer manualmente es desactivar SIP (en recovery, mediante cmd+R o usar trucos de vmware fusion). De lo contrario, la clasificación automática fallará al fuzzear en el SO de Tim Apple. Casi toda la configuración se ha automatizado con el script [setup/mac.sh](https://github.com/sec-tools/litefuzz/blob/main/setup/mac.sh), así que puedes ejecutarlo para un inicio rápido. ### windows [WinAppDbg](https://github.com/MarioVilas/winappdbg) se usa para depurar en Windows con la pequeña salvedad de que el fuzzing por stdin no es compatible. Al igual que las configuraciones automatizadas para los otros sistemas operativos, chocolatey ayuda a automatizar la instalación de paquetes en windows. Ejecuta [setup/windows.bat](https://github.com/sec-tools/litefuzz/blob/main/setup/windows.bat) en el directorio raíz de litefuzz como Administrador para automatizar las instalaciones. Instalará herramientas de depuración y otras dependencias para que todo funcione sin problemas. ### objetivos Esta es una lista de los tipos de objetivos que se han probado y que generalmente son compatibles. * Aplicaciones CLI/GUI locales que analizan formatos de archivo o stdin - soporte de depuración * Cliente de red CLI/GUI local que analiza respuestas del servidor - soporte de depuración para CLI - soporte de depuración limitado para GUI * Servidor de red CLI local que analiza peticiones de clientes - soporte de depuración (salvedad: debe poder ejecutarse como ejecutable independiente, de lo contrario puede tratarse como *remoto*) * Servidor de red GUI local que analiza peticiones de clientes - teóricamente compatible, no probado * Cliente de red CLI/GUI remoto que analiza respuestas del servidor - sin soporte de depuración * Servidor de red CLI/GUI remoto que analiza peticiones de clientes - sin soporte de depuración - excepción en Mac usando las características `attach` o `reportcrash` Nuevamente, el fuzzer puede ejecutarse y soportar aplicaciones, clientes y servidores locales en Linux, Mac y Windows y, por supuesto, puede fuzzear cosas remotas independientemente de la plataforma objetivo. ### triage * Aplicaciones CLI/GUI locales que analizan formatos de archivo o stdin - ejecutar la aplicación, capturar señales, reproducir ejecutándola de nuevo dentro de un depurador con el archivo causante * Cliente de red CLI/GUI local que analiza respuestas del servidor - ejecutar la aplicación, capturar señales, reproducir ejecutándola de nuevo dentro de un depurador con el archivo causante * Servidor de red GUI/CLI local que analiza peticiones de clientes - ejecutar la aplicación en el depurador, capturar señales, reproducir ejecutándola de nuevo dentro de un depurador con el archivo causante * Cliente de red CLI/GUI remoto que analiza respuestas del servidor - sin visibilidad, recopilar fallos desde el lado remoto - se pueden escribir scripts de apoyo manualmente para ayudar en la clasificación * Servidor de red CLI/GUI remoto que analiza peticiones de clientes - sin visibilidad, recopilar fallos desde el lado remoto - se pueden escribir scripts de apoyo manualmente para ayudar en la clasificación - excepción en Mac son las opciones `attach` y `reportcrash`, que se pueden usar para habilitar algunas capacidades de clasificación ## primeros pasos La mayor parte de la configuración entre plataformas se ha automatizado con los scripts en el directorio [setup](https://github.com/sec-tools/litefuzz/blob/main/README.md#setup). Simplemente ejecuta esos desde la raíz de litefuzz y debería ahorrarte mucho tiempo y ayudar a habilitar parte de lo necesario para despliegues automatizados. Es útil usar una VM para configurar un SO limpio y un entorno de fuzzing, ya que entre otras cosas sus capacidades de instantáneas son prácticas. Consulta [INSTALL.md](https://github.com/sec-tools/litefuzz/blob/main/INSTALL.md) para más detalles. **Después de la instalación, consulta el ejemplo de fuzzing de latex2rtf en la sección inicial para una ejecución rápida o sumérgete en todas las opciones de línea de comandos y ejemplos adicionales detallados en este README.** ### docker Puedes ejecutar litefuzz usando Docker con el `Dockerfile` sin instalar dependencias localmente. Esto es especialmente útil para pruebas rápidas o si quieres evitar instalar dependencias en tu sistema. El Dockerfile funciona tanto: - **Desde dentro del repositorio** - Usa archivos locales (más rápido, incluye cambios locales) - **Independiente** - Se puede construir desde cualquier directorio (clona desde GitHub)```bash # Build the Docker image (from any directory with Dockerfile) docker build -t litefuzz:latest . # Run litefuzz docker run --rm litefuzz:latest python3 litefuzz.py --help

Esto ejecutará pytest para `test_litefuzz.py` en el directorio principal y proporcionará resultados PASS/FAIL una vez que finalice la ejecución de la prueba. #### pruebas de aplicaciones que fallan Algunos ejemplos de aplicaciones con errores para probar las capacidades de detección de fallos y clasificación en las diferentes plataformas se pueden encontrar en la carpeta `test`. - (a) desreferencia de puntero nulo - (b) división por cero - (c) desbordamiento de montón - (d-gui) error de cadena de formato en una GUI - (e) desbordamiento de búfer en el cliente - (f) desbordamiento de búfer en el servidor Se construyen automáticamente durante la configuración y puedes ejecutarlos en la línea de comandos, en un depurador o usarlos para realizar pruebas como objetivos de fuzzing. **Si se ejecuta en la línea de comandos de Windows, revisa `Event Viewer -> Windows Logs -> Application` para ver los fallos.** ## opciones Hay una gran cantidad de opciones y características diferentes para aprovechar varios escenarios objetivo. A continuación se presenta una breve explicación y algunos ejemplos para ayudar a entender cómo usarlos. ### directorio de fallos `-o` te permite especificar un directorio de fallos distinto al predeterminado, que es crashes/ en la ruta local. Se puede usar esto para gestionar carpetas de fallos para varias ejecuciones de fuzzing concurrentes para diferentes aplicaciones al mismo tiempo. ### modo de aislamiento `-u` aísla la aplicación objetivo del proceso normal de fuzzing, p. ej., ejecuciones o envío repetido de paquetes y comprobación de fallos. En cambio, este modo fue creado para aplicaciones cliente interactivas, p. ej., Postman donde puedes hacer scripting dentro de la aplicación para repetir conexiones para fuzzing del cliente. El objetivo se ejecuta dentro de un depurador, el fuzzer se pausa para dar tiempo al usuario de hacer clic en algunos botones o configurar el objetivo para que se ejecute automáticamente, el usuario reanuda y ahora estás fuzzing clientes de red interactivos. `litefuzz -lk -c "/snap/postman/140/usr/share/Postman/_Postman" -i input/http_responses -a tcp://localhost:8080 -u -n 100000 -z` El modo de aislamiento + actualización se puede usar para clientes interactivos, p. ej., ejecutar FileZilla en un depurador, pero presionando F5 repetidamente para que se reconecte al servidor en cada nueva iteración. Además, los servidores CLI/GUI locales de fuzzing solo se inician y ejecutan una vez dentro de un depurador para hacer el proceso un poco más eficiente. `--key` también te permite enviar teclas mientras se fuzzean objetivos interactivos, como fuzzing del análisis de respuestas del servidor FTP de FileZilla enviando "refresh connection" con F5. `litefuzz -lk -c "filezilla" -a tcp://localhost:2121 -i input/ftp/filezilla -u -pp --key "F5" -n 100 -z glibc` nota: el modo de aislamiento solo se ha probado en Linux y no es compatible con Windows. ### tiempo de espera `-x secs` te permite especificar un tiempo de espera. En la práctica, esto es más bien "aproximadamente cuánto tiempo entre iteraciones" para objetivos CLI y un tiempo de espera real para GUI. ### mutadores `--mutator N` especifica qué mutador usar para fuzzing. Si no se proporciona la opción, se elige una selección aleatoria de la lista de mutadores disponibles para cada iteración de fuzzing. Estos mutadores fueron escritos desde cero (con la excepción de Radamsa, por supuesto). Y aunque han sido probados exhaustivamente y han funcionado bastante bien durante millones de iteraciones, pueden tener errores sutiles de vez en cuando, pero en general esto no debería afectar la funcionalidad.``` FLIP_MUTATOR = 1 HIGHLOW_MUTATOR = 2 INSERT_MUTATOR = 3 REMOVE_MUTATOR = 4 CARVE_MUTATOR = 5 OVERWRITE_MUTATOR = 6 RADAMSA_MUTATOR = 7

### pause Presiona ctrl+c para pausar el proceso de fuzzing. Si quieres reanudar, elige `y` o `n` para detener. Esta función funciona bien en varias plataformas, pero puede ser menos confiable al fuzzear aplicaciones GUI. ### reutilizando crashes para encontrar variantes `-e` habilita el modo de reutilización. Esto significa que si se encontraron crashes durante la ejecución de fuzzing, se usarán como entradas para una segunda ronda de fuzzing que puede ayudar a descubrir aún más bugs. Combínalo con `-z` para bugs `-ez`! Da-duph. El siguiente ejemplo está fuzzeando antiword con 100000 iteraciones y luego inicia otra ejecución con el mismo número de iteraciones y opciones para reutilizar los crashes como entrada e intentar extraer aún más bugs. `litefuzz -l -c "antiword FUZZ" -i docs -n 100000 -ez` (o uno podría copiar manualmente los crashes a un directorio de entrada para controlar directamente las iteraciones para la ejecución de reutilización) `litefuzz -l -c "antiword FUZZ" -i docs-crashes -n 500000 -z` nota: este modo solo es compatible con aplicaciones locales. ### ayudantes de depuración de memoria `-z` habilita Electric Fence (o depuración de malloc de glib como alternativa) en Linux, Guard Malloc en Mac y PageHeap en Windows. Además, `-zz` se puede usar para deshabilitar PageHeap después de habilitarlo para una aplicación. Si solo quieres activarlo/desactivarlo sin iniciar el fuzzer, simplemente omite la bandera `-i`. Durante la configuración de Windows, se instala [gsudo](https://github.com/gerardog/gsudo) y se puede usar para ejecutar comandos elevados en la línea de comandos, como activar PageHeap para los objetivos. `sudo litefuzz -l -c "notepad FUZZ" -i texts/files -z` `sudo litefuzz -l -c "notepad FUZZ" -zz` En Linux, se pueden elegir ayudantes específicos. Por ejemplo, en lugar de solo usar malloc de glib como alternativa, se puede seleccionar. `litefuzz -l -c "geany FUZZ" -i texts/codes -z glibc` El depurador malloc predeterminado de Electric Fence es excelente, pero no funciona con todos los objetivos. Puedes probar el objetivo con EF y si falla, selecciona el ayudante glibc en su lugar. ### verificando la salida en vivo del objetivo Si estás fuzzeando aplicaciones locales en Linux o Mac, puedes `cat /tmp/litefuzz/RUN_ID/fuzz.out` para verificar cuál fue la última salida estándar del objetivo. `RUN_ID` se muestra en el área de información STATS cuando comienza el fuzzing. En caso de que ocurra un crash, la salida estándar también se captura en el directorio de crashes como el archivo `.out`. La salida estándar/error global también va a `/tmp/litefuzz/out` con fines de depuración para todos los objetivos de fuzzing, con la excepción de los modos aislados o de servidor local, cuya salida del depurador va a `/tmp/litefuzz/RUN_ID/out`. Winappdbg no admite de forma nativa la captura de la salida estándar de los objetivos (según tengo entendido), por lo que este artefacto no está disponible en Windows. ### modos cliente y servidor Si el servidor se puede ejecutar localmente simplemente ejecutando el binario (con o sin algunas banderas y configuración), puedes pasar su línea de comandos con `-c` y se iniciará, fuzzeará y eliminará con una nueva ejecución en cada iteración. La idea aquí es intercambiar velocidad por la capacidad de evitar esos molestos bugs que se activan solo después de que la memoria del objetivo está en un "cierto estado", lo que puede llevar a falsos positivos. Lo mismo ocurre al fuzzear localmente clientes de red. Incluso admite conexiones TLS, generando certificados sobre la marcha (permitiendo al usuario proporcionar un certificado de cliente al fuzzear un servidor que lo requiera y el fuzzing de certificados en sí son otras ideas aquí). Litefuzz no proporciona soporte de depuración al fuzzear clientes y servidores remotos, por lo que la configuración en ese extremo remoto queda a cargo del usuario. Para servidores, simplemente verificamos si el servidor dejó de responder y anotamos el payload anterior como el causante del crash. Esto funciona bien para conexiones TCP, pero no tenemos ese lujo para servicios UDP, por lo que la supervisión del servidor remoto queda a cargo de la función ReportCrash (disponible en Mac), ejecutando el objetivo en un depurador (a través del modo de servidor local o manualmente) o creando scripts de soporte personalizados. Además, algunos servidores pueden reiniciarse automáticamente o recuperarse de otra manera después de un crash, pero puede haber señales de esto en los logs u otros artefactos en el sistema de archivos que pueden ser analizados por scripts de soporte escritos para un objetivo en particular. ### ejemplos de red local `litefuzz -lk -c "wget http://localhost:8080" -a tcp://localhost:8080 -i input/http -z` `litefuzz -lk -c "curl -k https://localhost:8080" -a tcp://localhost:8080 -i input/http -z` `litefuzz -lk -c "curl -k https://localhost:8080" -a tcp://localhost:8080 -i input/http -o crashes/curl --tls -n 100000 -z` (abre Wireshark y captura la respuesta de un d, haz clic derecho en Simple Network Management Protocol -> Export Packet Bytes -> resp.bin) `litefuzz -lk -c "snmpwalk -v 2c -c public localhost:1616 1.3.6.1.2.1.1.1" -a udp://localhost:1616 -i input/snmp/resp.bin -n 1 -d -x 3` `litefuzz -ls -c "./sc_serv shoutcast.conf" -a localhost:8000 -i input/shouts -z` `litefuzz -ls -c "snmpd" -i input/snmp -a udp://localhost:161 -z` **notas rápidas** - Los sockets UDP pueden comportarse de manera extraña en Mac + Py2, por lo que solo Mac + Py3 ha sido probado y compatible - El fuzzing de clientes de red local en Windows puede ser buggy y debe considerarse experimental en este momento ### ejemplos de red remota Fuzzear clientes y servidores remotos es un poco más desafiante: no tenemos depuración local y dependemos de detectar una detención en la interacción entre las dos partes a través de la red para detectar crashes. Además, dado que supuestamente estamos ciegos a lo que sucede en el otro extremo, el fuzzing termina cuando el cliente o servidor deja de responder y necesita reiniciarse manualmente después de que el cliente o servidor se restaura a un estado normal (sin crash) a menos que el usuario tenga scripts de configuración en el lado remoto para gestionar este proceso. UDP complica aún más esto. Incluso enviar un paquete de prueba para ver si hay un servicio escuchando en un puerto UDP no garantiza una respuesta. Por lo tanto, es posible fuzzear clientes y servidores de red de forma remota, pero hay una compensación en la visibilidad. #### cliente `while :; do echo "user test\rpass test\rls\rbye\r" | ftp localhost 2121; sleep 1; done` `litefuzz -k -i input/ftp/test -a tcp://localhost:2121 -pp -n 100` El modo cliente es más delicado aquí porque es difícil saber si un cliente realmente ha fallado y por eso no se reconecta, o si el baile de envío/recepción simplemente no funciona, ya que diferentes clientes pueden manejar las conexiones como quieran. También ten en cuenta que esto es solo un ejemplo y que el fuzzing remoto de clientes por naturaleza es complicado y debe considerarse algo experimental. #### servidor Los pros y contras de fuzzear un servidor local o remotamente pueden ayudarte a decidir cómo abordar un objetivo cuando ambas opciones están disponibles. Básicamente, fuzzear con el servidor en un depurador será más lento pero podrás obtener registros de crashes con el triage automático, mientras que fuzzear el servidor en modo remoto (incluso apuntándolo a localhost) será mucho más rápido en promedio, pero pierdes la alta visibilidad y las capacidades de triage basadas en depurador, pero te dará tiempo para reiniciar manualmente el servidor después de cada crash para continuar antes de que salga (solo servidores TCP, la función no admite servidores basados en UDP). **Shoutcast** `./sc_serv ...` `litefuzz -s -a localhost:8000 -i input/shouts -n 10000` **SSHesame** `sshesame` `litefuzz -s -a tcp://target:2022 -i input/ssh-server -p -n 1000000 -x 0.05` **FTP** `litefuzz -s -a tcp://target:21 -i input/ftp/req.txt -pp -n 1000` **DNS** `coredns -dns.port 10000` `litefuzz -ls -c "coredns -dns.port 10000" -a udp://localhost:10000 -i dns-req/1.bin -o crashes/coredns -n 10000` o `litefuzz -s -a udp://localhost:10000 -i dns-req/1.bin -o crashes/coredns -n 10000` ##### TLS `litefuzz -s -a tcp://hostname:8080 -i input/http --tls -n 10000```` ... @ 48/10000 (1 crashes, 0 duplicates, ~7:13:18 remaining) [!] check target, sleeping for 60 seconds before attempting to continue fuzzing...

El fuzzer divide cada línea en su propia respuesta FTP para intentar fuzzing del manejo de una sesión por parte de un cliente. Sin embargo, no hay garantía de que un cliente se "comporte" o actúe de formas que no permitan completar una sesión correctamente, por lo que algo de prueba y error más ajustes finos para casos de prueba de sesión mientras se ejecuta Wireshark puede ser útil para entender las diferencias en la interacción entre objetivos. `litefuzz -lk -c "ftp localhost 2121" -a tcp://localhost:2121 -i input/ftp -o crashes/ftp -n 100000 -pp -z` Esto también se puede combinar con *-u* para aislar objetivos de red con GUI como FileZilla. `litefuzz -lk -c "filezilla" -a tcp://localhost:2121 -i input/ftp.resp -n 100000 -u -pp -z glibc` ### adjuntarse a un proceso Si el objetivo genera un nuevo proceso al conectarse, se puede especificar el nombre de un proceso (o pid) al que adjuntarse después de que se haya establecido una conexión con el servidor. Esto es útil en casos donde, por ejemplo, launchd está escuchando en un puerto y solo lanza el proceso de manejo una vez que un cliente está conectado. Esta es una característica que desdibuja un poco la línea entre fuzzing local y remoto, ya que técnicamente el fuzzer está en modo remoto, pero especificamos la dirección objetivo como localhost y le pedimos que se adjunte a un proceso. `./litefuzz.py -s -a tcp://localhost:8080 -i input/shareserv -p --attach ShareServ -x 1 -n 100000` nota: actualmente esta característica solo es compatible en Mac (LLDB) y para fuzzing de red, aunque si se implementa, debería funcionar bien en Linux (GDB) también. ### artefactos de fallo Cuando se encuentra un fallo durante el fuzzing, se reproduce en un depurador para producir artefactos de depuración e información de categorización. La información varía de una plataforma a otra, pero generalmente se produce un archivo de texto con un backtrace, información de registros, cosas del tipo `!exploitable` (donde esté disponible) y otra información básica. **Los volcados de memoria** se pueden habilitar en Windows pasando `--memdump` o deshabilitar con `--nomemdump` de manera similar a como se controlan los depuradores de malloc con `-z` y `-zz` respectivamente. Si está habilitado, el volcado también se cargará en el depurador de consola (cdbg) y la salida del análisis de fallo `!analyze -v` se captura dentro de un archivo de registro de análisis de fallo de volcado de memoria adicional. Winappdbg ya tiene análisis del tipo !exploitable que obtenemos en el análisis inicial del fallo, así que aquí solo hacemos !analyze. `litefuzz -l -c "C:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\AcroRd32.exe" --memdump` o para deshabilitar volcados de memoria para una aplicación `litefuzz -l -c "C:\Program Files (x86)\Adobe\Acrobat Reader DC\Reader\AcroRd32.exe" --nomemdump` Además del triaje automático de fallos, también se producen diferencias binarias/de cadenas (según corresponda) y la salida estándar del objetivo (dependiente de la plataforma/objetivo), así como los archivos de reproducción. Para fuzzing local, los artefactos generalmente incluyen diferencias, salida estándar (solo linux/mac), archivo de reproducción y el registro de fallo y archivo de información.``` $ ls crashes/latex PROBABLY_EXPLOITABLE_SIGSEGV_XXXX5556XXXX_YYYYa39f3fd719e170234435a1185ee9e596c54e79092c72ef241eb7a41cYYYY.diff PROBABLY_EXPLOITABLE_SIGSEGV_XXXX5556XXXX_YYYYa39f3fd719e170234435a1185ee9e596c54e79092c72ef241eb7a41cYYYY.diffs PROBABLY_EXPLOITABLE_SIGSEGV_XXXX5556XXXX_YYYYa39f3fd719e170234435a1185ee9e596c54e79092c72ef241eb7a41cYYYY.out PROBABLY_EXPLOITABLE_SIGSEGV_XXXX5556XXXX_YYYYa39f3fd719e170234435a1185ee9e596c54e79092c72ef241eb7a41cYYYY.tex PROBABLY_EXPLOITABLE_SIGSEGV_XXXX5556XXXX_YYYYa39f3fd719e170234435a1185ee9e596c54e79092c72ef241eb7a41cYYYY.txt

# trofeos Litefuzz ha encontrado fallos en varios paquetes de software como... * antiword * AppleScript (OS X) * ArangoDB VelocyPack * Avast authenticode-parser * Avast RetDec * BBC Audio Waveform * ColorSync (OS X) * Dynamsoft BarcodeReader * eot2ttf * evernote2md * faad2 * Facebook's Origami Studio * FontForge * ForestDB * Gifsicle * GPUJPEG * GPAC Multimedia Framework * Google Draco * Google Quipper * GoPro GPR * GtkRadiant * IIPImage Server * John The Ripper * Kyoto Cabinet * latex2rtf * libMeshb * libembroidery * libsndfile * Lion Vector Graphics (lvg) * L-SMASH * mp3-decoder * MindNode * minimp4 * MiniWeb Server * MLpack * Nvidia Data Center GPU Manager * Numbers (OS X) * OpenJPEG * OpenOrienteering Mapper * OSM Express * Pages (OS X) * PBRT-Parser * Pixar USD * Remote Apple Events (OS X) * Samsung rlottie * Samsung ThorVG * Shoutcast Server * Silo * syslog (OS X) * Tencent NCNN * TinyXML2 * UEFITool * Ulfius Web Framework * zlib # Preguntas frecuentes ## ¿cómo surgió este proyecto? ¡Fuzzing es divertido! Y es agradable hacer proyectos que adopten una postura contraria, donde los fuzzers no siempre tienen que seguir los enfoques modernos o populares para lograr el objetivo final de encontrar errores. Ya sea que estés cerca del hardware, obteniendo cobertura de código en todos los caminos o simplemente optimizando la rapidez y flexibilidad, la forma fundamental de "invalidar suposiciones" de hacer las cosas, etc. Sin embargo se manifieste, disfrútalo. ## ¿este proyecto se mantiene activamente? Por favor, no esperes soporte activo o mantenimiento del proyecto. Siéntete libre de bifurcarlo para agregar nuevas funciones o corregir errores, etc. Incluso haz un PR para cosas pequeñas, aunque no tengas expectativas de respuestas o solución de problemas. No está previsto que el desarrollo en este repositorio sea activo. ## ¿cómo sabes que el fuzzer funciona bien y lo mediste contra otros? El propósito de Litefuzz es encontrar errores en distintas plataformas. Y lo hace. Así que, honestamente, la capacidad de medirlo contra fuzzerX o fuzzerY simplemente no fue prioritaria. Se tomaron ciertas concesiones y se reconocieron desde el inicio; consulta la [#intro](https://github.com/sec-tools/litefuzz/blob/main/README.md#intro) para más detalles. ## ¿qué cambiarías si lo reescribieras hoy? Funciona bastante bien tal como está y se ha probado en una gran cantidad de objetivos y escenarios diferentes. Dicho esto, podría beneficiarse de estandarizar un sistema más modular y basado en plugins donde cambiar entre objetivos y plataformas no requiriera tantas comprobaciones adicionales en la parte operativa del código, etc. Por supuesto, tener pruebas más formales y un sistema de despliegue que lo probara en los sistemas operativos compatibles crearía un entorno más fácil de trabajar al hacer cambios en las funciones principales. Creció de un proyecto pequeño pero ambicioso a algo un poco más grande bastante rápido. ## ¿qué tan estable es litefuzz? La línea de comandos, la interfaz gráfica, el fuzzing de red (principalmente en Linux y Mac), la minimización, etc., se han probado bastante a fondo y deberían ser bastante sólidos en general. Algunas de las características más exóticas, como el fuzzing de red con GUI aislada, el soporte de ReportCrash para Mac y otras funciones especializadas deben considerarse experimentales. ## ¿hay escenarios no soportados para litefuzz? Algunos, sí. Pero la mayoría son escenarios poco comunes que son problemáticos, requieren más tiempo e investigación para "hacerlos bien" o simplemente no funcionan por razones relacionadas con la plataforma. Muchos de ellos salen explícitamente con un mensaje de "no soportado" cuando intentas ejecutarlos con dichas opciones, y algunas advertencias se han mencionado en las secciones anteriores al describir varias características. Algunos de los más matizados incluyen que el modo de reproducción en aplicaciones *aisladas* no es compatible y también se han realizado pruebas limitadas en aplicaciones de Mac que usan la función de aislamiento; Pyautogui parece funcionar bien en Linux y Windows, pero en Mac no resultó muy confiable, así que considéralo funcionalmente no soportado; y el fuzzing de cliente en Windows puede ser un poco menos confiable que otros modos en otras plataformas. Puede haber algunos casos extremos aquí y allá, pero los escenarios más comunes de fuzzing local y de red se han probado y funcionan. Ah, estas son las alegrías de escribir herramientas multiplataforma: gratificante, pero es difícil hacer que todo funcione bien todo el tiempo. En general, el fuzzing en Linux/Mac parece ser más estable y admite más funciones en general, especialmente porque ha tenido muchas más pruebas de fuzzing de red que en la plataforma Windows, pero se hizo un esfuerzo para que al menos lo básico esté disponible en Win32 con un par de extras. Siéntete libre de bifurcar este fuzzer y realizar tales mejoras, soportar lo actualmente no soportado, etc., o hacer PRs para cosas menores pero útiles. ## ¿qué garantías se ofrecen para este proyecto o su código? Absolutamente ninguna. Pero es bastante divertido hacer fuzzing y ver cómo te entrega errores. ## autor / referencias - [Jeremy Brown](https://github.com/sec-tools/litefuzz/blob/main/jbrown3264%5BNOSPAM%5Dgmail) - [Presentación de diapositivas para fuzzing en macOS](https://www.slideshare.net/JeremyBrown37/summer-of-fuzz-macos)

litefuzz

Más Populares

intro

ejemplo de docker

Create crashes directory

Run fuzzing with example input (1000 iterations with heap debugging)

notas

pruebas

pruebas unitarias

ReportCrash

modos de intercambio de datos múltiples

golang

repros

remove file

minimization

comando

ejemplos

aplicación local

vistazo rápido```

enumerando manejadores de archivos en OS X

cliente

vistazo rápido```

servidor local

servidor remoto

línea de comandos```