[WEB PENTESTING] SSL Capture Password

Nous nous mettons dans le cas d'un audit d'un site WEB utilisant le protocole SSL. Alors que la plupart des internautes y voient une sécurité certaine, l'utilisateur averti connaît les faiblesses de ce protocole quand il est mal configuré. Ce post commencera par évaluer la robustesse de la sécurité de la communication. Dans un second temps, nous exploiterons le protocole s'il peut être affaibli (ou s'il l'est déjà ...).

1 - Quelques informations nécessaires.

Le protocole SSL existe en plusieurs versions. Vous trouverez sur Internet toutes les informations nécesaires. Pour commencer, Wikipédia est certainement un bon début grâce à l'article dédié à ce protocole [ici].

Mais pour la suite, nous avons juste besoin de savoir que nous trouvons principalement sur le WEB :

• CAS 1 : Des serveurs WEB reposant sur un certificat SSLv2 vulnérable à des attaques de type Man-in-the-Middle ;
• CAS 2 : Des serveurs WEB reposant sur un certificat SSLv3/TLSv1 mais supportant aussi le protocole SSLv2. Ils deviennent alors eux aussi vulnérables au mêmes type d'attaque ;
• CAS 3 : Des serveurs WEB reposant sur un certificat SSLv3/TLSv1 et ne supportant que ce protocole. Ces serveurs ne sont pas vulnérables sauf si la clé de chiffrement est faible.

Le certificat par défaut peut utiliser un algorithme de chiffrement robuste mais cela n'empêche pas qu'il peut supporter des algorithmes de chiffrements plus faibles.

2 - Le serveur audité est-il vulnérable ?

Pour résumer la première partie, la réponse sera "oui" s'il supporte le protocole SSLv2 et/ ou s'il supporte des algorithmes de chiffrement basée sur une clé trop faible.

Pour effectuer nos tests, nous allons étudier l'outil SSLDigger de Foundstone [télécharger].

Le certificat par défaut peut utiliser un algorithme de chiffrement robuste mais cela n'empêche pas qu'il peut supporter des algorithmes de chiffrements plus faibles.

Après avoir lancé l'outil et entré l'adresse du site, appuyez sur le bouton "GO". De suite, nous voyons que le certificat repose sur un algorithme RSA et une clé de chiffrement de 1024 bits : c'est bon ! De plus, nous remarquons qu'il est signé par une entité reconnue.

Mais supporte-t-il aussi des protocoles faibles ? Pour cela, SSLDigger lance automatiquement les tests si vous avez cliqué sur sur "oui" sur la popup apparue à l'ouverture de l'outil. Sinon, vous trouverez un bouton "SSL test" sur l'interface.

Une fois les tests terminés, cliquez sur "oui" pour enregistrer et voir le rapport. En l'occurrence, nous voyons que des protocoles faibles sont supportés (3 exactement) :

Le détails de ces protocoles est donné plus loin dans le rapport. Il est donc techniquement possible de casser la clé de chiffrement après s'être connecté avec l'un des algorithmes comportant une clé de longueur trop faible. Cela se fait à l'aide d'OpenSSL notamment mais ce n'est pas cette voie que nous allons détailler.

Nous allons néanmoins de suite utiliser cette commande pour voir si le site audité supporte le protocole SSLv2 :

openssl s_client -ssl2 -connect www.cible.com:443

Bingo ! Nous nous connectons au serveur en SSLv2. (NB: avec le protocole DES-CBC3-MD5, l'un des protocoles repérés par SSLDigger).

Alors nous pouvons passer à la suite !

3 - Lancement d'une attaque de type Man-in-the-Middle

3.1 - Préparation

Pour mener l'attaque, nous aurons besoin d'un seul outil, Ettercap [télécharger].

Configuration (si vous utilisez ipchains/iptables) :

1. Ouvrir etter.conf ;


2. Décommenter les lignes :
   
   
   
   1. redir_command_on
   
   
   2. redir_command_off
   
   
   
   

Le scénario est le suivant :

• 1 serveur qui correspond à nos critères de la phase 2 ;
• 1 machine victime qui se connecte vers se serveur après authentification ;
  
• 1 machine pirate qui se placera entre les deux machines pour mener une attaque de type MiTM.

3.2 - Lancement de l'attaque

On commence par vérifier que toutes les machines sont localisées (en ligne de commande "T", sur l'interface eth0 "i") :

ettercap -Tqi eth0 // //

On devrait voir l'adresse de la victime et celle du routeur commun (cadre rouge) alors que l'adresse du pirate apparaît en haut (cadre vert) :

L'attaque se lance avec la commande suivante :

ettercap -Tqi eth0 -M arp -l mission /adresse-routeur/ /adresse-victim/

Vous capturerez le compte dès que la victime se connectera sur le site avec son couple login/mot de passe.

Par la suite, nous pouvons retrouver les résultats en lisant le fichier de capture :

etterlog mission.eci

The account is owned! Have fun! :)

[SECURITY] Datacenter

Lors d'un pentest pour une entreprise, vous devrez certainement vous attaquer à un Datacenter car c'est bien là que sont installés les serveurs et équipements réseau du SI de la compagnie. De suite, nous comprenons l'enjeu de sécuriser le Datacenter ... Dans ce post, nous ne verrons qu'un seul aspect de la sécurité, les contrôles logiques.

1 - Apporter et maintenir le niveau de sécurité

1.1 - Application des bonnes pratiques systématique :

Un Datacenter "vit" et même sécurisé, le moindre changement peut ébranler son niveau de sécurité. Par exemple, dans le cas de l'installation d'un nouveau serveur, les principales mesures à prendre en compte sont :

• le système d'exploitation du serveur doit être "masteriser" avec les seules applications nécessaires et une sécurisation en amont si possible ;
• seuls les comptes nécessaires doivent être autorisés à se connecter à la machine que ce soit localement ou à distance ;
• seuls les services utiles doivent tourner. De plus, ils ne doivent être lancés "automatiquement" que si cela est nécessaire pour le bon fonctionnement du serveur et des applications hébergées. Sinon, une activation "manuelle" et un service arrêté au démarrage du système est préférable. Enfin, un compte de service avec des droits restreints doit être accordé au service ;
• la configuration des modules systèmes et des applications doit être travaillée. Par exemple, seules les communications sécurisée via SSH sont autorisées. Cela passe par la configuration du service de même nom via des fichiers de configuration comme sshd_config.

1.2 - Renforcement de la sécurité d'un système

Pour assurer tous les piliers de la sécurité à une machine, il nous faudrait installer idéalement :

• un agent de sauvegarde pour la disponibilité des données ;
• un agent chargé de surveiller l'intégrité des informations (ex : Tripwire) ;
• un agent chargé de tracer les évènements pour la non-répudiation des actions (ex : Syslog) ;
• le chiffrement des disques pour la confidentialité.
  

Dans la réalité, la société devra étudier et classer ses serveurs selon sa criticité (en général, en fonction de son exposition et des données contenues). Alors, la sécurité apportées doit être en adéquation avec le niveau de criticité attribué à la machine.


2 - La gestion des incidents

Personne n'est à l'abri d'un incident. Et lorsque cela arrive, il faut être en mesure de :

• le repérer. Cela peut se faire idéalement à l'aide d'un SOC et d'une équipe de monitoring pour l'animer. Ce SOC devrait reposer sur une solution de corrélation de logs (ex : OSSIM) ;
• le cerner. L'incident peut être de nature diverse. Ensuite, il peut être plus ou moins prioritaire. Mais avant tout, il faut être sûr qu'il ne s'agit pas d'un faux positif. Il faut donc vérifier la pertinence de l'alerte reçue. Si l'alarme est justifiée, l'incident doit être signalé à toutes les personnes impliquées ;
• l'analyser et le traiter. Un incident reconnu doit être pris en charge par l'équipe sécurité. Celle-ci entame alors une investigation pour déterminer la nature exacte de l'attaque, sa provenance, ses conséquences / actions et les actions à prendre en compte dans l'immédiat pour éviter une propagation par exemple et à échéance pour éviter le reproduction d'un incident de même nature.
  

Diverses mesures permettent d'obtenir une gestion d'incident efficace. Pour citer quelques exemples, une solution éprouvée doit être mise en place pour repérer les incidents avec fiabilité, une procédure détaillée doit être instaurée pour s'assurer qu'un incident sera traité de bout en bout et les moyens doivent être mis à la disposition des opérationnels sécurité pour mener à bien la phase d'investigation.

3 - Pérennisation de la sécurité logique

Pour faire face aux menaces continues des attaquants et pour se préparer contre les nouveaux vecteurs d'attaques. Pour cela, voici un résumé des recommandations qui peuvent être mises en place :

• une gestion des mises à jour rigoureuse. En plus du déploiement d'une solution telle que SCCM pour le déploiement des mises à jour, la compagnie devrait s'abonner à une liste de veille sécurité. Ainsi, les équipes sécurité seront au courant des menaces en quasi temps réel. Alors, en cas d'attaque critique (e.g. Ver), une procédure d'urgence d'application de patch doit être déroulée ;
• effectuer un audit de configuration. Pour s'assurer que les recommandations sécurité sont appliquées correctement, des audits de configuration avant la mise en production et régulièrement devraient être planifiés. Par exemple, il pourrait s'agir de vérifier qu'une application WEB et les client autorisés ne communiquent qu'en TLSv1 pour assurer l'intégrité et la confidentialité des données échangées ;
• effectuer des audits de vulnérabilité (ou mieux, des tests d'intrusion). Pour s'assurer de la robustesse d'un équipement du Datacenter, le mieux est d'effectuer un test d'intrusion sur cet élément ou à défaut, un test de vulnérabilité. Effectués régulièrement, ils permettent de s'assurer de la sécurité de la machine dans le temps. Evidemment, cela suppose que les actions correctives sont apportées concernant les failles trouvées pendant l'audit...
  

Finalement, toutes les mesures à prendre en compte ont pour objectif de garantir la concordance entre le niveau de sécurité des équipements et la politique de sécurité de l'entreprise.

Conclusion

Le post a présenté les aspects logique en termes de sécurité IT d'un Datacenter. Cependant, les mesures apportées ne seront efficaces que si elles sont accompagnées d'une sécurité organisationnelle et physique. A quoi bon blinder ses serveurs s'il est possible d'accéder facilement à la salle contenant les machines ? A quoi bon prévoir des solutions de sécurité drastiques si elles ne sont pas (ou mal) appliquées grâce à des procédures précises et connues par les personnes impliquées ? C'est pourquoi, pour aller plus loin et aborder ces autres aspects de la sécurité, je vous propose la lecture de l'article sur la sécurisation des datacenters paru dans Hakin9 de nov/déc 2008. Vous verrez, l'auteur est très sympa ;)

[PENTESTING][DNS]Train with backtrack's tools

Lorsque vous cherchez à auditer un serveur DNS, il existe de nombreux outils à votre disposition. En l'occurrence, la Backtrack vous en propose un certain nombre. Nous allons nous amuser un peu avec aujourd'hui pour mieux les comprendre. Nous avons déjà vu précédemment DnsEnum, plus complet mais cette fois, il s'agit d'opérer sur des points plus précis. C'est parti !

1 - DNS-ptr

But : Effectuer un grand nombre de requêtes DNS inverses pour trouver les hostnames de la plage IP auditée.

Syntaxe :

$ dns-ptr adresse-ip-auditée nombre-machines

Exemple :

2 - DNSWalk

But : Tenter des transferts de zones sur l'ensemble des adresses récupérées.

Syntaxe :

$ dnswalk adresse-ip-auditée

Exemple :

3 - DNSBruteforce

But : Tenter de trouver des machines supplémentaires sur le domaine en devinant les noms de machine, grâce à la technique de Bruteforce.

Syntaxe :

$ ./DNSBruteforce.py domaine-audité server.lst hosts-txt

Exemple :

Astuces :

• Peupler le fichier hosts-txt (ex : apache, gw, gateway, ns0, ns1, ns2, ns01, news, etc...) ;
• Peupler le fichier server.lst avec les serveurs DNS de la cible en lançant la commande suivante ;

$ dig NS cible

• Lancer la commande une première fois (cf. exemple ci-dessous) ;
• Peupler de nouveau le fichier hosts-txt avec les premiers résultats trouvés (ex : gw5, gw6, ... si on a trouvé gw1 à gw4 la première fois) ;
• Relancer la commande.

4 - DNSMap

But : Comme l'outil précédent, il a pour objectif de trouver des machines supplémentaires sur le domaine cible à partir d'un "dictionnaire". De plus, il présente les résultats par type et avec l'adresse IP associée.

Syntaxe :

$ dnsmap domaine-audité liste

Exemple :

Have fun ;)

[PENTEST WINDOWS] Find credentials using TaskManager!

En tant qu'agent confirmé, vous savez que lors d'un pentest sur Windows, vous passerez forcément par l'étape Dump de hashes et crackages. Fastidieux ? Alors voici une nouvelle méthode : passer par le TaskManager !

1 - Contexte

Ce post a pu être réalisé grâce à l'article très bien fait d'Ivanlef0u. Vous y trouverez toutes les explications. Dans le cadre d'un pentest, il faudrait que la machine auditée soit sous Windows donc et qu'une tâche planifiée au moins soit créée. Sachant que les droits administrateurs sont requis pour créer une telle action, nous devrions obtenir des credentials intéressants ;)

Dans la suite de ce post, nous reprenons le scénario depuis le début à des fins pédagogiques. Votre mission est de reproduire les étapes. Attention, vous pourriez être surpris !

2 - Mise en condition

Nous commençons par créer un tâche. Pour exemple, nous décidons de lancer le programme Paint. Mais nous aurions pu choisir n'importe quel autre programme. Deux méthodes :

• en ligne de commande :
  

at 18:05 paint.exe

• avec l'interface graphique :

Aller dans Démarrer > Paramètres > Panneau de configuration > Tâches planifiées. Dans la nouvelle fenêtre, cliquer sur "Création d'une nouvelle tâche" et suivez les instructions du wizard (ex : Paint, toutes les semaines, les jeudis à 22h45). Vous devrez renseigner les credentials ... ce qu'aura fait aussi l'administrateur de la machine auditée lors d'un test d'intrusion !

La figure suivante montre la liste des tâches créées : la première en ligne de commande (At1) et la seconde via la GUI (Paint).

3 - L'attaque

Grâce au programme d'Ivanlef0u, le travail va être très simple mais pas moins impressionnant ! Commencez par télécharger le programme que vous trouverez ici. Décompresser et via l'interpréteur de commande, rendez-vous dans le répertoire d'execution nommé exe\Release.

Il ne vous reste plus qu'à exécuter le programme ...

TaskPwdDmp.exe

... et à admirer le résultat !

Have fun ;)

[INTERNAL PENTEST] Caïn - attack local application

Que le test soit initialement interne ou que vous ayez réussi à obtenir un accès en passant par un accès externe (ex : Internet), il arrivera un moment où vous vous trouverez sur le LAN de la cible. Alors, vous aurez besoin de Caïn qui représentera un réel couteau suisse dans votre aventure ! Nous ne verrons qu'une toute petite partie de ses capacités dans ce billet mais de quoi déjà faire des ravages !

1 - Contexte

Voici le contexte qui représente dans le même temps les conditions nécessaires pour réussir les opérations qui vont suivre :

• nous avons {obtenu} un compte sur une machine du réseau locale de la cible ;
• ce compte a les droits "administrateur local" ;
• l'antivirus sur la machine de travail est inefficace ou vous avez réussi à le désactiver.

Il existe des méthodes de contournement pour la première condition. La deuxième est soit fournie par le client, soit obtenue grâce à une escalade de privilège. Quant à la troisième, nous supposons que la cible est assez sérieuse pour avoir installé un antivirus sur chaque machine. Cependant, pour le désactiver, il faudrait en théorie avoir des droits suffisants sur le domaine, sans quoi, un utilisateur pourrait le désactiver facilement.

2 - Redirection du trafic

Ici, nous souhaitons récupérer les informations sensibles que nous pouvons intercepter sur le réseau interne, en l'occurrence logins et mots de passe. Souvent, se croyant protéger sur son propre réseau, les communications sont en clair sur le réseau en question. Nous verrons que c'est souvent réellement le cas.

Alors, par une attaque appelée ARP Cache Poisoning, nous allons faire en sorte que les associations adresses MAC - Adresses IP soient modifiées dans le but de faire croire que d'autres adresses IP correspondent à notre adresse MAC. Cette attaque bien connue est bien expliquée sur Wikipédia. En plus de récupérer le trafic d'autres utilisateurs, vous le redirigez de sorte que l'opération reste transparente pour les victimes.

C'est ici qu'intervient Caïn ! Vous devriez commencer par le télécharger ici et l'installer si vous ne l'avez pas déjà fait auparavant.

2.1 - Configuration de Caïn

Dans le menu, cliquer sur Configure. par défaut, vous arrivez sur l'onglet Sniffer. Ici, vérifier que la bonne carte réseau est sélectionnée et que l'option "Don't use Promiscuous mode" n'est pas cochée.

Ensuite, rendez-vous dans l'onglet APR. Si vous avez pour but d'être discret, sélectionnez "Use Spoofed IP and MAC address" et modifier l'adresse IP et l'adresse MAC en choisissant des valeurs cohérentes. Les autres paramètres peuvent être laissés par défaut :

2.2 - Lancer la redirection de trafic

Voici la démarche à suivre :

• cliquer sur les boutons "sniffer" et "APR" dans la barre de menu en haut à gauche ;
• cliquer sur l'onglet "sniffer" (en haut) ;
• cliquer sur le sous-onglet "APR" (en bas) ;
• cliquer sur le "+" pour paramétrer l'attaque ARP Cachee Poisoning où vous choisirez la ou les machine(s) cible(s) :
  
  

• c'est bon, le sniffing est en cours !

3 - Interception des mots de passe

Il vous suffit de vous rendre dans le sous-onglet "Hosts" pour obtenir des informations intéressantes.

Encore mieux, allez dans le sous-onglet "Passwords" et là, trouvez tous les mots de passe interceptés, ainsi que les logins associés de tous les credentials qui circulent sur le réseau à travers de nombreux protocoles : HTTP, SMB, LDAP, etc.).

Have fun ;)

[PENTESTING] Get access through HTTP form using Hydra

Lors du dernier post, nous avons rencontré une interface WEB contenant une méthode d'authentification basée sur un mode dit "HTTP-Form". Puisqu'il existe de très nombreuses applications WEB utilisant cette méthode, il y a de grande chance que vous soyez amenés à tester la force du mot de passe. Nous partons du principe ici que l'attaque ne peut se faire qu'online.

NB : Comme tous les posts de ce blog, la démonstration qui suit n'a de vocation que de sensibiliser et prévenir et non de porter atteinte à quiconque, ce qui serait illégal !

0 - Contexte

Dans ce billet, nous reprenons le cas d'une application Jonas. Nous supposons que nous avons trouver l'interface admin grâce à des scanners comme NMAP (ici, il s'agirait d'une application WEB sur le port 9000, port utilisé par défaut par Jonas) ou des scanners WEB comme Nikto ou Wikto qui sont capables de trouver les pages de ce type. Notre cible est donc http://123.123.123.123:9000/jonasAdmin, sachant que c'est ici que se trouve par défaut la page d'administration de l'appli J2EE en question. Aussi, nous savons - ou avons appris suite à nos recherches - qu'il existe un nom d'utilisateur par défaut : jonas. Pour terminer, nous supposons que le mot de passe a été changé et n'est plus celui par défaut (qui serait ici jonas).

1 - A la recherche des informations clés !

Pour réussir notre attaque, nous utiliserons Hydra de THC. Ensuite, nous avons besoin d'un certain nombre d'éléments, à savoir :

• le nom du champ contenant le login dans la page WEB ;
• le nom du champ contenant le mot de passe dans la page WEB ;
• le nom de la page / du script vérifiant la validité ou non du couple login/mot de passe fourni par l'utilisateur ;
• un mot spécifique retourné par la page d'erreur en cas d'échec de l'authentification.
  

Il existe plusieurs méthodes pour obtenir ces informations. Mais la méthode la plus fiable qui nous assurera de toutes les avoir est d'utiliser un proxy local. S'il en existe bien d'autres, nous utiliserons ici Paros.

Une fois Paros lancé, nous configurons notre navigateur de sorte qu'il utilise ce proxy local (par défaut sur le port 8080). Cette opération peut se faire manuellement dans les options de votre navigateur (Outils > Options > Avancé > Réseau > Paramètres) ou via une extension après configuration (ex : l'extension Switch proxy de firefox).


Nous allons maintenant sur la page http://123.123.123.123:9000/jonasAdmin et tapez jonas en tant que login et un mot de passe aléatoire, exemple jonas pour être sûr que le mot de passe par défaut n'a pas été laissé tout simplement.


Effectivement, le mot de passe a été changé. Cependant, nous obtenons la dernière information clé et nous utiliserons le mot Invalid.

Nous retournons maintenant dans Paros :


La première requête POST contient toutes les infos dont nous avons besoin :

• le champ login à utiliser est j_username ;
• le champ mot de passe à utiliser est j_password ;
• la page à utiliser est j_security_check.

Nous sommes parés ! Il est donc temps de passer à l'étape suivante.


2 - Crackage du mot de passe

Pour casser le mot de passe, nous avons deux solutions : soit par brute-force, soit une attaque par dictionnaire. En tant que bon agent de Mission-Security, vous n'aurez pas négligé la phase de prise d'information et vous aurez certainement une bonne idée de ce que pourrez être le mot de passe. Alors, commençons par une attaque par dictionnaire et seulement ensuite, tenter une attaque par brute-force en cas d'échec.
Donc, une fois écrit votre fichier de mots de passe personnalisé pour la cible (appelé ici passwords.txt), nous pouvons lancer Hydra avec la commande suivante (ATTENTION : votre antivirus peut empêcher l'exécution du cracker) :

hydra -l jonas -P password.txt -s 9000 -o results.txt 123.123.123.123 http-post-form "/jonasAdmin/j_security_check:j_username=^USER^&
j_password=^PASS^&submit=Login:Invalid"

NB : avec -s, le numéro du port.

Le résultat ne se fait pas attendre :

Have fun ;)

[WEB PENTESTING] Hack a JOnAS Web Application

Avec le WEB 2.0, les applications WEB se sont largement multipliées, augmentant dans le même temps les failles de sécurité. Parmi ces applis, nous trouvons JOnAS. Le post suivant propose un scénario d'attaque dans le cas où vous trouveriez cette solution.

NB : Comme tous les posts de ce blog, la démonstration qui suit n'a de vocation que de sensibiliser et prévenir et non de porter atteinte à quiconque, ce qui serait illégal !

1 - Avoir accès à la page d'administration

Supposons que nous avons repéré JOnAS - une application WEB téléchargeable sur *NIX et WIN* - sur un serveur cible, tournant par défaut sur le port 9000. Il suffit d'utiliser notre navigateur pour nous retrouver sur la page de la cible (ici, à l'adresse 192.168.123.123 pour notre démonstration, reposant sur une plateforme Windows mais les tests peuvent aussi être lancer sous *NIX) : http://192.168.123.123:9000/jonasAdmin. Vous arrivez sur la page suivante :


Par défaut, les credentials sont jonas/jonas, tentez votre chance ! Sinon, il existe de nombreuses méthodes pour trouver le mot de passe s'il a été changé :

• Avec Brutus (cf. la fin du post "Is your money safe?") ;
• Avec Hydra. Ce deuxième cas fera l'objet du prochain post.

2 - Ajouter le module malicieux

Une fois loggé, nous pouvons déployer un nouveau module sur le serveur. Celui-ci, nommé mission-security.war, contiendra les pages malicieuses ... Pour cela, sur la page d'admin de JOnAS :

• Etendez "Deployment" (colonne de gauche) ;
• Cliquez sur "Web Modules (WAR)" ;
• Cliquez sur le deuxième onglet "Upload" (page principale) ;
• Cliquez sur "Parcourir" pour sélectionner le module ;
• Retrouvez le module sur votre machine ;
  
• Il ne vous restera plus qu'à cliquer sur le bouton "Upload".
  

Vous arrivez sur la page suivante :


Une fois cette opération réussie, il faut :

• Revenir sur le premier onglet, nommé "Deployment" ;
• Le module uploadé devrait apparaître dans la colonne de gauche de la page principale. Cliquez dessus pour le sélectionné ;
• Cliquez sur le bouton ">>>" pour le déployer (partie droite) ;
• Cliquez sur le bouton "Apply" pour finaliser cette étape.

Sur la page suivante, cliquez sur "Confirm" :



3 - Exécuter des commandes arbitraires

Dans votre navigateur, entrer l'URL : http://192.168.123.123:9000/mission-security/

Maintenant, c'est à votre imagination de jouer mais voici certainement l'exemple le plus convaincant :

• Cliquer sur le répertoire "win32/" (toujours en admettant que la cible est sous WIN*) ;
• puis sur la page "cmd_win32.jsp" (ou accessible directement en tapant l'URL http://192.168.123.123:9000/mission-security/win32/cmd_win32.jsp) ;
• Tapez la commande de votre choix. Ici, la commande dir en tant qu'exemple.
  

Plus exactement, le code de cette page est le suivant :


Et maintenant, Have fun !