16 de enero de 2012

Client Side Attacks (I): Introducción

  ****************************************************
    Client Side Attacks (I): Introducción
    Client Side Attacks (II): Infectando Navegadores
    Client Side Attacks (III): Sacando provecho
    Client Side Attacks (IV): Otros ataques
  ****************************************************

Hace unas semanas publiqué un artículo en el número 1/12 de la revista Hakin9. En el artículo hablaba de cómo sacar provecho de vulnerabilidades del lado del cliente (XSS, CSRF, Cross Domain...). Para aquellos que no tengan acceso a la revista original o no se sientan cómodos leyendo en la lengua de Shakespeare, voy a contar en una serie de entradas la mayor parte de lo que trataba el artículo.

Para empezar, cuando en Seguridad Web nos referimos a Client Side Attacks, o Ataques del Lado del Cliente, nos estamos refiriendo a todas aquellas técnicas que permiten explotar una vulnerabilidad que afecta a los usuarios del servidor web.

Para entenderlo mejor, veamos dos ejemplos de inyección de código:

  • Una inyección de código SQL. En este caso, la vulnerabilidad afecta a una aplicación / base de datos que se encuentra en el servidor, por lo que esta vulnerabilidad se considera que es del lado del servidor.

  • Una inyección de código HTML / script (es decir, un Cross Site Scripting). En este caso, aunque la aplicación vulnerable se encuentra hospedada en el servidor (obvio), al explotar la vulnerabilidad, los que se ven afectados son los usuarios o clientes de la aplicación. Por ejemplo, si utilizáramos el XSS para modificar el contenido de una página web, el servidor no sufre cambio alguno pero los clientes que accedan a la URL con la inyección de código se verían afectados por la vulnerabilidad que no permitiría visualizar el contenido original. En este caso estamos ante una vulnerabilidad del lado del cliente.

Existen muchos tipos diferentes de ataques del lado del cliente aunque, sin duda alguna, el más conocido es el Cross Site Scripting (XSS).

Cuando la gente piensa en un XSS, suele pensar en una ventana de error con la palabra "XSS" o, como mucho, con la cookie del usuario:


Por este motivo, es habitual que los desarrolladores web o incluso los responsables de seguridad de las empresas no se tomen esta vulnerabilidad en serio y no consideren que merezca la pena invertir esfuerzos en corregirla.

Cierto es, que es muy llamativa para los medios de comunicación y muy fácil de distribuir. Por ello también es muy habitual encontrar noticias como ésta, de hace un par de años, en la que se afirma que han hackeado la web de la Presidencia Europea subiendo una foto de Mr. Bean. ¡Nada más lejos de la realidad! Como decía antes, los XSS no afectan a los servidores, por lo que ni el servidor ha sido "hackeado" ni se ha subido nada

Entonces... además de porque son divertidos y pueden llegar a ser un quebradero de cabeza si sale en algún medio de comunicación, ¿para qué pueden servir?

La primera posibilidad que os voy a mostrar es Shell of the Future (sotf), de Attack and Defense Labs. Una curiosa herramienta que te permite robar sesiones de usuario (Session Hijacking) de una manera interactiva y bastante cómoda.

La herramienta, desarrollada para Windows, consta de un servidor y de un proxy web que permiten la interacción con la misma. Pero lo más interesante de ella son dos scripts en Javascript que son los que hay que inyectar en el navegador de nuestras víctimas y que permiten robar la sesión de los usuarios. Los scripts envían toda la información necesaria al servidor web de soft, que es con el que nosotros, como atacantes, utilizamos.

Para que os hagáis una idea, el procedimiento es el siguiente:
  1. Arrancaríamos el servidor web y el proxy.
  2. Accederíamos a la consola de sotf pasando a través del proxy (que suele ser la URL http://127.0.0.1/sotf.console si dejamos la configuración por defecto).
  3. Inyectamos alguno de los dos scripts en el navegador de nuestras víctimas. Por ejemplo publicando la URL con la inyección en un foro.
Una vez hecho esto, en la consola de sotf veríamos las sesiones de las víctimas que han pinchado en el enlace con la inyección y desde la misma consola podríamos elegir la que queremos suplantar. Al estar pasando por el proxy, es éste el que se encarga de sustituir nuestra cookie por la de la víctima, haciendo que el proceso de suplantación sea bastante transparente.

Lo mejor creo que es que la veáis en acción:


Lógicamente, la sesión tan sólo se mostrará en la consola de sotf mientras dure la inyección en la víctima. Es decir, que si el usuario "infectado" pulsa sobre cualquier enlace de la página y se sale de la URL maliciosa, dejaríamos de tener el control a través de sotf. Ésta es precisamente la diferencia entre los dos scripts. El que se llama "e1.js" no hace nada para resolver esto, por lo que es muy posible que la sesión nos dure poco. Sin embargo, "e2.js" hace que pulse donde pulse el usuario, abra una nueva pestaña en el navegador pasando el foco a esta pestaña y dejando la "infectada" en segundo plano. Con un poco (bastante en realidad) de suerte, el usuario no notará nada y permitiría mantener la sesión durante más tiempo.

Si probáis a jugar con la herramienta, veréis que tiene muchas deficiencias. No obstante, considero que es una herramienta interesante y, desde mi punto de vista, creo que puede ser útil para hacer presentaciones sobre lo que se puede llegar a hacer por medio de la explotación de un Cross Site Scripting.

Hasta aquí esta primera entrada, en la que os he presentado en qué consisten los ataques del lado del cliente con un ejemplo. A partir de la próxima entrada de la serie veremos cómo sacar más partido a este tipo de técnica tratando, además, de pasar desapercibidos.

9 de enero de 2012

Crackeando un Hash Cracker (Contribución)

Los que sigáis a José Selvi en su blog "Pentester.es", habréis comprobado que he comenzado el año con una colaboración que vamos a publicar en varias entradas.

Tanto en esta primera entrada como en las siguientes, trataré diferentes tipos de vulnerabilidades web con el objetivo de que veáis lo peligroso que puede llegar a ser cometer fallos de programación que permitan realizar inyecciones de código.

La primera vulnerabilidad de la que hablo es un Cross Site Scripting bastante "curioso" pero que es totalmente explotable y, como tal, debe ser evitado:

Crackeando un Hash Cracker (I): XSS con MD5
Crackeando un Hash Cracker (II): CMDi
Crackeando un Hash Cracker (III): SQLIi con MD5

¡Espero que os resulten interesantes!