viernes, 19 de febrero de 2010

Pentester.es participa en las Conferencias FIST

El próximo día 26 de Febrero tienen lugar en Barcelona las Conferencias FIST, que como ya sabréis generalmente se celebran alternativamente en Madrid y en Barcelona.

En Barcelona concretamente, ya llevan un par de años teniendo lugar dentro del contexto de la Fiberparty, una LANParty tradicional de esta ciudad que fue montada originariamente por estudiantes de la Facultad de Informática de Barcelona (UPC) en la que podemos tener acceso, además de los típicos torneos de los juegos más conocidos, a charlas y conferencias muy interesantes, e incluso un concurso de Hacking.

Si después de leer esto estáis pensando en apuntaros corriendo... lo siento, pero las entradas están ya agotadas a falta aún de dos semanas para el evento, aunque creo que si estáis interesados en las conferencias sí se puede asistir a ellas con un pase de visitante.

El caso es que hemos recibido una invitación por parte de la Organización de las Conferencias FIST para realizar una de las tres charlas que se impartirán en esta edición de las conferencias. El tema:

Windows Post-Explotation & Pass the Hash

La charla constará de 45 minutos en los que explicaremos alguna de las técnicas que podemos usar en la post-explotación de los sistemas Windows y un par de demostraciones en vivo de las herramientas y las técnicas.

Esperamos que el tema sea de vuestro interés y que aquellos que nos leen y tengan la oportunidad de estar por Barcelona se pasen a saludarnos.

Hasta entonces! Nos vemos en las FIST! ;)

jueves, 11 de febrero de 2010

Explotando SMB NTLM

Hace unos días, los investigadores Hernán Ochoa y Agustín Azubel, publicaron una vulnerabilidad en la implementación de NTLMv1 de Microsoft, el protocolo que utilizan los sistemas operativos Microsoft para la autenticación a través de la red.

A pesar de que Microsoft ya ha publicado un parche que corrige la vulnerabilidad, existe un riesgo muy alto para aquellos usuarios que no se encuentren al día con sus actualizaciones. La vulnerabilidad afecta a TODOS los productos Microsoft que soporten NTLMv1, es decir, absolutamente TODOS los sistemas operativos Microsoft que existen en el mercado. La vulnerabilidad existe, por tanto, desde hace 17 años.

La vulnerabilidad consiste en una debilidad en la elección del Reto en el mecanismo Reto-Respuesta utilizado para realizar la autenticación. Según se ha publicado en el advisory de la vulnerabilidad, realizando un número suficiente de conexiones a un servicio SMB, los Retos este envía al cliente para realizar la autenticación comienzan a repetirse en un corto espacio de tiempo.

Esta vulnerabilidad puede ser explotada de varias formas, teniendo como consecuencia la autenticación en un sistema con los privilegios de un usuario sin conocer la contraseña de dicho usuario, algo similar a lo que conseguirías como las técnicas de Pass-The-Hash pero mucho más terrorífico, sin necesidad de tomar el control de ninguno de los equipos.

Uno de los posibles vectores de ataque consiste en recolectar de un equipo tantos Retos como podamos, comprobando que efectivamente comienzan repetirse.


Una vez hecho esto, si conseguimos de alguna manera que algún usuario que pueda autenticarse en ese sistema visite un HTML especialmente preparado para hacerle acceder a un servicio Samba que hemos dejado a la escucha para la ocasión, podemos proporcionar a cada una de esas conexiones uno de los Retos que hemos obtenido, con lo que el usuario legítimo nos devolverá las Respuestas adecuadas a cada reto.




Ahora que ya tenemos un montón de Retos y sus respectivas Respuestas de un usuario legítimo, solo tenemos que volvernos a ir al servidor que queríamos atacar y lanzarle la conexión que queramos (escribir un fichero, ejecutar un comando, etc). Si el Reto que nos manda el servidor no lo tenemos en nuestra lista de Reto-Respuesta, lo descartamos y realizamos otra conexión. En el momento que el servidor nos envíe un reto que tengamos en nuestra lista, nosotros le devolveremos la Respuesta que nos devolvió el usuario, por lo que quedaremos autenticados en la máquina con sus privilegios, ejecutándose nuestra acción.


Podemos ver todo esto en vivo en un pequeño video que hemos preparado. Siento la marca de agua, queda un poco cutre pero no encuentro ningún software free para Mac para hacer ScreenCast, pero como me parece que es una vulnerabilidad interesante y de actualidad he preferido poneros el video así y cambiarlo por otro sin marca de agua en cuanto pueda. Perdón por las molestias. Os dejo con el video:





Los script ruby utilizados están contenidos el propio advisory.

lunes, 8 de febrero de 2010

Auditoría Web: W3af "en el Dojo"

Antes de nada quiero agradecer a todo el equipo de Pentester por permitirme colaborar con ellos. Espero poder contribuir con contenidos interesantes. ¡Muchas gracias!


Auditoría Web: Automatización mediante W3af

En algunas ocasiones, cuando necesitamos auditar una aplicación web de dimensiones considerables resulta interesante automatizar el proceso. Por esta razón, hemos decidido preparar un ejemplo para mostrar una de las formas posibles de hacerlo.

Para ello empleamos el Framework W3af creado por Andrés Riancho y que está disponible para la libre descarga en la página del proyecto.


Obtención de Dojo y Webscarab:

Para el ejemplo que vamos a mostrar hemos empleado la máquina virtual Dojo, disponible en la web de Dojo:


Hemos descargado los ficheros "dojo-v0.2.vmdk" y "Web Security Dojo v0.2.ovf". El archivo .vmdk corresponde al disco duro virtual (que incluye una distribución Ubuntu con varias herramientas "Targets" y varias "Weapons") y el fichero .ovf, que es necesario para crear la máquina virtual en VirtualBox. El proceso para importar la máquina en Virtual Box es muy sencillo, basta con escoger la opción "Importar servicio virtualizado" del VirtualBox y seleccionar el archivo .ovf que hemos descargado.

Las herramientas más interesantes que nos proporciona Dojo son los targets y las weapons:



Por último, hemos descargado el Webscarab (está incluído en la versión 0.4, pero no en la 0.2 que es la que yo utilicé) en la página del proyecto Webscarab, porque vamos a usarlo como proxy.

El motivo de usar Webscarab es, entre otros, porque W3af puede emplear la información capturada por éste. En concreto dispone del plugin 'importResults' de la categoría 'Discovery' que permite importar los resultados desde un fichero en formato CSV, desde el log del Burp y desde el directorio 'conversation' de Webscarab. En nuestro caso queremos emplear la información capturada por Webscarab mediante el crawling (y la navegación manual ;)) que hemos realizado sobre una Web.

A continuación arrancamos el Webscarab con el comando:

java -jar webscarab.jar &

Si es la primera vez que lo empleamos nos aparecerá el modo "Lite", que ofrece poca funcionalidad. Para ello activaremos el modo "Full-featured interface", reiniciaremos la aplicación y tendremos todas las opciones disponibles.




Preparación del Entorno:

Una vez disponemos de las herramientas necesarias, procedemos a preparar el entorno. Para ello solo necesitamos configurar el navegador, indicando que todas las peticiones vayan a través del proxy Web que deseemos utilizar. Para cambiar fácilmente de proxy emplearemos el complemento (add-on) de Firefox MM3-ProxySwitch, que permite lo que su nombre indica, cambiar de proxy :)

En él podemos definir todos los proxy Web necesarios y cambiar de uno a otro con un click de ratón. En mi caso suelo emplear con mayor frecuencia Paros Proxy, Webscarab y Burp Suite.

Definiremos una nueva configuración para el proxy Webscarab, para ello escogeremos la opción Edit del "ProxySwitch". Veámoslo en las siguientes imágenes:




Realización del crawling y la navegación por la página:

Una vez que tenemos el entorno funcionando levantamos la aplicación "Hacme Casino" desde el menú "Applications->Targets->Hacme Casino Start".

Procedemos a registrarnos en el Casino, navegamos por sus páginas mientras vamos visualizando, en el Webscarab, los recursos (directorios y ficheros) que vamos descubriendo en la aplicación Web.



Conforme vamos encontrando nuevos directorios empleamos la función "Spider tree" para que Webscarab siga los links e intente encontrar más ficheros en el servidor Web. Así:


Por último, guardamos la sesión del Webscarab, ya que luego alimentaremos al w3af con esta información.


Automatizando con W3af

¿Por qué no uso los plugins de discovery y bruteforce del w3af?

En circunstancias normales deberíamos emplear los distintos plugins que w3af nos ofrece, para efectuar un descubrimiento completo, escogiendo los que resultasen más adecuados para la aplicación Web que estamos auditando. Elegimos unos u otros en función de la tecnología empleada, si está ubicada en red local o a través de Internet, etc. En el caso en que nos ocupa trato de reproducir una situación en la que ya había realizado el crawling completo de la aplicación (explicado más arriba) y estaba bastante seguro de que no había obviado nada, ya que el servidor Web tenía una vulnerabilidad de Directory Listing , que permitía ver el contenido de los directorios.

A continuación vamos a mostrar los comandos empleados para lanzar el W3af. De esta forma:

./w3af_console

Procedemos a cambiar el timeout ya que la web que pretendemos auditar está en nuestra red local (en localhost):

w3af>>> http-settings
w3af/config:http-settings>>> set timeout 5
w3af/config:http-settings>>> back
w3af>>>


Escogemos los plugins para detectar XSS y SQL Injection:

w3af>>> plugins
w3af/plugins>>> audit xss,sqli


Definimos la salida que obtendremos indicando que queremos visualizarlo por consola y guardarlo en un fichero de texto plano:

w3af/plugins>>> output console,textFile
w3af/plugins>>> output config textFile
w3af/plugins/output/config:textFile>>> set fileName prueba.txt
w3af/plugins/output/config:textFile>>> back


Para importar los links guardados por el Webscarab:

w3af/plugins>>> discovery importResults
w3af/plugins>>> discovery desc importResults
This plugin serves as an entry point for the results of other tools that search for URLs.
The plugin reads from different input files and directories and creates the fuzzable requests
that are needed by the audit plugins.


Three configurable parameter exists:
- input_csv
- input_burp
- input_webscarab
w3af/plugins>>> discovery config importResults
w3af/plugins/discovery/config:importResults>>> set set input_webscarab /home/dojo/webscarab/conversations
w3af/plugins/discovery/config:importResults>>> back
w3af/plugins>>> back


Por último, definimos el objeto a analizar (en este caso la aplicación Foundstone Hacme Casino) en nuestro puerto 3000:

w3af>>> target
w3af/config:target>>> set target http://localhost:3000
w3af/config:target>>> back
w3af>>> start


El w3af se pone a trabajar y los resultados nos muestran varios parámetros inyectables y un listado de posibles vulnerabilidades, que luego verificaremos a mano para eliminar falsos positivos:


¡Hasta luego!

lunes, 1 de febrero de 2010

Ocultación XSS/CSRF en Short URL

En los últimos tiempos se ha puesto muy de moda Twitter (ando probandolo recientemente), que como todos sabreis es una manera cómoda de compartir mensajes cortos, reenviar los mensajes de otros a nuestros otros contactos, etc. Con la aparición de Twitter y la limitación de 140 caracteres por mensaje surgieron los primeros problemas: ¿cómo pongo una URL? Si es del tipo http://www.pentester.es no hay ningún problema, es corta y podemos incluirlo en nuestro mensaje. Sin embargo las limitaciones del Twitter se pegan de morros con la longitud actual de las URL, sobretodo cuando referenciamos a posts o artículos concretos de un periódico: http://www.pentester.es/2009/09/conferencias-source-barcelona-21-y-22.html .Esta última son, por si sola, 77 caracteres.

Como respuesta, han aparecido muchísimos servicios para hacer "Short URL Redirection", es decir, tú le das a la web la URL más larga que un día sin pan y él te lo convierte a algo del tipo http://bit.ly/9qAPvE, que aunque mucho menos legible, es mucho más corta y no nos va a dar ningún problema. Cuando el usuario pinche sobre esa URL será redireccionado inmediatamente a la URL larga, y todo funcionará sin mayor problema.

¿Sin mayor problema? Va a ser que no...

Cada vez está todo el mundo más acostumbrado a pinchar en este tipo de enlaces sin pensar que no tenemos ni idea de sobre que estamos pinchando.

Así que... vamos al grano, vamos a suponer que tenemos una web vulnerable a XSS o CSRF y que la URL con la que conseguimos explotarla es la siguiente:



Vale, ya tenemos una URL para que si alguien la pincha ejecute las acciones que queremos. En este caso algo tan tonto como sacar un mensaje con la versión del navegador, pero podriamos haber estado robando cookies o cualquier otra maldad.

Para disfrazar nuestro ataque un poco más, vamos a modificar un poco la URL que tenemos para que tras ejecutar nuestro script sea redirigida a otra página, así la aparición de la URL con el código del script será solo instantanea, y es probable que el usuario no se de cuenta ni de que está pasando (eso si estuvieramos usando algo que no fuera un "alert", claro).



Esto nos va a hacer ejecutar primero nuestro script y posteriormente ir a la raiz de esa misma web, aunque podriamos haber elegido cualquier otro path o incluso otra web, por ejemplo hacer pensar que queremos ir a una web X y que el enlace vaya a una web Y, robe cookies y posteriormente redirija a la web X, con lo cual se completa el engaño.

Bien, ahora que ya tenemos nuestra URL maliciosa, ya solo tenemos que ponerle un poco de chapa y pintura para que parezca otra cosa, y aquí es donde entran los servicios de Short URL. De entre estos servicios, hay algunos que tienen la precaución de filtrar los caracteres peligroso, pero es posible encontrar en Internet algunos que no lo hacen. Sin embargo, nos vamos a poner en el caso en que lo hagan, como hace por ejemplo bit.ly, que sería el caso más complicado.

Y si nos van a filtrar mayores, menores, comillas, etc... ¿cómo lo hacemos?
La respuesta es... pues vamos a hacer un salto intermedio, en lugar de con una con dos redirecciones.

Así pues, voy a la web de bit.ly y le pongo el enlace al servidor web público bajo mi control, devolviendome esta URL corta: http://bit.ly/9fwBrb



Una vez hecho esto, solo tengo que ir a esta página y crear un pequeño index.html que redirija de nuevo a la web vulnerable, lanzando el exploit:



Como podeis ver, he tenido que cambiar el "/" por un String.fromCharCode(47), que es exactamente lo mismo, pero que haciendolo así me evito usar las comillas, que como ya las estoy usando en el "onload" me puede dar problemas.

Pues bien, ya tenemos la URL con la que atacar, nuestra web preparada para que cualquiera que la visite sea redirigido a la URL con el ataque, y una URL Corta que apunta a la web bajo nuestro control, así que solo tenemos que dejar esta URL Corta en algún sitio anunciando algo interesante y...



Inmediatamente tras aceptar el mensaje que nos aparece (si hubieramos puesto un robo de cookies se hubiera realizado sin necesidad de intervención del usuario), el navegador redirecciona la web a la que queremos, la página principal:



Así que ya sabeis, mucho ojito con las URLs Cortas y con las Rusas en ropa interior, tienen mucho peligro y no sabemos lo que pueden esconder...