Il n’est plus besoin de démontrer que les applications Web sont des vecteurs d’attaques importants.

Les études d’Immuniweb et de Sucuri montrent une fois de plus la sensibilité de ce type d’applications.

Cette méthode part du principe que nous n’avons pas d’information sur l’application, son écosystème ou son code source a priori (boite noire).

Nous allons progresser comme suit :

1. Préparation
2. Reconnaissance
3. Exploitation
4. Post-exploitation (récupération de données)
5. Nettoyage
6. Bilan

1. Préparation

Nous allons nous entrainer sur DVWA une application concue pour s’entrainer à la sécurité des applis Web.

DVWA est facilement téléchargeable et installable, notamment avec Docker :

docker run -d -p 80:80 -p 3306:3306 -e MYSQL_PASS="mypass" infoslack/dvwa

Ainsi nous avons une appli Web disponible en deux minutes et nous pouvons commencer.

2. Reconnaissance

Commençons par analyser le socle applicatif.

Nous partons d’un nom de domaine/d’une URL qui nous a été donnée (dans mon cas : http://localhost/).

2.1 Un scan pour une vision d’ensemble

Les outils de scanners (NMap, Masscan, …) ou de simples outils de connexion réseau (telnet, netcat) vont déjà nous donner une idée du socle d’hébergement de l’application (services et ports ouverts, versions de serveurs, de l’OS, …)

Avec DVWA, on trouve par exemple les ports 3306/tcp, 554/tcp et 21/tcp ouverts en plus de l’habituel port 80/tcp.

Exemple de rapport de nmap -A :

Host is up (0.00011s latency).
...                                                     
80/tcp   open  http    Apache httpd 2.4.7 ((Ubuntu))
...                                  
|_http-server-header: Apache/2.4.7 (Ubuntu) 
| http-title: Login :: Damn Vulnerable Web Application (DVWA) v1.9
|_Requested resource was login.php
...
3306/tcp open  mysql   MySQL 5.5.47-0ubuntu0.14.04.1
| mysql-info:                               
|   Protocol: 10                             
|   Version: 5.5.47-0ubuntu0.14.04.1                  
...
MAC Address: 02:42:AC:11:00:02 (Unknown)      
...
Running: Linux 3.X|4.X

2.2 Liste de services potentiellement vulnérables

A partir des résultats du scan, on va pouvoir faire une liste des vulnérabilités connues pour ce socle logiciel.

Pour cela, on va s’aider de CVEDetails qui référence toutes les vulnérabilités connues par applications.

On peut chercher par éditeur (ex : Apache), par application (ex : HTTPD), par version (ex : 2.4.7) et classer par score CVSS ce qui donne un résultat assez précis

On peut également déduire approximativement les versions de logiciels non affichées :

Exemple avec PHP :

Ubuntu 14.04 fournit la version 5.3.2 de PHP (voir l’historique des packages Ubuntu) donc si PHP a été installé par les paquets Ubuntu, nous avons le numéro de version de PHP.

Voici donc une liste partielle :

2.3 Liste de ressources “ouvertes”

Dans le cas d’une application Web, il arrive régulièrement que des répertoires privés soient oubliés et accessibles à tort.

Des outils comme dirsearch, permettent d’obtenir facilement une liste de ces répertoires.

On peut également utiliser les outils de fuzzing pour tenter de voir comment le serveur répond à des requêtes “bizarres” et aléatoires.

On peut citer pour ça WFuzz ou regarder cette liste.

On peut donc obtenir de ces outils une liste de fichiers/répertoires intéressants :

2.4 Scanners Web

Un certain nombre de scanners sont spécialisés dans les applications Web et pourrons remonter des vulnérabilités plus spécifiques.

Citons OpenVAS ou Nessus (attention aux faux positifs), Nikto, Vega, Arachni, skipfish, Acunetix (payant, bruyant, ne pas utiliser en prod).

Il existe également des scanners spécialisés pour les CMS : WPScan, Joomscan, Droopscan, PrestaScan.

3. Exploitation

Cette liste de vulnérabilités est déjà un rapport de vulnérabilités en elle-même et doit amener à des mesures correctives.

Mais ce n’est pas parce qu’un service se présente avec une version vulnérable qu’il est vulnérable.

Si on souhaite aller plus loin, on va utiliser des outils “d’exploit” qui vont tenter de se servir des vulnérabilités à des fins malveillantes.

La partie exploitation peut intervenir sur tous les domaines de l’informatique :

• Social engineering
• Attaques physiques
• Réseau (et MITM)
• Système
• Web

Dans le cas des applications Web, l’outil le plus connu du domaine est Metasploit.

Il peut utiliser tout un tas de modules et facilement rechercher les modules liés à des cve précises.

On peut également se servir du Top 10 Owasp pour tenter les attaques les plus courantes sur l’application à tester (voir mes slides sur le Top 10) :

Exemples d’attaques :

• Code execution / Escape Shell
• Inclusion de fichiers locaux ou distants
• Upload de fichier
• XSS
• CSRF
• SQL Injection

On peut tester toutes ces attaques sur DVWA et si vous n’y arrivez pas, les solutions sont ici : https://ogma-sec.fr/dvwa-brute-force-command-execution-solutions-protections/

4. Post-Exploitation

En post-exploitation, on profite des exploitations qu’on a pu réaliser pour aller plus loin :

• Elévation de privilèges (voir par exemple : LPE Workshop)
• Déplacement latéral
• Installation de backdoors (voir par exemple : Backdoor Factory)
• Exfiltration de données

5. Nettoyage

Une fois l’exploitation et la post-exploitation réalisées, il faut tenter de nettoyer les traces générées, à savoir les logs des différents services.

Pour les machines Windows, il existe . Pour Linux il faut avoir accès aux logs et les effacer.

6. Bilan

A la suite des différentes étapes réalisées, on peut écrire un rapport sur les vulnérabilités trouvées, le niveau de criticité de ces vulnérabilités et les remédiations possibles (correctifs, mises à jour de la pile logicielle, réécriture de code, …).