Desarrollando para Metasploit (II) : Módulos auxiliares

Buenas otra vez, en nuestro post anterior hicimos una breve introducción al desarrollo de módulos de Metasploit programando el típico “Hola mundo”, en éste vamos a profundizar un poco más en el tema centrándonos en los módulos “Aux” (auxiliares). Recordamos que este tipo de módulos sirve para implementar casi cualquier cosa debido a la flexibilidad en la definición de sus interfaces.

Un tema del que no hablamos y es muy importante son los “Mixins”, su finalidad es evitar la duplicidad del código que se comparte entre módulos, los hay que ayudan en la implementación de escáneres para distintos protocolos ("Msf::Auxiliary::Scanner"), para exploits de fuerza bruta ("Msf::Exploit::Brute") e incluso para exploits remotos de un protocolo específico ("Msf::Exploit::Remote::Ftp"). Esto supone un claro aumento en la velocidad de desarrollo por apoyarse en un número cada vez mayor de módulos probados. Como siempre, en la guía del desarrollador y en la documentación de la API tenemos una referencia mucho más precisa sobre los mismos.

En esta ocasión vamos a comentar el código de un “flooder” típico para el protocolo UDP, es muy sencillo también pero utiliza “Mixins” y tiene algunas funciones definidas. Con esto tenemos lo necesario para comprender la estructura general de los módulos auxiliares, a partir de aquí se pueden complicar en mayor o menor medida dentro de la función “run()” dependiendo del vector de ataque que esté siendo implementado.

Código:

-----------------------------------------------------------------------------------------

-----------------------------------------------------------------------------------------

Diferencias a señalar respecto al código de nuestro Hola mundo anterior:

- Al inicio tenemos dos “include” para cargar los “Mixins”, en un principio podemos verlo como la típica librería de cualquier lenguaje de programación, si necesitamos una función que implementa debemos de cargala antes de usarla. En nuestro caso necesitamos el “Msf::Auxiliary::Dos” para poder usar la función “capture_sendto(p,rhost)” en el método “run()” y en el caso de “Msf::Exploit::Capture” no se carga porque necesitemos ninguna función pero sí por ser necesario para indicar que se trata de un módulo auxiliar de tipo DOS. ¿Con que objetivo? Pues por ejemplo para evitar que se ejecute este módulo durante procesos automáticos, lo cual suele ser una buena idea para los “flooders”.

- El método “initialize()” es similar al módulo de la vez anterior pero encontramos que se utiliza el “deregister_options('FILTER','PCAPFILE','SNAPLEN')”. Los “Mixins” resgistran automáticamente algunas opciones, en algunos casos necesarias para la ejecución del módulo, por lo cual si no les damos ningún valor éste no se ejecutará. Si nos fijamos vemos que la opción “RHOST” no la creamos, ésto es porque ya lo hace el “Mixin”. “Msf::Exploit::Capture” registra automáticamente las opciones “FILTER”, “PCAPFILE” y “SNAPLEN” debido a que normalmente se utiliza para implementar ataques que precisen alguna captura de red, en este caso no son necesarios así que los desregistramos.

- A continuación se definen varias funciones que convierten el tipo del valor asignado a cada opción o le asignan uno aleatorio si no se le proporcionó al llamar al módulo.

- El código termina con el método run(), echándole un vistazo a la documentación del método “UDPPacket()” de la librería PacketFu de Ruby vemos que se codificaría como cualquier otro programa escrito en este lenguaje. Usamos ésta en lugar de abrir un socket UDP porque en este caso no queremos establecer una conexión completa si no crear un paquete manipulado para enviarlo y si no recibimos la respuesta mejor (para eso spoofeamos la dirección IP de origen, entre otras cosas), ya que si no nos podríamos “floodear” a nosotros mismos xD.

Para terminar, en las imágenes siguientes podemos ver una muestra de su funcionamiento, vemos que envía un paquete UDP del tamaño especificado (256 bytes) con la dirección spoofeada. También se observa que aleatoriza la dirección Ip de origen entre peticiones así como el puerto de salida mientras que el servidor, como especifica la definición del ataque, responde con un “ICMP Unreachable” a cada petición.

Pues nada más por esta ocasión, en las siguientes implementaremos una PoC que dispare un DoS y otra que explote un stack buffer overflow. Hasta la próxima. :)

Artículo cortesía de Jesús Pérez y Roi Mallo

Etiquetas: contribuciones , hacking , herramientas , metasploit , seguridad