Après plusieurs heures de recherche sur votre cible, vous ne trouvez rien de très intéressant, tout au plus quelques noms, adresses mail et adresses postales de collaborateurs. Pas de quoi rentrer et repartir avec le contenu du coffre de la banque pour le moment. Et surtout une question demeure : n’y a-t-il vraiment qu’un seul bâtiment qui appartient à cette banque ?
C’est là qu’intervient la reconnaissance active !
Si on reste sur notre métaphore du braquage de banque, vous allez :
faire du porte-à-porte pour demander si oui ou non tel bâtiment est relié à la banque (en espérant qu’on vous réponde positivement) ;
ou encore regarder dans les poubelles pour voir si des documents utiles y sont présents,
essayer de capter des conversations entre employés, etc.
Dans le cadre de notre test d’intrusion, cela consiste à demander si tel ou tel enregistrement DNS existe, par exemple.
Et c’est ce que nous allons voir tout de suite !
Trouvez des cibles connexes
Il existe plusieurs techniques pour trouver des informations et étendre la surface d’attaque (c’est le terme consacré) :
l’énumération de noms de domaine et de sous-domaine, à partir d’une liste que vous aurez définie ;
le scraping de la cible principale, pour trouver des références à des sous-domaines dans le contenu de la cible ;
la lecture des certificats TLS (Transport Layer Security), qui sont parfois utilisés pour plusieurs sites ;
les registres whois ;
l’historique DNS…
Ces techniques sont très intéressantes et la reconnaissance de la surface d’attaque est une spécialité du test d’intrusion en soi. Pour des cibles compliquées sur périmètres larges, on va vouloir un expert du domaine dans l’équipe pour cette phase, par exemple.
Voyons tout de suite la facilité avec laquelle on peut utiliser amass, sur root-me.org :
Dans le cadre de notre pentest, il faudra faire cet exercice sur example.com, bien entendu. :)
Comme pour tous les outils, la configuration par défaut ne remonte pas forcément les résultats les plus exhaustifs. Il faudra prendre du temps pour le configurer en allant par exemple chercher vos clés d’API dans les différentes sources de données, trouver la liste la plus complète possible pour l’énumération de sous-domaines, etc.
Exercez votre devoir de conseil sur l'extension du périmètre
Dans la phase de cadrage, j'ai proposé au client une phase de cartographie, étant donné que c’est son premier audit. Le périmètre qu’il nous a donné est *.example.com.
Ce qui veut dire que si nous tombons sur des domaines comme :
dev.example.compreprod.example.comapp.dev.example.com
…nous avons le droit de les tester !
À la fin de la cartographie et pour la suite du cours, nous avons les 3 environnements suivants :
*.dev.example.com(développement),*.preprod.example.com(pré-production),*.example.com(production) ;
Et pour chacun de ces environnements, nous avons les sous-domaines suivants qui correspondent à différents modules de l’application :
api.*.example.comapp.*.example.comadmin.*.example.com
Après un rapide tour d’horizon de ces différents environnements et applications, ce sont tous les mêmes dans des versions de développement différentes. Le client nous indique alors de ne faire les tests d’intrusion que sur la pré-production. Pour la suite du test, on va donc travailler sur la partie *.preprod.example.com . Nous notifierons tout de même dans le rapport que les autres environnements sont identifiables sur internet.
Une petite anecdote sur le sujet : nous auditions le MVP (Minimum Viable Product) d’une application pour une Fintech, une startup dans le domaine financier. Dans le cadre d’un audit de MVP, le périmètre est généralement petit : nous n’avions donc pas grand-chose à nous mettre sous la dent. De plus, les développeurs avaient bien pris en compte la sécurité sur cette partie de l'application. Résultat : pas une seule vulnérabilité, quelle frustration !
Nous avons donc demandé au commanditaire si nous pouvions étendre un peu notre cartographie, et il nous a donné son accord.
Et là, nous sommes tombés sur le sous-domaine gitlab.client.tld qui était le dépôt de code, sur lequel nous avons pu :
créer un compte ;
nous connecter ;
consulter le code source de l’application ;
et trouver des informations de connexion dans les fichiers de configuration.
Nous avons donc trouvé une vulnérabilité majeure dans l’écosystème, avec ce dépôt de code exposé sur lequel nous pouvions créer un compte ! Donc dans ce cas précis, en étendant le périmètre nous avons trouvé une vulnérabilité importante que nous n’aurions pas vue sinon.
Avant de conclure ce chapitre, je vous laisse écouter l’avis de nos deux pentesters au sujet du changement de périmètre, et de la manière dont ils gèrent cela avec le client :
En résumé
Pour étendre le périmètre, il existe plusieurs techniques de cartographie, dont l’énumération de noms de domaines et le scraping des pages de la cible.
Connaître et maîtriser toutes les techniques prendra un peu de temps, mais des outils sont là pour vous aider, avec notamment amass. La cartographie est d'ailleurs une spécialité en soi.
Avant de prendre du temps pour étendre le périmètre, vérifiez avec le commanditaire, et votre chef de projet si vous en avez un, si vous pouvez le faire ! Si ce n’est pas prévu dans le périmètre, rien ne vous empêche d’en discuter avec le commanditaire et d’amender le document de cadrage.
Dans le prochain chapitre, nous allons commencer à dialoguer activement avec notre cible pour identifier les services qui sont ouverts sur le serveur.
