Sécurisation des applications Web
Propriétés
|
Description
|
Intitulé long
|
Exploitation d'une plateforme d'apprentissage
des vulnérabilités des applications web
|
Intitulé court
|
Sécurisation des applications web
|
Formation concernée
|
BTS Services Informatiques aux
Organisations
|
Matière
|
Bloc 3 :
Cybersécurité des services informatiques en deuxième année SLAM
|
Présentation
|
Cet atelier a pour objectif d'exploiter la
plateforme d'apprentissage Mutillidae (OWASP) afin de se
familiariser avec les principales vulnérabilités des applications
web.
Chaque activité couvre une problématique
spécifique (SQLi, XSS, CSRF…) en référence au top 10 des
vulnérabilités décrites par l'OWASP (page 4).
Dans un premier temps, Vous devez réaliser les
attaques associées à chaque vulnérabilité.
Dans un deuxième temps, l’objectif est
d’analyser et de comprendre les codes sources des scripts présentés
dans leur forme non sécurisée puis sécurisée en tant que
contre-mesure.
Cette deuxième activité traite des
problématiques d’authentification et de gestion des sessions.
|
Notions
|
Activités supports de l’acquisition des compétences
D4.1 –
Maintenance d'une solution applicative
●
A4.2.1 Analyse et correction d'un dysfonctionnement, d'un problème
de qualité de service ou de sécurité.
Savoir-faire
●
Programmer un composant logiciel.
●
Adapter un composant logiciel.
●
Valider et documenter un composant logiciel.
Savoirs
associés
●
Techniques de sécurisation.
|
Prérequis
|
Commandes de base
d’administration d’un système Linux, langages PHP et JavaScript.
Avoir lu la présentation et réalisé les installations nécessaires à
l’activité 1.
|
Outils
|
Deux machines
virtualisées (sous Virtualbox) sont fournies avec Linux (Debian 9)
comme système d’exploitation.
Site
officiel : https://www.owasp.org
|
Mots-clés
|
OWASP, Mutillidae, BurpSuite, vulnérabilités,
SQLi, XSS, IDOR.
|
Durée
|
Une heure pour cette activité.
|
Activité 2: Vulnérabilités liées à
l’authentification et à la gestion des sessions..................................................................................................
1
I
Présentation générale...............................................................
2
1
Le risque A2 du top 10 d’OWASP...........................................
2
2
Conséquences......................................................................
2
3
Bonnes pratiques..................................................................
4
II
Objectifs et architecture générale de l’activité.............................
4
III
Premier défi : énumération des logins........................................
6
1.
Objectif................................................................................
6
1
A vous de jouer.....................................................................
6
2
Bonnes pratiques..................................................................
7
IV
Deuxième défi : Force brute sur un mot de passe.......................
8
1
Objectif................................................................................
8
2
A vous de jouer.....................................................................
8
3
Bonnes pratiques..................................................................
8
V
Troisième défi : Vol de session...................................................
9
1
Objectif................................................................................
9
2
A vous de jouer.....................................................................
9
3
Bonnes pratiques..................................................................
9
VI
Conclusion..............................................................................
10
Dossier 1 : Énumération des
logins..............................................................
11
Dossier 2 : Force brute d’un mot de
passe...................................................
19
Dossier 3 : Vol de session
(Facultatif)..........................................................
22
Lors du développement d’une application, le
codage des fonctions liées à l’authentification et à la gestion des
sessions (cookie de session) peuvent être incorrectement
implémentées, permettant ainsi à des attaquants de compromettre des
mots de passe et des identifiants de session.
En cas de force brute sur des mots de passe ou
de vol d’identifiant de session (session hijacking), une personne
malveillante peut s’identifier avec le compte d’un autre
utilisateur voire avec celui de l’administrateur. Les conséquences
peuvent être particulièrement graves sur une application
manipulant des données hautement confidentielles (applications
médicales, bancaires…). Par ailleurs, le Règlement général sur
la protection des données (RGPD) confère à la CNIL des missions
supplémentaires et un pouvoir de contrôle et de sanction accru en
matière de protection des données ce qui renforce l’obligation des
entreprises d’assurer la sécurité des données manipulées.
Si le codage des
fonctions liées à l’authentification et à la gestion des sessions
est mal implémenté, l’application web risque d’offrir les
vulnérabilités suivantes :
1.
Tests d’authentification possibles sur des listes de login et de
mots de passe : énumération des logins valides puis force
brute des mots de passe ;
2.
Identification à l’aide de mots de passe par défaut encore actifs
lors de la phase de déploiement de l’application : certaines
applications web comportent des comptes avec des mots de passe par
défaut (glpi/glpi pour l’application GLPI ou nagios/nagiosadmin
pour l'application nagios ou admin/cisco sur un routeur Cisco
WRV215 , etc.) ;
3.
Création autorisée de comptes utilisateurs avec des mots de passe
non sécurisés tels que admin ou password1 ;
4.
Codage non sécurisé des fonctionnalités permettant à un
utilisateur de retrouver son mot de passe en cas d’oubli ;
5.
Mots de passe écrits en dur dans du code source, mots de passe non
chiffrés ou faiblement hashés (absence de fonction de
salage) ;
6.
Absence ou mauvais codage des fonctions gérant les
authentifications multi-formes pour les applications très sensibles
en terme de confidentialité des informations ;
7.
Mauvaise implémentation des cookies de session : cookie
d’identifiant de session prévisible, exposition des sessions ID
dans l’URL, absence de rotation des sessions ID après un succès
d’authentification ou après une déconnexion, pas de timeout sur les
sessions ID.
Côté mise en pratique, cette deuxième activité
exploite quelques exemples des vulnérabilités décrites dans les
points 1. et 7.
Les bonnes pratiques suivantes peuvent
être mises en place en tant que limitations ou contre-mesures des
vulnérabilités présentées en amont :
1.
Le développeur ne doit pas indiquer la raison d’un échec
d’authentification : login incorrect ou mot de passe
incorrect. Il faut simplement indiquer qu’il y a un échec
d’authentification sans donner plus de détails par une phrase du
type : échec d’authentification ;
2.
Il faut coder des fonctions qui imposent un changement de mot de
passe lors de la première connexion et supprimer les comptes
inutiles comportant des mots de passe par défaut lors du
déploiement de l’application ;
3.
Il faut interdire les mots de passe non sécurisés (mots de passe du
dictionnaire) en testant la solidité des mots de passe au moment de
la création des comptes (codage qui impose une longueur minimale,
la présence de caractères spéciaux…) ;
4.
Il faut s’assurer que les fonctions permettant de retrouver un mot
de passe en cas d’oubli ne présentent pas un codage trop laxiste
(demande d’une couleur préférée par exemple) ;
5.
Externaliser le stockage des mots de passe et les stocker sous
forme chiffrée : ne pas stocker des mots de passe en clair
dans du code source, utiliser des fonctions de salage lorsque les
mots de passe sont hashés afin de prévenir les attaques du type
table arc-en-ciel (rainbow table) ;
6.
Les applications manipulant des informations hautement
confidentielles doivent comporter des modules d’authentifications
multi-formes en plus du traditionnel login/mot de passe :
possession d’un objet pour déchiffrer un contenu, biométrie,
géolocalisation… ;
7.
Générer des cookies d’identifiant de sessions non prévisibles, qui
changent après un succès d’authentification, les désactiver après
une déconnexion et programmer une durée de validité (timeout).
Trois défis sont proposés pour illustrer la
sécurisation de l’authentification et des sessions :
●
l’énumération des logins : il s’agit d’énumérer des logins
valides à partir d’un dictionnaire ;
●
une attaque par force brute sur un login valide : l’attaquant
étant certain qu’un login est valide, il peut tenter une force
brute sur le mot de passe ;
●
un vol de session à l’aide d’un cookie d’identification prévisible
afin de s’identifier à l’aide du compte d’un autre utilisateur sans
connaître son login et son mot de passe.
Ces trois défis peuvent être réalisés de
manière indépendante. Chaque défi est associé à un dossier
documentaire.
Pour rappel, l’environnement
de travail est le suivant :
Machine attaquante
(192.168.1.11)
Serveur mutillidae (192.168.1.10)
Le serveur Mutillidae propose un site web conçu
pour identifier et tester les failles de sécurité identifiées par
l’OWASP. Il est possible pour chacune d’entre elles, de définir le
niveau de sécurité appliqué.
Notre démarche consistera, pour les failles de
type A2 d’OWASP :
●
à partir de la version non sécurisée de la page concernée et à
mettre en évidence la faille de sécurité.
●
nous constaterons ensuite que dans la version sécurisée de cette
page fournie par Mutillidae, l’attaque n’est plus possible.
●
l’étude des mécanismes de sécurisation utilisés, donc du code de la
page associée, permettra de dégager des bonnes pratiques de
programmation.
Quant à la machine attaquante, elle comprend un
navigateur ainsi que le proxy BurpSuite qui permet d’intercepter
les requêtes avant de les envoyer au serveur.
L’objectif est d’obtenir une liste de logins
valides testés à l’aide d’un dictionnaire. Lorsque le développeur
indique la raison d’un échec d’authentification (login incorrect),
un attaquant peut profiter de ces messages d’échec afin de tester
des listes de login en comparant les réponses obtenues entre un
succès et un échec d’authentification.
L’énumération des
logins est envisageable, quel que soit le type d’interaction entre
les clients et le serveur : nous aurions pu appliquer la
démarche décrite plus bas pour une authentification "classique"
basée sur des pages HTML/PHP ; nous avons choisi de travailler
sur une authentification passant par un service web basé sur
un protocole de communication de type SOAP.
Les services web
sont de plus en plus utilisés, ils seront vus en cours les
prochaines semaines.
Ils facilitent la communication entre applications
hétérogènes : ils servent beaucoup pour interconnecter les
systèmes d’informations ; on les retrouve aussi dans les
services mis à disposition par un cloud.
Mutillidae permet
d’aborder un certain nombre de problèmes de sécurité posés par ces
services web : l’énumération des logins est donc le premier
que nous rencontrerons.
Les questions suivantes peuvent être traitées
en suivant les étapes décrites dans le dossier documentaire n°1
(page 11, énumération des logins).
Q1.
Énumération des logins en mode non sécurisé.
Le but de cette première série de questions
est d’étudier le comportement de l’application en mode non sécurisé
afin de lancer l’attaque visant à énumérer des logins
valides.
Q1.
Commencer par installer l’extension Wsdler en réalisant les
manipulations décrites dans l’étape n°1. Puis, positionner le
niveau de sécurité à 0.
Q2.
Tester un exemple de requête et de réponse à l’aide d’un login non
valide en réalisant les manipulations décrites dans l’étape n°1
(parse de la page wsdl, envoi au répéteur, génération de la réponse
et envoi au comparateur).
Q3.
Tester un exemple de requête et de réponse à l’aide d’un login
valide en réalisant les manipulations décrites dans l’étape n°2
(parse de la page wsdl, envoi au répéteur, modification avec un
login valide, génération de la réponse et envoi au
comparateur).
Q4.
Créer un dictionnaire de login sur votre machine cliente. Pour
cela, ouvrir un éditeur de texte et saisir des logins les uns en
dessous des autres et enregistrer votre fichier.
Q5.
Lancer l’énumération et relever les logins valides en réalisant les
manipulations décrites dans l’étape n°3.
Q6.
A l’aide du comparateur, expliquer quelles sont les lignes de la
réponse sur lesquelles l’attaquant a pu s’appuyer pour lancer
l’attaque ?
Travail à faire 2
Énumération des logins en mode sécurisé et analyse du code
source
Le but
de cette deuxième partie est de tester à nouveau l’attaque après
activation du codage sécurisé et de comprendre l’encodage mis en
place.
Q1.
Fermer puis relancer BurpSuite. Positionner le niveau de sécurité à
5 et relancer l’attaque en suivant les étapes 2 à 4.
Q2.
Les informations affichées par le comparateur sont-elles
exploitables pour tenter une énumération ?
Q3.
Chercher dans le code source de la page ws-user-account.php
(située dans /var/www/html/mutillidae/webservices/soap/) le codage
mis en place permettant d’obtenir un encodage sécurisé. Expliquer
le rôle de l’instruction EncodeforHTML.
Les bonnes pratiques de codage permettant de
limiter ou d’éviter ce type d’attaque sont les suivantes :
●
ne pas indiquer la cause d’un échec d’authentification mais se
limiter à un affichage indiquant l’échec d’authentification sans
donner plus de détails (login incorrect ou mot de passe
incorrect) ;
●
encoder les messages de sortie pour éviter qu’un attaquant puisse
les exploiter.
Réaliser une force brute du mot de passe
associé au compte administrateur précédemment découvert (login
admin).
Les questions suivantes se traitent en suivant
les étapes décrites dans le dossier documentaire n°2 (page
19, force brute d’un mot de passe).
Travail à faire 3
Force brute d’un mot de passe.
Dans un premier temps, l’objectif est de se
placer côté attaquant en lançant une force brute pour découvrir le
mot de passe d’un compte.
Q1.
Commencer par préparer l’attaque en réalisant les manipulations
décrites dans l’étape n°1.
Q2.
Lancer la force brute en suivant les indications de l’étape
n°2.
Travail à faire 4
Codage sécurisé et analyse du code source
Le but
de cette deuxième partie est de tester à nouveau l’attaque après
activation du codage sécurisé et de comprendre les contre-mesures
permettant de limiter ou de contrer l’attaque.
Q1.
Fermer puis relancer BurpSuite. Positionner le niveau de sécurité à
5 et relancer l’attaque en suivant les étapes 1 et 2. La force
brute a t-elle échoué ?
Q2.
Observez le code source de la page register.php (création
d’un nouveau compte) et indiquer si avec un codage de niveau 5, un
utilisateur peut créer un compte avec un mot de passe non
sécurisé ?
Q3.
Côté administrateur du système attaqué, quelles sont les mesures
permettant de détecter et de contrer ce type d’attaque ?
Les bonnes pratiques suivantes permettant de
limiter ou d’éviter ce type d’attaque :
●
limitation de l’attaque : le développeur doit rajouter des
fonctions permettant de tester la sécurité d’un mot de passe au
moment de la création d’un compte en empêchant l’utilisation d’un
mot de passe non sécurisé ;
●
empêcher l’attaque : côté administrateur système, les systèmes
de prévention des intrusions peuvent bloquer les attaques de type
force brute.
Se retrouver authentifié avec le compte d’un
autre utilisateur via un cookie d’identification prévisible sans
connaître le login et le mot de passe de la victime.
Les questions suivantes se traitent en suivant
les étapes décrites dans le dossier documentaire n°3 (page 22, vol
de session).
Travail à faire 5
Vol de session.
Dans un premier temps, l’objectif est de se
placer côté attaquant en volant la session d’une victime.
Q1.
Commencer par intercepter le cookie d’un utilisateur correctement
authentifié en réalisant les manipulations décrites dans l’étape
n°1.
Q2.
Voler la session d’une victime en modifiant l’identifiant associé
au cookie intercepté. Pour cela, réaliser les manipulations
décrites dans l’étape n°2.
Travail à faire 6
Codage sécurisé et analyse du code source
Le but
de cette deuxième partie est de tester à nouveau l’attaque après
activation du codage sécurisé et de comprendre les contre-mesures
permettant de contrer l’attaque.
•
Fermer puis relancer BurpSuite. Positionner le niveau de sécurité à
5 et relancer l’attaque en suivant les étapes 1 et 2. La
modification du cookie uid a t-elle une
conséquence ?
Q3.
Observez le code source de la page index.php (page
d’accueil) et relever les différences avec le codage de niveau de
sécurité 0 et 1.
Q4.
Expliquer les différences entre un cookie et une session. Conclure
sur les bonnes pratiques de codage concernant le suivi des
utilisateurs identifiés.
Les bonnes pratiques permettant d’éviter
ce type d’attaque sont les suivantes :
●
utiliser des sessions avec des valeurs générées et non
prévisibles ;
●
utiliser des ID de sessions qui sont modifiés après un succès
d’authentification, désactivés après une déconnexion et qui ont une
durée de vie limitée (timeout) ;
●
encoder les ID de sessions.
Aperçu général des mesures de
défense
En résumé, les principales mesures de défense
concernant les problématiques d’authentification de gestion des
sessions sont les suivantes :
Authentification
• Ne
pas révéler des messages d’erreur ou de succès trop
explicites ;
• Ne
jamais inscrire, dans du code source, des mots de passe non
chiffrés ou pas assez chiffrés, externaliser le stockage des mots
de passe ;
•
Renforcer la politique de gestion des mots de passe (durée de vie,
longueur, caractères spéciaux, majuscules).
|
Gestion des sessions
1.
Générer des jetons de sessions non prévisibles ;
2.
Programmer des règles d’expiration et de rotation des ID de
sessions (après un succès d’authentification ou une
déconnexion) ;
3.
Utiliser des fonctions permettant d’encoder les identifiants de
session.
|
Dossier
documentaire
Dossier 1 : Énumération des
logins
La démarche permettant de réaliser l’attaque
est la suivante :
1.
Dans un premier temps, l’attaquant va observer le code renvoyé par
le serveur suite à un échec d’authentification.
2.
L’étape précédente est répétée avec un login existant : pour
cela, il peut utiliser son propre compte standard ;
3.
L’attaquant peut alors comparer les différences sur les codes de
retour obtenus afin de relever un extrait pertinent qu’il pourra
exploiter comme filtre pour réaliser son attaque ;
4.
Enfin, il ne reste plus qu’à utiliser un dictionnaire comportant
des logins à tester en utilisant le filtre précédemment repéré.
L’ensemble des logins valides obtenus correspond au résultat de
notre énumération.
Étape n°0 (préalable) : Installation
de l’extension Wsdler
Dans un premier temps, il faut enrichir
BurpSuite d’une extension nommée Wsdler.
Cette extension intercepte les requêtes WSDL et
les opérations associées au service web cible. Il est alors
possible de générer des requêtes SOAP qui pourront être envoyées au
service web.
L’extension est décrite plus en détail par son
développeur sur son site :
https://blog.netspi.com/hacking-web-services-with-burp/
Pour commencer, lancer BurpSuite, aller dans
l’onglet Extender puis dans Bapp Store. Sélectionner
l’extension Wsdler et l’installer. Le bouton
Installer est situé en bas de la fenêtre de droite.

Une fois l’installation terminée, vérifier que
l’extension s’affiche dans l’onglet Extensions.
Étape n°1 : Test d’une requête et d’une
réponse sur un login inexistant
Positionner le proxy à intercept off
puis ouvrir la page suivante :
OWASP 2017 => A2 : Broken
Authentication and Session Management => Username Enumeration
=> Lookup User (SOAP Web Service).
Positionner le proxy à intercept on,
puis cliquer, dans le navigateur, sur le lien View the
WSDL.

Faire un clic droit à l’intérieur de cette
fenêtre de capture (Raw) en positionnant la souris dans la partie
en fond blanc et cliquer sur Parse WSDL. (dans
Extensions/wsdler/parse WSDL)
Vérifier que l’onglet Wsdler de
BurpSuite s’enrichit des opérations suivantes :

Pour notre objectif d’énumération, c’est
l’opération getUser qui nous intéresse. Cliquer sur
getUser et observer le code de la requête et plus
particulièrement le contenu de la balise username. Cette
balise contient une valeur par défaut correspondant à un login qui
n’existe pas dans la liste des logins valides des comptes déjà
existants (gero et). Cette requête est donc idéale pour tester le
comportement de notre application sur un login
inexistant.
Faire un clic droit dans la fenêtre
correspondant à la requête associée à un login inexistant (Raw) et
cliquer sur Send to Repeater.
L’onglet Repeater de BurpSuite ajoute un
premier sous onglet correspondant à notre requête.
Dans cet onglet, la partie Request
correspond à la requête traitée et l’onglet Raw indique le
flux capturé suite à cette requête.
Cliquer sur le bouton Send (et non go)
pour observer la réponse correspondante.
Observez le code de la réponse et plus
particulièrement la phrase indiquant que l’utilisateur (login)
n’existe pas (User gero et does not exist).

Faire un clic droit dans la fenêtre de la
réponse (fenêtre de droite et cliquer sur Send to Comparer.
L’onglet Comparer de BurpSuite s’enrichit de notre première
réponse correspondant à un login inexistant.

Étape n°2 : Test d’une requête et d’une
réponse sur un login existant
Préalable : créer un nouvel utilisateur
sous Mutillidae nommé utilisateur1 en lui affectant un mot
de passe. Pour cela, cliquer sur le lien Please register
here dans la page d’authentification. Pour les besoins du TP,
créer aussi un autre utilisateur nommé utiisateur2.

Reproduire ensuite l’ensemble des manipulations
de l’étape n°2 avec un login existant. Pour cela, positionner le
proxy à intercept off puis ouvrir la page
suivante :
OWASP 2017 => A2 : Broken
Authentication and Session Management => Username Enumeration
=> Lookup User (SOAP Web Service).
Positionner ensuite le proxy à intercept
on, puis cliquer sur le lien View the WSDL.
Comme précédemment, faire un clic droit dans la
fenêtre de capture du proxy et cliquer sur Parse WSDL. Puis,
dans l’onglet Wsdler de BurpSuite, cliquer sur
getUser et envoyer la requête au répéteur (Send to
Repeater) par un clic droit.
Le répéteur de BurpSuite offre maintenant un
deuxième onglet correspondant à notre nouvelle requête. C’est à ce
moment là qu’il faut remplacer la valeur gero et par un
login valide (utilisateur1 dans la capture d’écran
ci-dessous).

Il faut alors cliquer sur le bouton Send
pour obtenir la réponse correspondant à un login valide. On observe
la chaîne de caractère Results for. On peut alors envoyer la
réponse au comparateur (Send to the Comparer) par un clic
droit.
L’onglet Comparer de BurpSuite permet alors de
comparer les réponses obtenues entre un login valide et un login
inexistant. En cliquant sur le bouton Words, on peut
observer les différences.
La fenêtre de gauche correspond à la réponse
obtenue en cas de login inexistant. Celle de droite en cas de login
existant.

C’est cette différence dans les messages qui
s’affichent que nous allons exploiter.
Étape n°3 : Énumération des
logins
Revenir dans l’onglet Repeater de BurpSuite et
dans la fenêtre de réponse (fenêtre de droite) correspondant au
test sur un login correct, faire un clic droit et cliquer
sur Send to the Intruder. Aller ensuite dans l’onglet
Intruder de BurpSuite, et cliquer sur l’onglet
Positions puis sur le bouton Clear.

Toujours dans cette fenêtre, il faut
sélectionner avec un double clic de souris la valeur correspondant
au login (utilisateur1 dans cette capture d’écran) et
cliquer sur le bouton Add. Nous travaillerons donc avec une
seule variable, d’où le mode Sniper. D’autres modes existent
et permettent de travailler avec plusieurs variables.
Une fois la valeur sélectionnée, Bupsuite
testera en boucle différents logins en remplaçant la variable par
les valeurs indiquées dans le dictionnaire.

Puis, cliquer sur l’onglet Payload et
charger un dictionnaire de login. Ce dictionnaire peut être créé à
l’aide d’un éditeur de texte comportant une liste de login.


La sélection du dictionnaire se fait en
cliquant sur le bouton Load de la rubrique Payload
options.
Enfin, dans le dernier
onglet Options, il faut ajouter un filtre dans la rubrique
Grep Extract. Cliquer ensuite sur le bouton Add.

Dans la fenêtre suivante, il faut indiquer la
chaîne de caractère correspondant à un login correct: "Results
for", puis
valider en cliquant sur OK.
Il ne reste plus qu’à lancer l’attaque en
cliquant sur Start Attack dans le menu Intruder de
BurpSuite. A ce moment là, ne pas tenir compte du message
d’avertissement sur les limitations de la version community.

La fenêtre de résultat de l’attaque correspond
à notre énumération de logins.

Tous les logins
testés pour lesquels la colonne Results for est alimentée
sont des logins valides sur lesquels une force brute du mot de
passe peut être tentée.
Dossier
2 : Force brute d’un mot de passe
Étape n°1 : Préparation de l’attaque
Une attaque en force brute consiste à tester en
boucle des mots de passe présents dans un dictionnaire. L’outil
Burpsuite teste alors chacun des mots de passe en observant le code
de retour ce qui permet d’identifier un succès
d’authentification.
Démarrer BurpSuite et positionner
mutillidae sur le niveau de sécurité 0. Placer aussi le proxy en
mode de non capture en cliquant surintercept off. Ouvrir
ensuite la page permettant de s’authentifier :
OWASP 2017 => A2 (Broken Authentication
and Session Management) => Authentication Bypass =>Via Brute
Force => Login
Dans l’exemple qui suit, nous travaillons sur
un compte dont le login est admin. Dans la version
2.6.62 de Mutillidae, un compte admin existe déjà avec le
mot de passe adminpass. Les manipulations suivantes
pourraient être faite avec n’importe quel compte existant dont on
souhaite brute forcer le mot de passe.
Positionner le proxy BurpSuite à on (intercept
on). Dans le champ login, saisir admin et dans le
champ du mot passe, saisir n’importe quel mot de passe erroné, puis
valider en cliquant sur le bouton Login. On peut saisir
n’importe quel mot de passe erroné vu que l’objectif de cette étape
est juste de positionner une variable.

Cliquer ensuite sur le bouton Forward
(si request différent de http://192.168.1.10:80). Dans
la capture d’écran ci-dessous, c’est le mot de passe admin
qui a été saisi. Peu importe puisque nous allons transformer ce mot
de passe en variable de test pour notre force brute.

Étape n°2 : Lancement de l’attaque
Faire ensuite un clic droit à l’intérieur de
cette fenêtre et cliquer sur Send to Intruder.
L’onglet Intruder de BurpSuite s’enrichit d’un
sous onglet supplémentaire.


Cliquer sur l’onglet Positions puis sur
le bouton Clear.

Puis, sélectionner par un double clic le mot de
passe saisi (admin) et cliquer sur le bouton Add.

Cliquer ensuite sur l’onglet Payload et
charger un dictionnaire en cliquant sur le bouton Load dans
la section Payload Options. Il faut auparavant avoir créé ce
dictionnaire.

Le lancement de l’attaque se fait en cliquant
sur le bouton Start Attack.

Les lignes
associées à un code de status de 302 correspondent à un
succès d’authentification. Le mot de passe du compte admin est donc
adminpass.
Dossier 3 : Vol de session
(Facultatif)
Étape n°1 : Interception du cookie
Tout d’abord, commencer par se déconnecter de
Mutillidae et positionner le proxy en non interception en cliquant
sur intercept off. Redémarrer aussi le navigateur.
Démarrer BurpSuite et positionner Mutillidae
avec le niveau de sécurité à 0. Puis ouvrir la page
suivante :
OWASP 2017 => A2 : Broken
Authentication and Session Management => Privilege Escalation
=> Login
Saisir un login et un mot de passe
correspondant à un compte existant (utilisateur1 dans cet
exemple). Puis valider en cliquant sur le bouton Login.

Ensuite, positionner le proxy à intercept
on. Cliquer ensuite sur le lien Home en haut de la page
afin de naviguer en étant connecté.

Cliquer éventuellement sur le bouton
Forward (si différent de ) du proxy et observer les cookies
capturés dans la partie de droite de la fenêtre
(inspector).

Un des cookies capturé s’intitule uid et
ressemble à une sorte de clé primaire.
On peut s’interroger sur le comportement de
l’application si on rejoue la requête avec un numéro différent car
après le numéro 24 on peut prévoir que l’utilisateur suivant est
associé au numéro 25. De même on peut se demander à quel
utilisateur est associé le numéro 1.
Étape n°2 : Vol de la session
Modifier la valeur du cookie uid en
mettant la valeur 1. Pour cela, double cliquer sur la valeur du
cookie et saisir la nouvelle valeur.

Puis cliquer sur le bouton Forward du
proxy. On se retrouve connecté en tant qu’administrateur. Le cookie
d’identification était donc prévisible.
