cisco-talos/mutiny-fuzzerFuzzer de protocolos de red que reproduce tráfico PCAP a través de un motor de mutación (Radamsa) para descubrir rápidamente vulnerabilidades en los hosts objetivo mediante procesadores de mensajes y monitores personalizables.
Publicación del blog aquí:
Enlaces a esta demostración en video de YouTube:
Para más características orientadas a campañas de fuzzing/retroalimentación/arneses:
El Marco de Fuzzing Mutiny es un fuzzer de red que opera reproduciendo PCAPs a través de un fuzzer mutacional. El objetivo es comenzar el fuzzing de red lo más rápido posible, a expensas de ser exhaustivo.
El flujo de trabajo general para Mutiny es tomar una muestra de tráfico legítimo, como una solicitud de navegador, e introducirla en un script de preparación para generar un archivo .fuzzer. Luego, Mutiny se puede ejecutar con este archivo .fuzzer para generar tráfico contra un host objetivo, mutando los paquetes que el usuario desee.
Hay extensiones que permiten cambiar el comportamiento de Mutiny, incluyendo cambiar mensajes basados en entrada/salida, cambiar cómo Mutiny responde a errores de red, y monitorear el objetivo en un hilo separado.
Mutiny usa Radamsa para realizar mutaciones.
El Proxy Decept es un proxy de red multipropósito que puede reenviar tráfico desde una conexión de socket TCP/UDP/dominio en texto plano o TLS a una conexión de socket TCP/UDP/dominio en texto plano o TLS, entre otras características. Es un buen compañero para Mutiny, ya que puede generar archivos .fuzzer directamente, especialmente útil al fuzzing conexiones TLS, y permitir que Mutiny se comunique con hosts TLS.
sample_apps da una idea básica de algunas cosas que se pueden hacer con el fuzzer, con algunas aplicaciones/clientes diferentes para probar.
Escrito por James Spadaro ([email protected]) y Lilith Wyatt ([email protected])
Asegúrate de que python y scapy estén instalados.
Descomprime Radamsa y ejecuta make (No es necesario hacer make install, a menos que lo quieras en /usr/bin - usará el Radamsa local) Actualiza mutiny.py con la ruta a Radamsa si lo cambiaste.
Guarda el pcap en una carpeta. Ejecuta mutiny_prep.py en <XYZ>.pcap (también opcionalmente pasa el directorio de un procesador personalizado si lo hay, más abajo). Responde las preguntas, obtendrás un archivo <XYZ>.fuzzer en la misma carpeta que el pcap.
Ejecuta mutiny.py <XYZ>.fuzzer <targetIP>. Esto iniciará el fuzzing. Los registros se guardarán en la misma carpeta, bajo el directorio <XYZ>_logs/<time_of_session>/<seed_number>
Los archivos .fuzzer son legibles por humanos y están comentados. Permiten cambiar varias opciones por archivo fuzzer, incluyendo qué mensaje o partes del mensaje se fuzzan.
Dentro de un archivo .fuzzer están los contenidos del mensaje. Estas son simplemente líneas que comienzan con 'inbound' o 'outbound', indicando la dirección del mensaje. Están en formato de cadena de Python, con '\xYY' usado para caracteres no imprimibles. Estos son autogenerados por 'mutiny_prep.py' y Decept, pero a veces necesitan ser modificados manualmente.
Si un mensaje tiene la palabra clave 'fuzz' después de 'outbound', esto indica que debe ser fuzzeado a través de Radamsa. Un mensaje dado puede tener continuaciones de línea, simplemente poniendo más datos del mensaje entre comillas en una nueva línea. En este caso, esta segunda línea se fusionará con la primera.
Alternativamente, la palabra clave 'sub' se puede usar para indicar un subcomponente. Esto permite especificar un componente separado del mensaje, para fuzzear solo ciertas partes y por conveniencia dentro de un Message Processor.
Aquí hay un conjunto de datos de mensaje arbitrario de ejemplo:
outbound 'say'
' hi'
sub fuzz ' and fuzz'
' this'
sub ' but not this\xde\xad\xbe\xef'
inbound 'this is the server's'
' expected response'
Esto hará que Mutiny transmita say hi and fuzz this but not this(0xdeadbeef). 0xdeadbeef se transmitirá como 4 bytes hexadecimales. and fuzz this se pasará a través de Radamsa para fuzzing, pero say hi y but not this(0xdeadbeef) se dejarán sin cambios.
Mutiny esperará una respuesta del servidor después de transmitir el solo mensaje anterior, debido a la línea 'inbound'. La respuesta esperada del servidor es this is the server's expected response. Mutiny no hará mucho con estos datos, aparte de verificar si lo que el servidor realmente envió coincide con esta cadena. Si ocurre un fallo, Mutiny registrará tanto la salida esperada del servidor como lo que el servidor realmente respondió.
mutiny_classes/ contiene clases base para el Message Processor, Monitor y Exception Processor. Cualquiera de estos archivos se puede copiar en la misma carpeta que el .fuzzer (por defecto) o en una subcarpeta separada especificada como 'processor_dir' dentro del archivo .fuzzer.
Estas tres clases permiten almacenar respuestas del servidor y cambiar mensajes salientes, monitorear el objetivo en un hilo separado, y cambiar cómo Mutiny maneja las excepciones.
El Message Processor define varios callbacks que se llaman durante una ejecución de fuzzing. Dentro de estos callbacks, se puede ejecutar cualquier código Python. Anécdotamente, se usan principalmente de tres maneras.
La más común es cuando el servidor envía tokens que deben agregarse a futuros mensajes salientes. Por ejemplo, si el primer mensaje de Mutiny inicia sesión, y el servidor responde con un ID de sesión, el callback postReceiveProcess() se puede usar para almacenar ese ID de sesión. Luego, en preSendProcess(), los datos salientes se pueden arreglar con ese ID de sesión. Un ejemplo de esto está en sample_apps/session_server.
Otro uso común de un Message Processor es limitar o cambiar un mensaje fuzzeado. Por ejemplo, si el servidor siempre descarta mensajes mayores de 1000 bytes, puede que no valga la pena enviar mensajes grandes. preSendProcess() se puede usar para acortar mensajes después del fuzzing pero antes de que se envíen, o para lanzar una excepción.
Lanzar una excepción trae la última forma en que los Message Processors se usan comúnmente. Dentro de un callback, se pueden lanzar excepciones personalizadas definidas en mutiny_classes/mutiny_exceptions.py. Hay varias excepciones, todas comentadas, que causarán varios comportamientos de Mutiny. Generalmente implican registrar, reintentar o abortar la ejecución actual.
El Monitor tiene una función monitorTarget() que se ejecuta en un hilo separado del fuzzer principal de Mutiny. El propósito es permitir implementar un proceso de larga duración que pueda monitorear un host de alguna manera. Esto puede ser cualquier cosa que se pueda hacer en Python, como comunicarse con un daemon de monitoreo ejecutándose en el objetivo, leer un archivo largo, o incluso simplemente hacer ping al host repetidamente, dependiendo de los requisitos de la sesión de fuzzing.
Si el Monitor detecta un fallo, puede llamar a signalMain() en cualquier momento. Esto señalará al hilo principal de Mutiny que ha ocurrido un fallo, y registrará el fallo. Esta función generalmente debe operar en un bucle infinito, ya que retornar hará que el hilo termine y no se reiniciará.
El Exception Processor determina qué debe hacer Mutiny con una excepción dada durante una sesión de fuzz. En el sentido más general, la función processException() traducirá excepciones de Python y del sistema operativo en acciones de manejo de errores de Mutiny lo mejor que pueda.
Por ejemplo, si Mutiny recibe 'Connection Refused', la respuesta predeterminada es asumir que el servidor objetivo ha muerto de manera irrecuperable, por lo que Mutiny registrará la ejecución anterior y se detendrá. Esto es cierto en la mayoría de los casos, pero este comportamiento se puede cambiar al de cualquiera de las excepciones en mutiny_classes/mutiny_exceptions.py según sea necesario, permitiendo adaptar la detección de fallos y la corrección de errores.