Desarrollo de módulos auxiliares HTTP en Metasploit
La idea de este tutorial de Desarrollo de módulos auxiliares HTTP en Metasploit es mostrar la estructura de los módulos auxiliares de metasploit, familiarizarnos con el código, conocer las funcionalidades que nos ofrece el framework, para de esta forma empezar a crear y modificar los módulos de esta magnífica herramienta.
Desarrollo de módulos auxiliares HTTP en Metasploit tutorial 1
Este primer tutorial explica la modificación del módulo auxiliar de metasploit llamado "apache_mod_cgi_bash_env". Este módulo aprovecha la vulnerabilidad de Bash denominada shellshock y el cual fue publicado al poco tiempo que la vulnerabilidad se hizo pública.
También puede ser de tu interes - http://dragonjar.org/curso-de-metasploit.xhtml
La principal motivación para modificar el módulo es porque al hacer las pruebas contra un servidor vulnerable, el módulo no respondía, ni generaba error o las excepciones correctas para verificar que el servidor era vulnerable o no, simplemente salía la siguiente pantalla:
Esta pantalla no era nada diciente por esta razón nace la necesidad de modificar los módulos y agregar puntos de depuración o mejoras.
Antes de empezar a modificar el módulo una breve explicación del código:
A continuación los parámetros que recibe como tal el módulo
Funciones del módulo auxiliar
Y por último las 3 funciones que conforman la operación del módulo auxiliar, las cuales vamos a explicar en detalle, la primera la funcion check_host, la cual es invocada una vez ejecutamos el comando check desde la consola de metasploit
El cuerpo de la función muestra el llamado de otro método llamado "req", el cual realizara la petición al servidor, enviando como parámetro el comando a ejecutar.
La función req hace uso del método "send_request_cgi" el cual hace parte de la clase "Msf::Exploit::Remote::HttpClient" incluida en la cabecera del módulo . Esta función se encarga de hacer la petición HTTP al servidor.
Como se puede observar en la imagen anterior, el método "send_request_cgi" recibe tres parámetros en este caso, el primero es el metodo http, el cual esta almacenado en la variable datastore['METHOD'], cabe recordar que esta variable es la que almacena el valor cuando nosotros hacemos uso del comando "set METHOD" en la consola de metasploit.
Segundo parametro en Desarrollo de módulos auxiliares HTTP en Metasploit
El segundo parámetro es el path del cgi, el cual almacenamos con el comando "set targeturi " en la consola de metasploit y por ultimo parámetro es el user-agent donde se inyecta el comando.
El método run_host no lo vamos a modificar en este ejemplo, por esta razón no vamos a explicar la funcionalidad. Solo vamos a modificar y validar el método check_host.
Entonces lo primero es agregar una función que imprima la respuesta del servidor, para esto vamos a utilizar el método:
print_status o el metodo vprint_status La diferencia entre estos dos métodos es que el método vprint_status despliega la información en pantalla si se encuentra en TRUE la variable VERBOSE
Nuestra función check_host queda de la siguiente forma
En la consola ejecutamos el comando reload, para que se tomen los cambios realizados
Ejecutamos la función check para validar la respuesta del servidor
Respuesta del servidor
Con esto validamos que la respuesta del servidor es un error interno del servidor (código 500) Podemos modificar el código que se envía en el agente, dado que el código inicial espera que la respuesta imprima un valor aleatorio, pero al validar que el servidor responde con un error 500, podemos intentar enviar un comando que cree un archivo en el servidor. Por ejemplo:
() { :; }; /bin/echo prueba > /var/www/poc/index_xxxxxx.php
El método req, quedaría de la siguiente forma:
Si recargamos el módulo con el comando reload y ejecutamos con check, vemos que sale el mismo erro 500 pero si verificamos en el explorador la dirección del nuevo archivo que se debió crear en el servidor podemos verificar que efectivamente responde
Por último agregamos al módulo que verifique si la creación del archivo en el servidor fue exitosa. solo basta con agregar un request y que dependiendo de la respuesta informe si el servidor es vulnerable.
Si todo sale bien el módulo auxiliar informa que el servidor es vulnerable una vez verifica la creación del archivo
Notas
- Para la POC es servidor vulnerable contaba con el CGI que especifican en la pagina https://www.invisiblethreat.ca/2014/09/cve-2014-6271/
- La versión publicada del módulo fue la que salio una vez se hizo publica la vulnerabilidad. En estos momentos el módulo tiene modificaciones y mejoras. (Recuerden mantener actualizado su metasploit msfupdate)
- En la próxima entrega como construir un módulo auxiliar para explotar una vulnerabilidad de denegación de servicio para Joomla. Saludos
Artículo escrito por Luis Hernandez, Especialista Seguridad Informática @luisco100 para La Comunidad DragonJAR.