Suivre le berger par sécurité (Security Shepherd 101)

Il y a quelques temps déjà l’OWASP nous proposait Security Shepherd, une application permettant de découvrir les vulnérabilités des applications web sous la forme amusante d’un CTF (Capture The Flag) ou bien sous la forme plus classique permettant un accès à toutes les vulnérabilités.

Depuis peu l’OWASP fournit également une machine virtuelle contenant Security Shepherd. Et ça c’est plutôt sympathique.

On peut ainsi très facilement publier sur internet le CTF pour jouer avec des amis ou bien proposer des exercices aux étudiants.

L’OWASP devrait également fournir prochainement la possibilité d’ajouter ces propres exercices.

Ce que l’on reproche généralement à ce type d’outil c’est la nécessité de trouver la vulnérabilité telle qu’elle a été pensée par les concepteurs. Et généralement le hacker en herbe n’a pas la possibilité de faire preuve d’imagination et de sortir du carcan du concepteur. C’est en particulier le cas de Webgoat (de l'OWASP également) qui reste malgré tout un très bon outil pédagogique (pour plus d’informations sur Webgoat vous pouvez jeter un œil à Un bug dans Webgoat 5.2? Non! Pas un mais deux…).

Au travers des premiers tests que j’ai pu réaliser avec Security Shepherd, il ne semble pas être aussi contraignant que Webgoat.

Dans ce qui suit nous allons décrire les étapes permettant de mettre en place un petit CTF entre amis.

Je ne m’attarde pas sur la mise en place de la VM, et la publication de Security Shepherd sur internet. C’est assez standard !

1^ère étape : Créer une classe

2^ème étape : Créer vos participants dans une classe

Vous pouvez ensuite visualiser ou changer la liste des participants à une classe donnée.

3^ème étape : Configurer le mode « Capture The Flag »

4^ème étape : Jouer

Après la connection, le participant doit impérativement changer son mot de passe pour pouvoir commencer les exercices.

Un premier exercice est proposé au participant qui peut choisir ses propres outils pour le résoudre.

Une fois l'exercice résolu, une clef est affichée. Cette clef doit ensuite être copiée dans la champ rservé à cet effet en haut de la page, puis soumise au serveur pour que le résultat de l'exercice soit finalement pris en compte.

5^ème étape : Visualiser les résultats en temps réel

L'administrateur peut suivre en direct les résultats du concours. on voit ici que c'est le participant "student1" qui vient de prendre la tête de la course!

Amusez-vous bien !

Note : comme vous pouvez le constater je ne vous donne pour l’instant aucune information sur comment résoudre les exercices pour vous permettre de prendre plus de plaisir dans la recherche des solutions ! Les solutions devraient faire l'objet d'un prochain article très certainement !

Damn Vulnerable Web App…

Au cours de mes ballades dans le web profond, ma route a croisé une vielle VM qui semblait avoir eu un certain succès en son temps! C’était bien avant l’arrivée de Backtrack, enfin je crois!

Cette vielle VM c’est celle de Web Security Dojo de chez Maven Security (http://www.mavensecurity.com/web_security_dojo/)! Et j’ai découvert quelques applications intéressantes que je ne connaissais pas comme par exemple Google’s Gruyere, Hacme Casino et Damn Vulnerable Web App.

A l’instar de Webgoat, ces applications permettent d’apprendre en trouvant et corrigeant les failles de sécurité parsemées çà et là au travers de ces applications web.

Nous allons nous intéresser plus particulièrement à Damn Vulnerable Web App (DVWA) au travers de l’injection SQL à l’aveugle proposée (Blind SQL Injection ou Blind SQLi).

Certains puristes disent qu’une “Blind SQL Injection” se base uniquement sur le temps de traitement de la requête qui indique une réponse positive (e.g. le traitement est plus long) ou négative. Mais certains parlent aussi de “Blind SQLi” lorsque l’affichage change en fonction des résultats. Avec DVWA nous sommes dans ce deuxième cas de figure.

La vidéo ci-dessous détaille la démarche que l’on peut suivre pour ce type d’injection:



C’est fini! Mais nous devrions retrouver les applications de Web Security Dojo dans de prochains articles!

Les failles Cross-Site Scripting: si communes et pourtant si méconnues !

Comme l’indique le site xss attacks information, les failles Cross-Site Scripting (aussi appelé XSS) sont toujours d’actualité bien qu’elles soient connues comme le "loup blanc" depuis de nombreuses années. Mais comme parfois avec ce qui nous est familier, nous en perdons le véritable signification et en oublions le risque. Je ne sais pas pour vous, mais pour moi c'est le cas!

A titre d’exemple, voici une capture d’écran du site de BP ayant subi une attaque XSS:

Nous allons dans ce qui suit décrire ce qu'est le XSS et les différentes formes qu'il peut prendre.

L'attaque "Stored XSS" ou “XSS permanent” dans laquelle le code injecté est stocké de manière définitive sur le serveur cible. Cette attaque peut être réalisé à deux conditons:

• quand les informations transmises par un utilisateur sont stockées côté serveur (par exemple dans une base de données ou des fichiers)
• quand ces informations stockées sont ensuite affichées de nouveau sans que les caractères spéciaux HTML aient été encodés.
  

C’est le cas d’un message écrit dans un forum qui peut être lu par des milliers de personnes.

Ci-dessous vous trouverez une vidéo détaillant la mise en oeuvre d’une attaque “XSS permanent” sur le site Webgoat de l’OWASP:

L'attaque "Reflected XSS" ou “XSS non-permanent” dans laquelle le code injecté est transmis dans la requête et renvoyé par le serveur cible (i.e. utilisation d’un message d’erreur ou d’un outil de recherche).

Mais vous allez me dire que ce n’est pas un problème car l’utilisateur malicieux ne peut injecter du code que dans ses propres pages. Eh bien non! Prenons l’exemple d’un mail de phishing qui vous propose d’aller sur une page avec une URL qui contient le code XSS!

Ci-dessous vous trouverez une vidéo détaillant la mise en oeuvre d’une attaque “XSS non-permanent” sur le site Webgoat de l’OWASP:

L'attaque "DOM Based XSS" ou “XSS local” dans laquelle le code injecté permet de modifier l’arbre DOM dans le browser de la victime permettant à la page web de se comporter différemment (i.e. phase d’authentification court-circuitée).

Comme précédemment un mail de phishing avec une URL prenant en compte la faille peut vous piéger.

Ci-dessous vous trouverez une vidéo détaillant la mise en oeuvre d’une attaque “XSS local” sur le site Webgoat de l’OWASP:

Le XSS est également utilisé dans une attaque nommée Cross-Site Request Forgery ou CSRF. Un précédent article décrit précisément en quoi consiste cette faille et comment la mettre en oeuvre (voir l’article Cross Site Request Forgery par l'image!).

Source: toujours l’OWASP !http://www.owasp.org/index.php/Cross-site_Scripting_(XSS)

Un bug dans Webgoat 5.2? Non! Pas un mais deux…

Eh bien oui, il faut le voir pour le croire mais il y a bien quelques bugs dans la version 5.2 de Webgoat. Webgoat ne fait pas exception à la règle! Dans les développements de sites web il y a des bugs qui parfois échappent à la validation et qui peuvent devenir des vulnérabilités exploitables par des personnes mal intentionnées. Mais heureusement nous ne sommes pas dans ce cadre, Webgoat est fait pour être faillible! Ouf! L’honneur est sauf!

L'objectif de cet article est simplement de vous montrer qu'il est possible de modifier le code de Webgoat. Vous avez toujours la possibilité de récupérer Webgoat 5.3 si vous le souhaitez.

On peut trouver tous les bugs de Webgoat à l’URL suivante: http://code.google.com/p/webgoat/issues/list

Mais puisque nous disposons du code source et d’Eclipse (voir “Modifier le code source de Webgoat, c’est possible!”), nous n’allons pas nous priver du plaisir de faire les corrections.

Bug 1 dans la leçon DOM injection de Ajax Security(référence 28)

Dans le code source de la page, on trouve:

<input name='key' value='' type='TEXT' onkeyup='validate();' >

Or plus loin on trouve:

var keyField = document.getElementById('key');

Il n’y a pas de paramètre “id” avec la valeur ‘key’ mais un paramètre “name”, il est donc nécessaire d’ajouter le paramètre “id” et de lui donner la valeur ‘key’

Dans la méthode Element createContent(WebSession s) de la classe org.owasp.webgoat.lessons.DOMInjection (fichier DOMInjection.java), on ajoute donc la ligne ci-dessous qui permet d’ajouter un tag “id” et de lui donner la valeur ‘key’:

Input input1 = new Input(Input.TEXT, KEY, "");
input1.addAttribute("onkeyup", "validate();");

// Fix
input1.setID(KEY);

tr.addElement(new TD(input1));
t1.addElement(tr);

Bug 2 dans la leçon DOM injection de Ajax Security(référence 32)

Dans le code source de la page on trouve:

var result = req.responseXML.getElementsByTagName('reward');

Mais la valeur req.responseXML est nulle lors de l’exécution avec Firebug

Par ailleurs on peut observer que la variable result n’est pas utilisée.

Pour résoudre notre problème on peut donc simplement commenter la ligne dans la méthode Element createContent(WebSession s) de la classe org.owasp.webgoat.lessons.DOMInjection (fichier DOMInjection.java)

Environnement de développement

Lorsque vous sauvegardez une modification dans Eclipse, le “build” est automatiquement lancé et le serveur est mis à jour (cf. Project/Build automatically).

Il ne reste alors qu’à recharger la page dans le browser et votre correction est immédiatement prise en compte.

Etonnant non!

Tags:

- Technorati Tags: Webgoat,OWASP

- del.icio.us Tags: Webgoat,OWASP

- BuzzNet Tags: Webgoat,OWASP

Modifier le source de Webgoat, oui c’est possible!

Si comme moi vous avez eu le besoin ou l’envie de modifier le code de Webgoat, soit pour y ajouter votre propre leçon, soit pour corriger un bug (eh oui il y en a parfois!), alors vous allez être ravi. Oui, l’OWASP permet aux utilisateurs de Webgoat de modifier le code source.

Tout d’abord un petit rappel sur les principales versions de Webgoat actuellement disponibles:

• Webgoat 5.3 est disponible en RC1 (première Release Candidate de cette nouvelle version) depuis le 10 novembre 2009


• Webgoat 5.2 est disponible en version finale depuis le 12 juillet 2008

Contrairement à la version 5.2, la récente version 5.3 ne propose pas encore une version incluant le code source. C’est pourquoi nous allons nous intéresser à Webgoat 5.2.

Dans cet article nous allons voir comment installer Webgoat 5.2 fournit avec le code source et l’éditeur Eclipse. Puis dans un prochain article, nous essaierons de corriger un petit bug de la version 5.2.

Installation de Webgoat 5.2 avec le code source

Sur http://sourceforge.net/projects/owasp/files/WebGoat/ choisir le répertoire Webgoat 5.2 et télécharger le fichier WebGoat-OWASP_Developer-5.2.zip

Extraire le fichier sous “C:”. Vous devez alors trouver dans “C:\WebGoat-5.2”, le fichier “Eclipse-Workspace.zip”

Extraire ce zip dans ce répertoire. Vous devez alors avoir le nouveau répertoire suivant: “C:\WebGoat-5.2\eclipse”

Lancer alors “C:\WebGoat-5.2\eclipse.bat”. Vous avez alors accès au projet Webgoat.

Sélectionner “Window/Open perspective/Java” ou “Window/Open perspective/Other/Java” et vérifier que les projets “Servers2” et “Webgoat” sont bien présents dans l’onglet “Project Explorer”. Vous pouvez faire un clique droit sur “Servers2” et sélectionner “Refresh” (idem pour le projet “Webgoat”).

Lancer Webgoat via Eclipse. Pour cela sélectionner “Window/Open perspective/Resource” ou “Window/Open perspective/Other/Resource” et dans l’onglet “Servers” séléctionner la ligne “Webgoat Tomcat v5.5 server at localhost”, faites un clique droit et sélectionner “Start”. L’état de ce serveur doit alors passer à “Started”

Enfin dans votre browser préféré, vous pouvez entrer l’URL: http://localhost/WebGoat/attack

Tags:

- Technorati Tags: Webgoat,OWASP

- del.icio.us Tags: Webgoat,OWASP

- BuzzNet Tags: Webgoat,OWASP

Membre de l'OWASP! Yes!

Faîtes comme votre serviteur, devenez membre (ou devrais-je dire adhérent) de l'OWASP.

Pour la modique somme de 50 dollars soit environ 35 euros (en fonction des fluctuations du cours), vous pouvez rejoindre la communauté OWASP de ceux qui se sentent concernés par la sécurité des applications web et qui veulent que les choses changent!

En retour vous ne serez pas en reste car vous recevrez, un magnifique T-Shirt pour les étés torrides...

une vraie carte de membre pour impressionner...

et un merveilleux diplôme à afficher au dessus de votre bureau.

Rejoignez le mouvement...!

Source: Open Web Application Security Project http://www.owasp.org/

Challenge Webgoat 5.2: la solution en vidéo

Vous connaissez tous Webgoat, le site web permettant de faire des tests de pénétration fournit par l'OWASP.

Et vous savez également tous que les solutions des exercices de pénétration proposés par Webgoat se trouvent à l'adresse suivante: http://yehg.net/lab/pr0js/training/webgoat.php

Et comme moi, il ne vous a pas échappé que certains exercices n'étaient pas corrigés. C'est en particulier le cas du challenge proposé par Webgoat 5.2.

C'est pourquoi je vous propose de vous donner la solution du challenge avec l'aide d'une vidéo (que vous pouvez visualiser ICI).

La solution est composée de 3 étapes:

- la découverte d'une fonctionnalité de visualisation du code Java n'apparaissant pas dans la barre de menu mais malgré tout disponible
- une injection SQL classique
- et enfin une injection de commande DOS

Bien entendu, nous utilisons Webscarab pour observer et modifier les requêtes HTTP.

Bon film!

Comment détecter les failles de type XSS?

Si vous souhaitez automatiser la recherche des champs de saisie permettant de réaliser des attaques de type "XSS", vous pouvez utiliser l'outil "XSS Me" (add-on de Firefox)

Voici le résultat des tests avec "XSS Me" sur l'exercice "Reflected XSS attacks" de Webgoat:



On découvre que le champ "field1" est faillible.

L'inconvénient de la démarche automatisée est que de nombreux "faux-positifs" peuvent apparaître. Les outils automatisés ne sont généralement pas capables de détecter si la validation des paramètres est réalisée ou non.

L'approche manuelle est plus précise. Vous pouvez pour cela utiliser le script suivant:




Il suffit alors de saisir ce script dans les champs à tester. Si vous obtenez le pop-up ci-dessous alors le champ testé est faillible.


Il ne vous reste plus qu'à développer votre attaque en écrivant le script de votre choix. Vous trouverez un tutorial JavaScript sur le site:

http://www.w3schools.com/JS/default.asp

Par ailleurs vous trouverez les vidéos décrivant les solutions des exercices de Webgoat sur le site:

http://yehg.net/lab/pr0js/training/webgoat.php

Vous y trouverez également des scripts équivalents à ceux utilisés pendant le séminaire.