On commence à avoir pas mal d’articles traitant de la sécurité informatique ici, mais on a encore rien sur la phase la plus essentielle : la phase d’exploration. C’est à dire tout ce qui va se passer avant de commencer à vraiment tenter d’attaquer quoique ce soit. Et mieux ce travail en amont est bien réalisé, mieux on s’en sort par la suite. Il y a pléthore de façons de faire, et l’ordre est pas forcément important mais je pense citer ici les étapes essentielles.
La reconnaissance passive
Toute cette phase se fait sans interagir avec la cible, donc elle ne s’applique pas dans le cadre d’un CTF mais sera très instructive dans un cadre réaliste. Il s’agit de récolter un maximum d’informations mais dans un cadre qui ne permettra pas de se faire repérer, ce qui est un énorme avantage. Parmi les outils les plus utiles on retrouvera notamment :
- Whois et DNS Lookup : permet souvent d’en apprendre plus sur la surface d’attaque disponible ainsi que sur la cible
- du Dorking via Google : avec une bonne maîtrise on peut trouver de nombreuses ressources qui se sont retrouvées exposées à tort
- Wayback Machine : souvent sous-estimé mais certaines failles/fichiers exposés et corrigées depuis sont encore disponibles dessus et peuvent donner des informations essentielles sur le code qui se cache derrière
D’ailleurs les deux derniers points peuvent parfois marcher ensemble. Il n’est pas rare de retrouver des ebooks normalement payants disponibles sans protection en usant de ces techniques (pour ma défense : j’ai payé le ebook, mais vous avez l’idée).
La cartographie de la surface d’attaque
Partie qui est rigolote au début et longue sur la fin, mais primordiale. On va commencer avec de la récupération encore via des outils :
- Identification de la plage d’IP
- Enumeration des sous-domaines
- Détection et footprinting des technos utilisées
- Recensement des ports ouverts
- Lecture des fichiers sitemap.xml et robots.txt
Et pourquoi pas un peu de Fuzzing par dessus qui permettrait de détecter quelques ressources utiles : .env, fichiers de backup, swagger, depot git, endpoint graphql, … Ça demande à ce qu’il y ait eu négligence côté dev mais dans le fond, le hacking c’est parfois aussi de la chance. En revanche c’est à éviter au maximum si vous devez rester discret.
Mais surtout la phase essentielle ça va être une cartographie manuelle depuis un proxy comme Burp ou Zap. Vous pouvez utiliser des crawlers mais en le faisant manuellement vous vous assurez de connaître la cible au lieu de sous-traiter ça à un bot. Cartographie une cible ça n’est pas juste naviguer sur les pages, c’est tester aussi chaque formulaire, chaque champs. L’idée est de repérer toutes les entrées utilisateurs qui sont autant de failles potentielles. Via un outil comme Burp, vous vous retrouverez ainsi avec une petite liste de chaque url, chaque paramètre envoyé, les retours obtenus pour chaque appel, et tous les fichiers de style et de scripts utilisés. Le plus c’est que ces ressources sont triées par domaine, donc si une api est utilisée par exemple, vous aurez tout de listé proprement également.
La mise au propre
Super, on a tout plein d’infos (plus ou moins) utiles. Maintenant qu’en faire ?
Se faire une petite mind-map ou juste un rapport détaillé permet de faire un premier tri. À partir de là en fonction des failles que vous savez utiliser et des vecteurs d’attaques que vous avez pu identifier, vous pouvez commencer à lister vos priorités (surtout dans le cadre d’un audit, vous avez souvent un temps limité).
Et maintenant vous avez suffisamment de cartes en main pour commencer à jouer !
En clair, la phase de reconnaissance a pour but de maximiser votre connaissance de la cible afin de savoir où vous posez vos pieds, et ce généralement en faisant un minimum de bruit afin de ne pas vous faire ban avant même d’avoir commencé le travail. J’ai parlé ici de beaucoup d’outils, et si certains ne vous parlent pas particulièrement pas de souci, on essaiera de revenir dessus sur ce blog (un jour) (je suis pas ultra à jour de toutes les fois où j’ai dit ça).
