MSF: Actualizar módulos a mano

Cuando hace unos días publiqué un post sobe metasploit, me preguntaron: ¿Cómo puedo actualizar los módulos de metasploit bajándome las cosas desde exploit-db.com? Y respondí de una manera un tanto rápida. 

Recordando que soy un tanto novato en el tema, tendremos en cuenta que contaré las dos formas que conozco de actualizar el framework. 

También recuerdo el típico disclaimer de siempre: yo no me hago responsable de cómo se utilicen estos conocimientos, datos, todo lo aquí descrito, etc...

La primera de todas sería teniendo un control total sobre lo que se hace. En este caso, toca visitar la página donde se encuentran los exploits (en nuestro caso, la de exploit-db) y bajarse aquel que deseemos actualizar o utilizar. 

exploit-db.com

Aquí vemos la página inicial de la página con los exploits descargables. Estos deberían de estar escritos en ruby (extensión .rb). La verdad, no se desarrollar en este lenguaje. 

Según he podido deducir, tenemos las siguientes partes:

• La fecha en la que se creó la entrada
• La columna D: el enlace directo para descargar el exploit.
• La columna A: si existe, la descarga del software vulnerable al cual se le podrá aplicar el exploit.
• La columna V: de validado. No sé el criterio que se utiliza para ponerlo en este estado. Si alguien lo sabe, por favor, que lo indique en el comentario.
• La columna de descripción:  Nos lleva a otro sitio donde podremos ver algunos datos adicionales del exploit y su código fuente. También se podrá descargar desde ahí:

Descripción del exploit

• La siguiente... ¿Número de descargas?
• La columna Plat. entiendo que es la plataforma. 
• Y, por último, la de Auth... como su nombre indica, la del autor. En este caso, si pone metasploit, ya sabemos que debería de funcionar sin problemas. Si es otro usuario... Pues podría funcionar o, posiblemente tocaría editar el código fuente (por eso lo de saber o no ruby es importante) para hacerlo funcionar en nuestro entorno. 

Por lo tanto, una vez puestos en situación. Vamos a ir a:

# cd /pentest/exploits/framework

# msfconsole

Una vez abierto, podremos utilizar los exploits con el siguiente comando:

msf> use exploit/ruta_al_exploit_deseado/exploit

Si quisiéramos utilizar el exploit 24308.rb (uno de java) que hemos descargado en /pentest/exploits/framework/modules/exploits/ 

exploit 24308.rb en /pentest/exploits/framework/modules/exploits/ 

y lo hemos puesto ahí después de haber arrancado el msfconsole, veremos que no aparece (no se carga al presionar la tecla tab del ordenador). Si, una vez descargado, la abrimos (o la cerramos y la volvemos a abrir), veremos que sí se puede utilizar, tal y como hemos visto en el último comando mostrado. 

use exploit/24308

¿Ya está? Para lo que se quería mostrar, sí. Ya hemos actualizado con un módulo específico. ¿Y tengo que bajarme uno a uno todos los módulos para tenerlo bien actualizado? Yo diría que no. He visto que hay un enlace en la página principal que permite descargarte un archivo que, según he podido entender, tienen todos los exploits que han ido almacenando. Están separados en plataforma: windows, win32, win64, linux, arm... Y después, dentro de cada una de ellas, según sea local, remota... Aún me queda mucho por aprender para poder explicar qué se puede hacer con cada una de ellas. Y, recordando que no todos estos módulos están en ruby, por lo que no se tienen por qué poder utilizar desde este framework.

¿Cuál es la otra opción para actualizarlo? La otra opción sería ejecutar

# msfupdate

Este comando se encargará de añadir todos los módulos nuevos de los que disponga el framework... Y de eliminar aquellos que consideren que no se van a seguir utilizando, por mucho que nos guste darle caña a ese en concreto. Es decir, se pierde el control sobre lo que añaden y lo que quitan. 

Pues estas son las formas con las que podemos actualizar nuestro sistema de metasploit. En algún que otro post ya contaré cómo, teniendo en cuenta mis conocimientos, puedo realizar un ataque entre distintas máquinas virtuales. 

MSF en Informática 64

La semana pasada, los días 21 y 22 de este mes de enero, me cogí unos días libres para ir a la formación de metasploit que se daba en las oficinas de Informática 64.

Como la mayoría de las veces, este tipo de herramientas puede tener dos enfoques en lo que a su uso se refiere:

• El primero, y para lo que está concebida, en teoría, que sería para realizar auditorias y tests de intrusión (penetration tests)
• El otro, resumiéndolo mucho: para realizar maldades y comportarse de una forma muy, muy poco ética.

Como siempre, en este blog se quiere buscar el uso ético de los conocimientos y descubrimientos que se van adquiriendo. O, en su defecto, saber las posibles maldades que nos pueden hacer y cómo se podrían (si es que se puede) resolver. Vamos, nada que alguien con un poco de cabeza no necesita que se le diga. 

Bueno. Que me disperso (como de costumbre). 

Era la primera vez que arrancaba de verdad una de las herramientas de las que consta el framework: el msfconsole. De hecho, tendría que haberla lanzado cuando me leí el libro de metasploit, escrito por Pablo González, y que la empresa publicó.

Lo primero que se hizo fue una presentación de qué constituía el framework, con la misma presentación en power point que nos puso en el Asegur@IT Camp4, (está muy bien reutilizar, esa parte era teoría).

Después de la teoría, se empezó con lo bonito: lanzó el msfconsole y se buscó un exploit de Windows XP bastante conocido: el MS08_067_netapi. Según tengo entendido, bastante conocido por los que llevan un tiempo en este mundillo. 

Una vez nos mostró cómo utilizar, en general, alguno de estos exploits, como el mencionado aquí, cada uno de los cinco participantes que estábamos apuntados intentamos hacer lo mismo desde nuestras máquinas virtuales. Unas veces con más éxito que otras (todo sea dicho).

Y... más o menos, el primer día se quedó en eso, en el haber podido acceder al equipo "víctima" y haberle hecho alguna que otra barrabasada. 

¿Qué hicimos el segundo día? El segundo día, aprovechando el mismo exploit nos lanzamos a hacer algo más: lo que se llama pivoting. A todos los efectos, se trata de ver qué podemos encontrar a través del equipo vulnerado e intentar aprovecharse de esta circunstancia para vulnerar algún equipo vecino al que no podríamos acceder sin habernos colado en el primero. Y así, podríamos hacerlo sucesivamente. 

¿Qué más vimos? Vimos cómo preparar un servidor web para que todo aquel que cargue la URL establecida, se le empiecen a cargar vulnerabilidades, probando a ver si funciona una a una, hasta que podamos cantar "bingo!" con alguna de ellas. Para conseguirlo, haría falta obligar a la(s) victima(s) a acceder a la URL, ya sea por un iframe oculto, o por una URL acortada, o incluso, poniendo un enlace y decirle que podrá ver un montón de pr0n gratis (eso siempre funciona, pero en este caso, siento mucho que os haya enviado al about:blank [contadme cuántos de vosotros le habéis dado sin pensar al enlace]). Una de las cosas que hicimos fue buscar el exploit de, en su momento, 0day de java que salió hace unas pocas semanas. 

También hicimos un ejercicio de búsqueda. Teniendo un equipo accesible, vimos los servicios que tenía instalados, y localizamos que uno de ellos era vulnerable. Se hizo una búsqueda por google, se localizó qué vulnerabilidad era, y nos la bajamos de exploit-db (¿o nos bajamos de este el de java?) para actualizar el framework sin tener que lanzar el msfupdate (que añade y elimina cosas sin un control por nuestra parte).

La verdad, lo disfruté mucho. Quiero seguir jugando con las máquinas virtuales. Creo que haré alguna cosa de estas y las publicaré, sin importarme que ya sean del todo conocidas. 

Si os gustan estas cosas, creo que disfrutaréis mucho si hacéis esta formación la próxima vez que la hagan.