Avant d’aborder les techniques et outils, il est essentiel de définir ce que sont les « secrets » recherchés lors des tests d’intrusion.
Ces secrets sont généralement des chaînes de caractères privées, qui, si elles sont compromises, permettent d’accéder à un système, de casser un chiffrement, ou de forger des données utiles à l’authentification. Il peut s’agir, par exemple, d’un couple identifiant et mot de passe, de clés d’API, de clés privées, ou d’un jeton de session encore valide.
Obtenir un secret constitue souvent un problème majeur. Cela peut permettre à un attaquant de compromettre l’intégrité, la confidentialité et la disponibilité des données du système.
Selon la phase de l’audit, son type (web, mobile, interne, etc.) et ses conditions techniques (boite noire, grise ou blanche), différentes techniques et outils peuvent être utilisés. Cet article aborde certaines des méthodes que nous employons, sans prétendre à une liste exhaustive des techniques possibles.
Guide complet sur les techniques et outils de recherche de secrets
Dans la phase de reconnaissance précédant les tests techniques
Lors de la phase de reconnaissance d’un audit, l’objectif est de collecter un maximum d’informations sur le système cible ou l’organisation cliente.
Une partie de cette phase consiste à rechercher des secrets sur internet. Découvrir des secrets à ce stade peut offrir un accès à l’application ciblée et révéler des fuites de données importantes.
Ces informations peuvent ensuite être exploitées par un attaquant pour cibler l’entreprise de manière plus précise.
Consulter des agrégateurs de fuite de données
Il existe des services en ligne qui offrent des API pour surveiller les fuites de données liées à un domaine ou sous-domaine.
Bien que ces services soient souvent payants, ils peuvent être très efficaces. Ils récupèrent et analysent généralement les informations suivantes :
- Fuites de données provenant de services tiers (comme LinkedIn, Adobe, etc.).
- Données vendues ou échangées sur le dark web.
- Fuites de données dues à des malwares de type « stealers », qui volent des identifiants et des mots de passe.
Parmi les agrégateurs payants, on trouve des services comme BreachLeaks, CybelAngel, Flare.io, leak-lookup.com, etc.
Une fois qu’une liste d’identifiants, secrets ou mots de passe est détectée pour un domaine ou un email, il est possible de tester ces données sur les systèmes associés au test d’intrusion. Cela a souvent permis d’obtenir des accès valides.
Utiliser les moteurs de recherche
L’utilisation des opérateurs avancés dans les moteurs de recherche peut être très efficace pour détecter rapidement des fuites de secrets liées au contenu indexé. Voici deux exemples d’utilisation :
Exemple 1 : rechercher directement des secrets liés à un domaine
Dans cet exemple, l’objectif est de découvrir si des pages ou documents publics indexés par Google contiennent des identifiants en clair. Par exemple, la recherche suivante peut être utilisée :
site:.example.com intext:password OR intext:secret
Cette recherche liste toutes les pages des sous-domaines en .example.com contenant les mots-clés « password » ou « secret ».
Ce type de recherche retourne souvent des faux positifs, comme des pages d’authentification. Cependant, en affinant les recherches et en analysant les résultats, les opérateurs de recherche avancés peuvent révéler des identifiants, des clés d’API ou d’autres secrets oubliés dans une page indexée. Cela reste toutefois relativement peu fréquent.
Example 2 : rechercher sur des sites connus
Certains sites, comme pastebin.com, sont connus pour être utilisés par des personnes malveillantes pour fuites de données. Il peut donc être utile de faire des recherches spécifiques sur ce type de site. Par exemple :
site:pastebin.com and intext:secret and intext:vaadata.com
Cette recherche va lister les pages de pastebin.com contenant les mots « secret » et « vaadata.com ».
Pour plus de détails sur l’exploitation des Google dorks, vous pouvez consulter cet article : Exploiter les google dorks pour renforcer sa sécurité.
Github
De nombreuses entreprises ou leurs employés possèdent des comptes GitHub avec des dépôts publics. Il peut être utile d’examiner ces dépôts ainsi que tous les « commits » effectués à la recherche de secrets.
Pour identifier les employés d’une entreprise, des techniques d’OSINT peuvent être utilisées.
Pour rechercher et lister les identifiants dans un dépôt, plusieurs outils existent, dont les suivants :
En effet, il arrive que des secrets fuitent de cette manière.
Lors de tests techniques : cas concret des pentests web
Lors de la phase de tests, également appelée phase active, des attaques sont directement effectués sur la plateforme cible.
Pendant ces tests, il est crucial de détecter si des secrets fuitent. En fonction des conditions (boite noire, grise ou blanche) et du type d’audit, différents tests peuvent être réalisés.
Dans des conditions boite blanche
Lors d’un test en boîte blanche, les auditeurs ont accès au code source de la solution ainsi qu’à la configuration des serveurs ou autres systèmes.
Dans ce cas, ces informations constituent des zones de recherche précieuses. Bien qu’il soit relativement peu probable qu’un attaquant externe ait un accès direct au code source, il arrive fréquemment que des accès à des services sensibles soient oubliés dans le code ou la configuration. Si ces données sont un jour accessibles grâce à une vulnérabilité, les conséquences peuvent être désastreuses.
Si vous avez accès au code source, il est primordial de l’analyser à la recherche de secrets hardcodés.
Pour ce faire, vous pouvez réutiliser les outils de la section « GitHub » sur les dépôts auxquels vous avez accès. D’autres outils d’analyse statique, tels que Semgrep, SonarQube, etc., permettent également de remonter les secrets identifiés en plus des vulnérabilités potentielles détectées au niveau du code.
Une autre approche consiste à faire des recherches par mots clés dans le code source.
Voici une liste d’idées de mots-clés pouvant être intéressante à examiner :
- password
- secret
- private_key
- access_key
- access_token
- app_secret
- admin_key
- token
- API key
- apiKey
- api_key
- authsecret
- appkey
Ainsi, un simple « grep » peut suffire :
grep -Rna ‘access_key’Cette commande permet de faire une recherche sur le mot-clé « access_key » dans le répertoire courant de manière récursive (-R), en affichant la ligne sur laquelle le mot est détecté (-n).
L’option -a permet de considérer les fichiers binaires comme s’il s’agissait de fichiers texte et donc de rechercher dans leur contenu si ce dernier contient du texte lisible.
L’utilisation d’éditeurs de code comme Visual Studio Code permet également de réaliser des recherches rapides au sein du code source, grâce à des fonctionnalités de recherche avancées et des plugins adaptés pour l’analyse du code.
Avec une approche boite noire ou grise
Réponses du serveur
Bien que cela reste relativement rare, il peut arriver que des secrets, comme des identifiants ou des clés d’API privées, soient oubliés dans le code d’une page HTML, JavaScript ou CSS, notamment dans les commentaires HTML ou JavaScript.
Extraction des données
Pour extraire ces données, il est possible d’utiliser des outils comme Burp Suite. Dans Burp Suite, il faut se rendre dans l’onglet « Target », faire un clic droit sur le site ciblé, puis sélectionner « Engagement tools ».
L’option « Find comments » permet de lister et d’exporter tous les commentaires des pages visitées, tandis que l’option « Find scripts » permet de lister et d’exporter tous les scripts. Ces fichiers peuvent ensuite être analysés pour détecter d’éventuels secrets ou informations sensibles oubliées.
Recherche dans les données
Une fois les fichiers exportés, des recherches par mots clés peuvent être effectuées afin d’identifier des secrets. Cependant, plus fréquemment, des secrets sont retrouvés dans les réponses du serveur renvoyées par les APIs.
Un exemple récurrent concerne les hashs de mots de passe des utilisateurs d’une plateforme.
Imaginons une requête d’API sur un endpoint tel que « /api/users » permettant de lister les utilisateurs d’une application web. Il n’est pas rare de voir des applications où l’entièreté de l’objet « user » en base de données est renvoyée dans la réponse du serveur, y compris le hash du mot de passe.
Heureusement, lors d’un audit, des outils peuvent faciliter et automatiser la détection de ce type de secrets. L’un des outils les plus utilisés est Burp Suite, qui fournit une fonctionnalité appelée les BChecks.
Les BChecks sont des scans personnalisés que les utilisateurs peuvent créer en utilisant un langage spécifique. La documentation officielle pour la création de BChecks est disponible ici : BChecks Documentation.
Pour la détection de secrets, l’idée est de créer des BChecks permettant de détecter de façon passive la présence de différents types de hashs (comme md5, bcrypt, etc.) dans les réponses du serveur.
Les hashs ont un format standard, ce qui permet de les repérer facilement. Les BChecks peuvent également être utilisés pour détecter des mots clés spécifiques ou certaines clés d’API qui suivent un format standard, comme les AWS Access Keys.
Lorsqu’un BCheck est déclenché, une alerte est visible sur le dashboard de Burp Suite selon le message configuré, permettant ainsi de signaler la fuite de secrets.
Fichiers de configuration
Il n’est pas rare que des secrets soient directement visibles dans des fichiers de configuration d’une application web ou des fichiers de test.
Généralement, ces fichiers ne sont pas directement accessibles depuis Internet. Cependant, une mauvaise configuration du serveur web peut exposer ces fichiers extrêmement sensibles.
En tant qu’attaquant, la technique consiste simplement à effectuer une attaque brute force en utilisant des dictionnaires de fichiers existants afin de repérer si un fichier de configuration est accessible. Ces fichiers peuvent contenir des secrets comme des identifiants, des clés d’API, ou des paramètres sensibles.
Différentes listes de fichiers connus sont disponibles sur Internet. Le dépôt SecLists en est un exemple parfait, proposant un grand nombre de dictionnaires pour la recherche de fichiers ou de répertoires : SecLists GitHub.
Des outils comme feroxbuster, dirsearch, ou ffuf permettent d’utiliser ces listes pour détecter la présence de fichiers. Il est essentiel de bien configurer ces outils lors de leur utilisation pour éviter de saturer les serveurs web ou de se faire détecter par d’éventuelles protections anti brute force.
Ces outils facilitent l’automatisation de la recherche de fichiers sensibles dans des répertoires accessibles publiquement, ce qui pourrait mettre en évidence des secrets mal protégés.
Brute force
Lorsque des pages d’authentification sont présentes sur une application et qu’elles ne sont pas protégées par des mécanismes de rate limiting, il devient possible de lancer des attaques brute force à l’aide de dictionnaires pour tenter de découvrir des mots de passe valides.
Identifiants par défaut
Certaines applications ou certains systèmes utilisent des solutions ou des frameworks connus.
Si des pages d’authentifications par défaut sont présentes ou qu’un service connu utilise des clés d’API, il peut être intéressant de consulter la documentation associée.
Des identifiants par défaut peuvent potentiellement exister et être utilisés. Si la configuration n’a pas été changée suite au déploiement du service, cela peut permettre de gagner facilement un accès au service concerné. Cela arrive encore régulièrement au cours de nos audits.
Autres techniques de recherche de secrets en fonction de la cible des tests
Applications mobiles
Le stockage local d’un appareil mobile réserve parfois des surprises, tout comme le code décompilé d’une application.
Il est utile d’analyser les bases de données locales, les préférences partagées ou les chaînes de caractères extraites du code décompilé.
Ces analyses permettent d’identifier des secrets, comme des clés d’API ou de chiffrement.
Voici un article qui illustre pourquoi il est essentiel de vérifier le code source d’une application mobile : Vol de comptes via détournement de tokens d’authentification.
Réseaux internes
Lors d’un test d’intrusion interne, l’écoute des communications réseau (man in the middle) est une pratique clé.
Elle permet d’identifier et d’analyser la transmission éventuelle d’identifiants ou de hachages. L’analyse des partages de fichiers peut également révéler des fuites de secrets.
En outre, si vous avez accès à la configuration du serveur ou du système, examinez les fichiers de configuration et les variables d’environnement. Ces éléments peuvent contenir des informations sensibles.
Systèmes IoT
Lors des audits d’objets connectés, il arrive que des secrets, comme des clés de chiffrement, soient directement intégrés dans le firmware ou la mémoire.
Idéalement, ces secrets devraient être stockés dans une puce dédiée et chiffrée lors de la fabrication, mais ce n’est pas toujours respecté.
Il est donc essentiel d’extraire la mémoire RAM et le firmware pour les analyser comme un code source, en utilisant des expressions régulières ou des outils de détection de secrets.
L’analyse du trafic réseau (Bluetooth, TCP, UDP, etc.) peut également révéler des secrets en transit
Phishing
Le phishing est une autre méthode pour récupérer des secrets, notamment des identifiants et des mots de passe.
Cependant, cette attaque cible principalement les humains et vise souvent à voler des comptes. Ce n’est donc pas une véritable technique d’identification de secrets à proprement parler.
Comment prévenir les risques de compromission de secrets ?
Comme nous l’avons vu, il existe différentes façons d’identifier des secrets. Ces recherches peuvent être simplifiées grâce à des outils spécialisés.
Cependant, il reste difficile de contrôler tous les secrets d’un système d’information et d’éviter complètement les fuites.
Pour limiter les risques et les impacts de ces fuites, l’adoption de bonnes pratiques en sécurité est essentielle. Voici quelques recommandations :
- Utiliser des secrets robustes : Optez pour des mots de passe et des clés complexes. Évitez les secrets par défaut ou trop faibles, même sur des environnements de test.
- Mettre en place une authentification forte : Activez l’authentification à deux facteurs (2FA) pour tous les utilisateurs. Privilégiez l’authentification par certificat plutôt que par mot de passe pour des services comme SSH.
- Surveiller les fuites de données : Vérifiez régulièrement si votre organisation est concernée par des fuites connues, par exemple via Have I Been Pwned.
- Éviter le hardcoding des secrets : Ne stockez pas de secrets directement dans le code source ou les dépôts Git. Préférez les variables d’environnement.
- Chiffrer les communications : Utilisez systématiquement des protocoles sécurisés comme HTTPS, SFTP, FTPS ou SSH.
- Mettre en place du monitoring : Activez la journalisation et le suivi des activités réseau pour détecter rapidement un trafic anormal ou une compromission. Une réponse rapide peut limiter les dégâts.
- Former vos équipes : Sensibilisez les employés aux enjeux de la sécurité, au phishing, et à l’utilisation de gestionnaires de mots de passe.
- Réagir en cas de compromission : Si une faille est identifiée, corrigez-la immédiatement et changez tous les secrets potentiellement exposés.
Auteur : Yoan MONTOYA – Pentester @Vaadata