Conquistar el mundo con OSINT & Known-Vulnerabilities (PARTE 2 de 2) #OSINT #Metasploit

Continuando con la primera parte de este artículo sobre cómo "Conquistar el mundo con OSINT & Known-Vulnerabilities", vamos a ver en esta parte la automatización del proceso completo para terminar con una Prueba de Concepto ficticia de lo que se podría realizar. Vamos a ello.

Figura 7: Conquistar el mundo con OSINT & Known Vulnerabilities (Parte 2)

¿Dónde están las máquinas?

Una de las ideas de esta prueba de concepto era poder demostrar que las máquinas víctimas podrían estar distribuidas por países. Esto demostraría que disponer de máquinas en distintas ubicaciones geográficas aporta un poderío y una ventaja al atacante. Para procesar la información y obtener la geolocalización de las máquinas que nos interesan se desarrolló un script que mediante un servicio similar a ip2location nos permite obtener esta información.

Figura 8: Obteniendo la localización

Como puede verse los valores que se almacenan son:

• La dirección IP de la máquina.
• El país dónde se encuentra la dirección IP.
• La región / ciudad dónde se encuentra la dirección IP.
• El código del país.
• El fichero / software dónde se encontró la máquina.

Una vez realizado todo este proceso se pueden sacar algunos datos curiosos. Por ejemplo, la aplicación PcMan FTP 2.0.7, la cual el texto de su interfaz está en algún idioma asiático solo tiene presencia en Taiwan. Lo más curioso es que si echamos un vistazo a exploit-db con la siguiente búsqueda nos daremos cuenta de que ese software tiene muchos agujeros. Por cada comando del FTP hay un Buffer Overflow, y uno se pregunta… ¿Este software está puesto ahí adrede o es casualidad?

Figura 9: Exploits en versiones de PCMan's FTP

Bien, tras analizar por encima diversos datos y ver que se cumplía uno de los objetivos de la prueba de concepto que era ver máquinas distribuidas por el mundo, debía realizar un script que me cogiera solo las direcciones IP para, a posteriori, poder crear el mapa gráfico. El script encargado de recolectar direcciones IP con sus códigos de país fue denominado xoxo2ip.rb. Este script facilitaba mucho la tarea de generateMap.rb, el cual utiliza un servicio online que nos presenta el mapa.

Figura 10: Script generateMap.rb

En la imagen anterior podemos ver la salida del script generateMap.rb, el cual me devuelve una dirección URL a la que podemos acceder para visualizar el mapa gráfico. Como se puede ver en el gráfico, dispondríamos de máquinas en una gran cantidad de países.

Figura 11: Ubicación de las máquinas localizadas

Como curiosidad, y por si alguien piensa en irse a la isla de Barbados, allí salía una máquina con software vulnerable. ¿La localizáis?

Hablemos del módulo: exploit_massive

Mi idea era automatizar desde un único nodo central el lanzamiento de exploits que se aprovechan de las vulnerabilidades conocidas. La forma más sencilla de llevar a cabo esto era aprovechar Metasploit para la PoC. Recordemos que en Metasploit ya existía algo similar denominado autopwn, y sigue existiendo un browser_autopwn. Mi idea era retomar la idea del mítico autopwn pero enfocado a algo que me sirviera en esta PoC.

El diseño de mi módulo es sencillo y lo puedo explicar en diferentes pasos. Todos quedáis invitados a mejorar la funcionalidad y mejorar el propio código. A continuación un resumen de lo que se hace en el módulo:

• El módulo cuando se ejecute la función exploit leerá de un fichero comentado anteriormente la información que tiene que configurar. Hay que recordar que el fichero contiene información sobre las direcciones IP, módulos de tipo exploit a utilizar, puertos dónde los servicios vulnerables escuchan, tipo de payload, etcétera.

• Por cada línea es un target distinto. De este modo cada línea es procesada en el cuerpo de la función exploit.

• La ruta del fichero se especifica a través de un atributo básico definido por nosotros, mediante el uso del mixin register_options. El atributo se denominó FILE_HOSTS.

• Otro atributo, en este caso tipado de avanzado, es el de UPGRADE. Este atributo admite 2 valores, true o false. Si el atributo avanzado se configura a true, cuando el módulo detecte una sesión que es de tipo shell, y no Meterpreter, se realizará un upgrade automático a una Meterpreter. Es una funcionalidad muy interesante, ya que de primeras algunos módulos no admiten un Meterpreter, por ejemplo el módulo unix/ftp/vsftpd_234_backdoor.

• El módulo proporciona información sobre la línea o target sobre el que se está lanzando el exploit. Se puede visualizar en la consola información como el host, el módulo del exploit que se está lanzando, el puerto remoto y el payload que se utilizará en caso de que la explotación se consiga.

Visto esto ahora comienza la parte iterativa. Por cada línea que se lee y se parsean los parámetros se debe configurar una variable denominada datastore. Esta variable almacena los valores de atributos como RHOST, LHOST, PAYLOAD, etcétera. En otras palabras todos los atributos o variables que pueden ser configurados desde la línea de comandos cuando tenemos cargado un módulo.

Por cada iteración debemos instanciar el módulo que se quiere utilizar, por ejemplo si el Target 1 es un servicio FTP con ProFTPd 1.3.3c se instanciará el módulo de tipo exploit para dicho software. Para llevar a cabo la instanciación se utiliza el objeto framework en el código. Este objeto permite al desarrollador utilizar y referenciar cualquier acción que se pueda llevar a cabo desde la línea de comandos. De este modo utilizaremos framework.modules.create([módulo exploit]) para instanciar de forma iterativa los módulos. Como se dijo anteriormente, por cada iteración hay que configurar varias cosas con los parámetros que se pasan a través del fichero hosts que nombré anteriormente.

Figura 12: Procesamiento de fichero de objetivos y configuraciones a realizar

Se utiliza el método check_simple para por cada módulo leído que se lanza contra un Target comprobar si la máquina remota sería vulnerable al exploit. La variable message almacena el resultado de la ejecución del método para posteriormente mostrarse al usuario por pantalla.

Una de las cosas más importantes es la ejecución del método exploit_simple, el cual recibe una serie de parámetros que son los atributos que queremos configurar, por ejemplo Target por defecto, datastore[‘PAYLOAD’], etcétera. El lanzamiento del método exploit_simple puede provocar la obtención de una nueva sesión, la cual será almacenada en la variable session_shell, tal y como puede verse en el código.

Figura 13: Lanzamiento de exploit por Target

Una vez lanzado el módulo y obtenida la sesión se comprueba si existe el cuarto parámetro, el cual reflejan atributos avanzados que puede contener el módulo de Meterpreter. El cuarto parámetro puede contener diversos atributos avanzados separados por comas. Cada elemento contiene una clave o key y un valor separados por ‘:’. Como se puede ver en la línea datastore[key] = value, permite configurar valores dentro del módulo.

Figura 14: Configuración de atributos por claves

Los atributos como InitialAutoRunScript y AutoRunScript nos permite ejecutar instrucciones automáticamente una vez la Meterpreter se encuentra ejecutándose. De este modo hay que tener en cuenta que realizar un pequeño script el cual ejecute automáticamente las instrucciones necesarias para subir binarios que “troyanizasen” dichas máquinas sería algo muy sencillo.

Figura 15: Ejecución de módulo de post explotación

 Por último hay que hablar de si la sesión que se consigue no es una Meterpreter y sí es una shell. En este instante si el atributo avanzado UPGRADE se configura como true se subirá automáticamente a través de la sesión de la shell. Esto se puede realizar gracias al módulo de post-explotación post/multi/manage/shell_to_meterpreter.

PoC: Escenario ficticio

Para la prueba de concepto se presenta un entorno multiplataforma. Es cierto que lanzar el módulo en un entorno real sería ilegal, y no es el objetivo de dicho módulo. El objetivo es que sea utilizado en auditoría y ayudar al pentester a simplificarse el trabajo. El escenario montado es el siguiente:

• En una máquina con Metasploit se lanzará el módulo. Esto es lo que llamamos el nodo central de la operativa.
• Habrá un sistema Windows 7 SP1 con un servidor HTTP de los evaluados en el estudio.
• Habrá un sistema Windows XP SP3 versión ingles con un servidor FTP, sí el de Taiwan que comenté anteriormente.
• Habrá un sistema Linux con un servidor FTP vulnerable.

Lo que se pretende con estas 3 muestras es reflejar la realidad de los entornos y el uso de aplicaciones o servicios vulnerables hoy día. Ahora, configurando módulo para lanzar el ataque masivo con el mínimo esfuerzo.

Figura 16: Configuración de módulo para lanzar ataque masivo

También se puede configurar el atributo UPGRADE para que en el caso del sistema Linux podamos ejecutar una shell y posteriormente un Meterpreter. Esto ocurre porque si vemos el detalle del módulo unix/ftp/vsftpd_234_backdoor, no proporciona la posibilidad de inyectar una Meterpreter directamente.

Ahora simplemente hay que ejecutar exploit y esperar a que las sesiones vayan llegando. Cómo es lógico, una mente maliciosa haría que en el atributo InitialAutoRunScript y AutoRunScript se ejecutase una instrucción que permitiese troyanizar la máquina, pero eso lo dejamos para otra vez.

Figura 17: Ejecución de exploit masivo

Como puede verse en la imagen, por cada línea del fichero hosts del módulo se irán lanzando módulos con la configuración especificada. El resultado final lo podemos imaginar, aunque no todas las máquinas fueran vulnerables, aplicando una ley del 50% de las encontradas con scans.io, podríamos hablar de una botnet de más de 25.000 máquinas con el mínimo esfuerzo. Al final, la verdad está ahí fuera, ya lo decía la gente de Expediente X.

Figura 18: Sesiones obtenidas en equipos vulnerables

Se pueden ver las sesiones logradas en esta prueba de concepto. Al final fue bastante divertido “trastear” con Metasploit y sus tripas en Ruby. Os animo a probar el módulo y seguir avanzando y mejorando sus versiones. ¡Diviértete!

Autor: Pablo González Pérez (@pablogonzalezpe)
Escritor de los libros "Metasploit para Pentesters", "Ethical Hacking" y “Pentesting con Powershell”
PD: Este artículo está dedicado a ti, hacker.