Fuzzbunch, una Producción NSA



En los últimos días se puso "hot topic" el tema de EternalBlue debido al éxito del ciberataque conocido como WannaCry. El ataque se esparció usando el toolset de la NSA que libero el team Shadow Brokers el pasado viernes santo.

El presente articulo tiene como fin dar a conocer diferentes aproximaciones para poder analizar el funcionamiento de este framework, como también dar a conocer una vulnerabilidad de bajo impacto localizada en el framework

A grandes rasgos, tratamos de usar diferentes herramientas de depuración para tracear la ejecución y analizar zonas importantes en el código.






DEBUGGEANDO EL LAUNCHER

Fuzzbunch es el mini framework escrito en python encargado de lanzar los diferentes tipos de módulos binarios, como por ejemplo payloads como DoublePulsar o exploits como EternalBlue.

Para Fuzzbunch usaremos el modulo pdb que nos permitirá levantar una consola interactiva en la cual podemos consultar estado de variables y/o modificarlas, la linea en cuestión es:

import pdb;pdb.set_trace()

Cuando llegue a ejecutar esa linea, levantara la consola interactiva de Pdb, los comandos mas usados son:
  •  list, que muestra en que linea de código estamos posicionados.
  • next y step para ejecutar la linea donde estamos con la diferencia que next se detiene en la siguiente linea, en cambio step pasa la ejecución a la función mas interna.
  • continue, para seguir con la ejecución normalmente.
También podemos meter código python para inspeccionar las variables. Como ejemplo en la siguiente imagen se interrumpió el flujo normal en el "main" de fuzzbunch:



Las variables marcadas en color amarillo corresponden a diferentes directorios del propio fuzzbunch, el método setup_and_run creara una instancia del objeto FuzzBunch que es un objeto heredado de Cmd usado para crear consolas interactivas al estilo gdb o metasploit.

Mirando el constructor podemos advertir que se usa un archivo de configuración xml para cargar el entorno inicial:


Un poco mas abajo evalua uno de los campos del archivo xml para guardar un valor booleano:


Por defecto trae el valor True, entonces cuando hace la evaluación deja habilitada la variable enablecolor. En vez de un valor true/false se podría inyectar código python para que nos entregue una reverse shell

Al ejecutar el framework, se evaluara la anterior linea y entregara una consola con los mismos privilegios del atacante que esta ejecutando los módulos:


Es particularmente raro que  se use eval de un archivo de configuración para setear variables, parece que al momento de construir este código, se tuvo en cuenta la facilidad de desarrollo sin hacer mucho hincapié en la seguridad.

Eso es alentador si lo que pretendemos es buscar errores en estas herramientas.


DEBUGGEANDO EL MODULO

Los módulos son ejecutables compilados que los ejecuta el launcher con subprocess.Popen luego de configurar algunos archivos, en la siguiente imagen podemos ver el comando en cuestión:


fuzzbunch lanza el binario y espera un maximo de cuarenta y cinco segundos a que el binario establezca una comunicación por un IPC que creo el, en caso de alcanzar el Timeout el framework saca por pantalla un mensaje de error en el canal IPC.



CONNECT_TIMEOUT_SECS esta definida unas lineas mas arriba

Para analizarlo modificamos el binario con un loop en el EntryPoint e incrementamos los segundos del Timeout a un valor que nos permita analizarlo con todo el entorno levantado.

El EntryPoint lo pisamos con un bucle infinito, que nos posibilitara dormir el proceso y que nos espere a Attachearnos.


Ahora solo falta lanzar el modulo, attach el proceso con un debugger como OllyDBG o x32dbg y restauramos los bytes originales del proceso.

Tengan en cuenta que fuzzbunch lanza dos veces el proceso, el primero para verificar que todo funcione correctamente con el parámetro --ValidateOnly y el segundo ejecuta el exploit.

Si el objetivo es caer en zonas cruciales del programa, como el estado del backdoor o el envió del exploit, podemos frenar la ejecución en TcLog que es una función que maneja todos los textos que se imprimen por pantalla.


También podemos mirar en send y recv ya que hace uso de esas funciones para enviar los paquetes


los tips expuestos anteriormente deberían funcionar para cualquier modulo de los que posee el framework.

PING AL BACKDOOR

Una de las verificaciones que hace el modulo antes de triggerear la vulnerabilidad es ver si la maquina ya fue comprometida, para hacer eso envía un paquete SMB y en base a la respuesta reconoce si esta o no infectado, también permite enviar el status del backdoor DoublePulsar

Esta información viene dentro de uno de los paquetes que se envían, el campo importante es el 51h que estamos marcando en la imagen



Las posibilidades están enumeradas en el próximo switch:




Las opciones son:
  • 00h significa que la maquina no esta comprometida aun.
  • 51h es que el agente ya esta instalado y operativo.
  • 61h 71h 81h y 91h son mensajes de estado, como por ejemplo "Bad transaction" o "Invalid transaction Param"

Cabe destacar que ya existen módulos en diferentes herramientas como nmap o metasploit para chequear si una maquina ya fue comprometida.


CREDITOS
Javier Aguinaga, German Riera y Ezequiel Tavella
(Infobyte Security Research Team)
Post a Comment
Thanks for your comment