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?