Dans ce chapitre, nous allons réutiliser une partie des enseignements du chapitre précédent pour gagner en pertinence dans la cartographie de l’application web !
Cartographiez le site web
Souvenez-vous : dans le chapitre “Collectez plus d’informations avec la reconnaissance active”, nous avions cherché d’autres applications ou systèmes de notre cible connexes à l’application cible initiale. On avait vu que cela pouvait être hors périmètre et qu’il fallait bien vérifier avec le commanditaire, qu'on a le droit de le faire et que la charge était prévue pour cela dans le document de cadrage.
Ici, on va adopter la même approche, mais à l’échelle de l’application cible. Ce ne sera pas hors périmètre, et c’est même obligatoire pour ne pas passer à côté de quelque chose !
Allez, on attaque !
On a déjà un peu parcouru l’application dans la phase de découverte, pour se familiariser avec elle. Maintenant, on va commencer à réellement chercher et noter les comportements intéressants.
Il est temps d'activer le proxy d'interception et de naviguer dans l’application. On en profite pour noter les modules intéressants, les pages d’erreur avec des informations techniques, etc.
Accélérez votre cartographie
La cartographie de l’application peut se découper en deux aspects :
Le recensement de la partie connue en sautant de lien en lien (appelée crawling ou spidering).
La recherche de parties plus “cachées”, pour lesquelles il n’existe pas de liens qui pointent dessus. On parlera dans ce cas d’énumération.
Pour recenser la partie connus, le spidering se fait bien manuellement, et permet de comprendre toute l’articulation de l’application. Pour compléter, on peut utiliser un outil comme gospider, ou si vous possédez la version pro de Burp Suite, le scanner intégré de l’outil.
En ce qui concerne l'énumération de parties cachées, vous pouvez également faire le travail à la main :
modifier l’URL dans la barre de recherche ;
ajouter, une à une, les différentes options auxquelles vous pensez, ou celles de la liste que vous avez téléchargée.
Ou alors vous pouvez automatiser cette tâche :
faire un petit script bash ou Python pour boucler sur des requêtes cURL ;
utiliser un outil parmi tous ceux présents sur le web : Burp Intruder (pro), ffuf, dirbuster… Il en existe une multitude !
Personnellement, j’utilise plutôt ffuf. Pas de raison précise à ce choix, c’est juste que j’ai appris à le prendre en main et qu’il répond à mes besoins. Les captures et tutoriels en vidéo de ce chapitre seront donc réalisés avec cet outil.
Voyons tout de suite comment utiliser ffuf avec une liste permettant de découvrir du contenu web :
À vous de jouer !
Challenge
Saurez-vous trouver la page nécessitant une authentification ?
L’exercice sera réussi quand vous aurez trouvé cette page en utilisant ffuf.
Pas besoin de trouver le flag (drapeau), ça ne fait pas partie de l’exercice. Mais si vous souhaitez aller au bout du challenge, libre à vous !
Solution
Cet exercice étant basé sur un challenge de Root Me, nous ne pouvons vous donner la solution toute cuite, car dans la philosophie du hacking, on considère qu'il faut bidouiller pour apprendre. Cela dit, tous les éléments permettant de réussir l’exercice se trouvent dans ce chapitre. Relisez-le au besoin et visionnez la vidéo de démonstration.
D'ailleurs, en parlant de l'enregistrement vidéo plus haut, vous y trouverez une indication importante pour vous aider : il faut ajouter certaines options pour que Root Me ne bloque pas nos outils ! Dans le cas de ffuf, ce sont les suivantes : -t 7 -rate 70 -H “User-Agent: Firefox”
Évitez les pièges
Rappelez-vous : les outils ne sont pas magiques !
Veillez à ce que l’automatisation fonctionne correctement
Comme pour les autres types de scan, il peut y avoir des pièges et des faux positifs, ou pire, des faux négatifs ! Étant donné que ce sont des outils qui automatisent…
Si par exemple vous leur passez une requête mais qu’il manque un header particulier, l’énumération vous renverra toujours le même code HTTP (par exemple 404 ou 403 ). Ce sera parce que vous aurez mal recopié les entêtes qui, pour l’application, étaient obligatoires !
Quand je ne suis pas sûr du fonctionnement, je fais passer toutes les requêtes de ces outils dans Burp. Tant pis pour la performance, mais au moins je suis sûr de ce qui est envoyé à l’application !
Analysez bien l’application avant d’automatiser
Par exemple, quand vous attaquez une API REST, la spécification voudrait qu’elle vous réponde par un codeHTTP 403si vous n’avez pas le droit d’accéder à la page cible. Eh bien, certaines API vont vous répondre avec un codeHTTP 200, et dans le corps de la réponse vont donner le “vrai” code : 403 ! Et donc nous n’aurons pas accès à la page.
Méfiez-vous des mécanismes de protection
Gardez également en tête qu’il peut y avoir des mécanismes de protection devant le site web, comme un Web Application Firewall (WAF). C’est un dispositif capable de détecter les comportements anormaux et d'appliquer par exemple un bannissement du client.
En résumé
On peut trouver des pages ou endpoints d’API cachés en :
cartographiant l’application cible avec un outil de crawling ou spidering ;
et en complétant cette cartographie avec une énumération à partir d’une liste prédéfinie.
Cela permet de découvrir des fonctionnalités qui ne sont pas toujours exposées au grand public.
Ces fonctionnalités sont parfois oubliées, parfois moins protégées, et sont donc des cibles privilégiées pour nous !
Pour les trouver, nous avons besoin d’un outil pour automatiser l’énumération, et d’une bonne liste adaptée à la cible (une liste PHP pour une application PHP, et pas une liste Java, par exemple).
Mais attention à bien configurer l’outil et à ne pas lui faire aveuglément confiance !
C’est terminé pour cette partie. La prochaine partie sera dense mais passionnante : nous allons enfin nous attaquer à la recherche de vulnérabilités dans l'application !
