Maintenant que nous avons introduit quatre fonctionnalités centrales de Burp Suite dans l’article précédent, nous allons aller un peu plus loin avec quelques fonctionnalités et extensions qui peuvent augmenter la qualité d’un audit et votre efficacité.
Les fonctionnalités et captures d’écran présentées dans cet article correspondent à la version Professional 2.1.01.
Monitorer ses scans
Comme vous le savez, le proxy fournit un historique des requêtes qu’il a vues passer. Cependant, lors d’un scan automatique, les requêtes ne passent pas par le proxy et n’apparaissent donc pas dans son historique. Or, dans le but de maîtriser ses scans, il faut pouvoir les surveiller.
Pour cela, il existe une extension nommée Logger++. Cette extension va loguer toutes les requêtes exécutées par Burp. Cela permet par exemple de savoir quelles sont les payloads envoyées par Burp, mais aussi de retrouver une requête qui aurait déclenché un comportement inattendu de la part du serveur.
Organiser ses tests
Les requêtes envoyées dans le repeater ou dans l’intruder sont par défaut organisées par onglet et ces onglets sont nommés par un numéro (de 1 à n). Ces numéros correspondent à l’ordre dans lequel les requêtes ont été envoyées. Cependant, lors d’un pentest, cela devient vite désorganisé et il est compliqué de se retrouver parmi toutes les requêtes.
Heureusement, il est possible en double-cliquant sur l’onglet de les renommer selon son souhait. Il est alors facile d’organiser ses requêtes.
Scan personnalisé
L’un des atouts principaux de Burp est son scanner de vulnérabilité. Ce module offre la possibilité d’automatiser certains tests. Cependant, les paramètres par défaut peuvent être trop agressifs ou bien pas assez précis. Cela peut faire perdre du temps, mais aussi déclencher certaines protections mises en place. Il est donc essentiel de pouvoir personnaliser ses scans pour réaliser les tests adaptés à chaque situation.
Lorsque l’on veut lancer un scan, la fenêtre « new scan » apparaît. C’est à cet endroit que l’on va pouvoir personnaliser nos scans.
L’onglet Ressource pool (Ressources) offre la possibilité de personnaliser le nombre de requêtes concurrentes, ainsi que le temps de pause entre chacune d’entre elles. Cela permet l’ajustement du comportement du scan pour qu’il se fasse détecter moins facilement par des protections contre les robots.
L’onglet « scan configuration » permet quant à lui l’optimisation des scans et des alertes. Les paramètres ajustables sont les suivants :
- Le niveau de sensibilité de la détection ;
- Les payloads à exécuter en fonctions des vulnérabilités recherchées ;
- Les conditions d’arrêt du scan en cas d’échec ;
- Les
points d’insertion des payloads ;
- Paramètres présents dans l’URL ;
- Paramètres présents dans le body ;
- Cookie ;
- HTTP header ;
- Nom des paramètres ;
- Nom des fichiers dans l’URL ;
- Nom des dossiers dans l’URL ;
- Les points d’insertion à ignorer ;
- Le changement d’emplacement de certains paramètres ;
- Le nombre de points d’insertion ;
- Le comportement du scanner pour l’analyse du JavaScript.
La version 2.1.01 de Burp offre la possibilité de créer différentes configurations afin que chaque scan ait sa configuration personnalisée, contrairement à la version précédente où tous les scans se voyaient appliquer la même configuration.
Pour aller plus loin dans la personnalisation des points d’insertion, il est possible, au lieu d’envoyer les requêtes dans le scanner, de les envoyer dans l’intruder. En effet, l’intruder permet de sélectionner manuellement les emplacements des payloads.
Les champs affichés en surbrillance sont ceux sélectionnés comme point d’entrée. Il suffit ensuite de cliquer sur « scan defined insertion points ». Le processus du scan est ensuite le même qu’un scan classique.
Faciliter les tests de droits
Lors d’un audit de sécurité, les tests des droits utilisateurs peuvent être assez longs et fastidieux. En effet, selon les plateformes, de nombreux tests sont à effectuer (de nombreux rôles différents, grand nombre fonctionnalités, etc.). S’il y a un manque d’organisation, le risque est grand d’oublier des tests et de perdre du temps.
Il est important d’accorder une grande importance aux tests de droits, car les manques de vérification des droits sont assez récurrents et créent parfois des vulnérabilités critiques (lecture et modification des informations d’un autre utilisateur, accès des fonctionnalités administrateur, obtention de données sensibles, etc.). Afin d’aider le pentester dans cette tâche, il existe l’extension AuthMatrix.
L’atout premier de cette extension est de faciliter la gestion et l’organisation des tests. Pour cela, nous créons un premier temps un utilisateur pour chaque niveau de privilège, par exemple utilisateur non inscrit, utilisateur inscrit, administrateur. Ensuite, pour chaque type d’utilisateur, nous leur attribuons différents rôles, comme super administrateur, superviseur, RH, etc. Pour simplifier cet exemple, nous utiliserons un cas de figure où nous testons l’étanchéité des actions entre deux utilisateurs (utilisateur1 et utilisateur2).
Tout d’abord, nous configurons la AuthMatrix afin qu’elle simule deux utilisateurs différents. Dans notre exemple, les utilisateurs sont différenciés par un PHPSESSID. Afin de le récupérer, il suffit de se connecter sur le site à auditer avec les deux utilisateurs à tester. Ensuite, nous allons dans l’historique du proxy et nous envoyons les cookies vers la AuthMatrix (clic droit sur les requêtes des différents utilisateurs et « send cookies to AuthMatrix user: utilisateur1 »).
Vous retrouverez les utilisateurs dans l’onglet AuthMatrix :
Maintenant que nos utilisateurs sont configurés, nous sélectionnons les requêtes à tester. De la même manière que pour les cookies, nous choisissons dans l’historique du proxy les requêtes à auditer puis nous les envoyons vers la AuthMatrix (clic droit sur la requête « send request to AuthMatrix »), ce qui nous donne la fenêtre suivante :
Maintenant nous sommes prêts à effectuer les tests. Il ne reste plus qu’à sélectionner les cases pour chaque utilisateur. Si la case est cochée, cela signifie que l’utilisateur choisi doit pouvoir effectuer l’action correspondante. Lorsque tout est configuré, nous lançons les tests en appuyant sur « run ». Cela donne les résultats suivants :
En rouge apparaissent les problèmes de droits, c’est-à-dire les requêtes qui ont réussi à être exécutées alors que nous n’avions pas coché la case pour expliciter que l’utilisateur a les droits.
Cette extension permet donc d’automatiser et d’organiser de façon visuelle tous les tests de droits d’un audit. Cela facilite également la synthèse des résultats.
Pour aller plus loin et ne pas être bloqué par les protections anti-csrf ou encore les autorisations header, l’extension offre la possibilité via des regex de récupérer les valeurs des réponses du serveur afin de les insérer dans les requêtes à envoyer. Une documentation détaillée est disponible sur le GitHub de l’extension.
Auditer l’upload d’image
Lors d’un scan effectué par le scanner, les chargements d’images sont considérés comme un paramètre comme un autre. Par conséquent, les payloads spécifiques au chargement de fichiers (SVG piégé, PDF piégé, image piégée, etc.) ne sont pas testées. Il est alors possible pour le pentester d’effectuer tous ces tests manuellement. Mais cela demande un certain temps dans le but d’être exhaustif, et de plus, certains cas peuvent être oubliés.
Afin de répondre à cette problématique, il existe une extension nommée « upload scanner ». Comme pour un scan, il faut au préalable sélectionner la requête de l’upload à auditer, puis l’envoyer dans l’extension (send to upload scanner).
La requête se présente de la façon suivante :
Dans le cas d’un upload « multipart », le scanner va détecter automatiquement la partie upload de la requête afin d’y injecter les fichiers piégés. Il est aussi possible de renseigner manuellement l’emplacement du fichier avec l’option « Flexilnjector ». Afin de détecter une vulnérabilité, Burp utilise soit les interactions avec Burp collaborator, soit la lecture du fichier après téléchargement.
Nous configurons donc le chemin où le site propose de visualiser et/ou télécharger le fichier. Il y a deux possibilités :
- Renseigner un chemin statique (à effectuer si l’image est uploadée toujours dans le même dossier)
- Renseigner un chemin statique avec une partie du chemin dynamique récupéré dans la réponse de l’upload (à effectuer si chaque fichier uploadé est référencé par un identifiant unique).
Voici un exemple de chemin dynamique avec l’upload d’un fichier. Dans cet exemple, à chaque upload, le serveur nous répond où se situe le fichier (cf. réponse ci-dessous en surligné en jaune).
Nous observons que la partie variable se situe entre «. /galerie/upload/ » et le nom du fichier. L’outil est alors configuré de la manière suivante :
Il est alors possible de tester si le téléchargement se passe bien en cliquant sur « send ReDownloader request », pour ensuite observer la réponse dans l’onglet « ReDownload response ». Une fois tout configuré, il suffit de cliquer sur « start scan with Redownloader » et le scan va s’effectuer comme un scan classique.
Pour conclure, nous devions choisir un nombre limité d’extensions et de fonctionnalités à vous présenter, et nous espérons que celles-ci seront utiles et vous feront gagner en efficacité.
Il y a bien entendu encore bien d’autres extensions intéressantes, le mieux est de vous laisser aller voir le BApp Store de Burp !