What We Learned About Secrets Security at AppSec Village at DEF CON 32

Si vous avez grandi aux États-Unis, il est probable que vous avez une mémoire d’aller à un camp d’été. même si vous n’avez pas participé à l’un vous-même, l’expérience de campt de s’éloigner de chez soi, d’apprendre toutes sortes d’arts et de métiers, de rencontrer de nouveaux meilleurs amis et d’aller sur des aventures mémorables est enracinée dans la culture pop et les médias. Every August, the largest hacker summer camp on earth takes place in the heat of Las Vegas. This year marked the thirty-second iteration of DEF CON.

DEF CON can be hard to explain without experiencing it. Yes, there are speaking tracks, official workshops, and multiple capture-the-flags (CTFs), but there is so much more. No other conference contains so many sub-conferences and community-led events. Even attendees who have been going for years say they still don’t think they have experienced everything on offer.  

While there is no official number released by the organizers, past events have ranged from 25,000-30,000 attendees. Each and every attendee brings with them a love for tech and plenty of knowledge to share. The hallways are full of people hacking on hardware, writing software, making music, sharing stickers, and making all the DEF CON fun happen.

Les Villages

Il y avait 33 villages dans le cadre de DEF CON 32. Ils couvraient une large diversité d’intérêts, allant de la hacking aérospatiale, de l’ingénierie sociale et de la désinformation jusqu’à l’équipe rouge et à la sécurité des applications. Chaque village est organisé indépendamment et offre un ensemble unique d’échanges, d’ateliers et d’activités interactives pour les participants qui souhaitent s’impliquer dans une spécialité précise.

Village AppSec était un espace précieux au sein de la communauté plus large des hackers et de la sécurité axée sur la défense des applications qui animent toutes les parties de notre vie. L’auteur de cet article était l’un des chanceux qui ont aidé à organiser et à administrer le Village AppSec 2024.

Trouver les Secrets

En retournant au Village AppSec à la RSA Conference 2024, GitGuardian a présenté Spot the Secrets, un jeu de cartes qui simule l’expérience de revue de code manuelle pour trouver des informations de connexion en clair. Les joueurs sont invités à courir pour trouver toutes les clés API cachées, mots de passe et autres secrets en clair que les attaquants pourraient utiliser pour accéder à une collection de code, de tickets Jira, de fichiers de logs et de messages Slack.

Spot the Secrets au Village AppSec, modifié pour tenir compte des règles de photographie de DEF CON

À DEF CON, sur la base de 2 jours, plus de 120 personnes sont passées par notre POD dans le AppSec Village pour expérimenter personnellement cette séquence d’exercices. Nous avons même eu un tableau des meilleurs joueurs où les joueurs les plus rapides, qui ont commis le moins d’erreurs, ont gagné des prix spéciaux.

Les Plus Communes Questions de Sécurité sur les Secrets

Lorsque les gens ont commencé à examiner les cartes contenant du code, nous avons reçu une gamme large de questions. Nous croyons qu’il serait bénéfique de partager certaines de ces questions, au cas où vous n’avez pas encore entendu les réponses à ces préoccupations.

Voici les 11 questions les plus courantes que nous avons entendues et nos réponses.

1. Qu’est-ce qu’un commit exactement?

Un commit est une unité de travail dans Git, le système de contrôle de version utilisé par plus de 97% des développeurs mondiaux. C’est une capture instantanée du système de fichiers à un moment donné, englobant tout le travail effectué par le développeur depuis le dernier commit. Si vous alignez les commits les uns après les autres, vous obtenez l’historique Git, qui vous permet d’examiner chaque modification apportée de manière progressive dans la vie du code source. Un des défis de sécurité secrets de l’utilisation de Git est que l’historique est un enregistrement permanent partagé. Si un secret est ajouté dans un commit et retiré dans le commit suivant, le commit contenant le secret est toujours préservé.

2. Comment pouvez-vous savoir si quelque chose est un secret?

Un secret est n’importe quelle autorisation qui permet un accès direct à un système ou à des données. Ils peuvent prendre la forme de clés API, de mots de passe, de certificats et de jetons, pour ne citer que quelques-uns. Une partie de la raison pour laquelle ils sont difficiles à repérer est qu’ils sont utilisés de nombreuses manières différentes dans le code et en ligne de commande. Par exemple, dans un fichier de configuration, une variable spécifique peut être définie pour une clé API. Cependant, pour les systèmes tels que Slack, le jeton API est intégré à l’URL elle-même, ce qui signifie que vous devriez être familiarisé avec ce système pour savoir qu’il s’agit d’un secret.

De nombreux systèmes utilisent des numéros longs et uniques dans leurs URL de interface utilisateur, qui peuvent ressembler étonnamment à des jetons intégrés. Par exemple, les URL de Figma peuvent sembler contenir une chaîne encodée base64 dans le chemin. Cependant, si vous suivez un lien Figma aléatoire, vous serez confronté à un écran de connexion, car vous devez être un utilisateur authentifié pour se connecter à cette page. Comme cela ne confère pas automatiquement un accès au système mais ne fait que définir l’emplacement de la page, un attaquant sans point d’appui dans Figma retournerait l’erreur « Pas d’accès » et passerait à autre chose. C’est un autre motif pour accueillir des outils pour identifier les secrets, car il existe des plateformes qui peuvent rapidement déterminer la différence entre une URL contenant un jeton d’autorisation et une qui ne l’est peut-être que dans l’apparence.

3. Qu’est-ce que la validité signifie ?

Valide, dans notre contexte, signifie qu’une pièce jointe spécifique permet toujours d’accéder au système ou aux données associées. Si un attaquant la trouve, un secret valide peut être utilisé immédiatement. Si les secrets non valides peuvent fournir à un attaquant des informations sur l’architecture globale et les systèmes interconnectés, seuls les secrets valides offrent à ces derniers un accès direct à ces ressources. Ces types de déplacements latéraux peuvent être difficiles à détecter.

4. Comment est-ce que je suis censé savoir quels secrets sont les bons à rechercher ?

La meilleure réponse consiste à trouver et à retirer tous les secrets valides. Cependant, comme l’indique Spot the Secrets, c’est un problème difficile à résoudre sans les bonnes outils. Des examens de code manuels ou des outils ne reposant que sur des patterns simples peuvent vous amener à consacrer du temps à la correction de secrets déjà invalidés plutôt que de se concentrer sur les secrets valides. Les clés expirées ne représentent pas une menace importante, donc les efforts pour les éliminer devraient donc avoir une priorité inférieure à celles des identifiants valides que vous découvrez.

5. Quelle est la différence entre un secret et du code mal écrit ?

Les attaquants ne lisent probablement pas votre code la plupart du temps ; ilsscan à la recherche de moyens précis pour obtenir un accès plus large et le plus rapidement possible. Un code mal écrit peut contenir de nombreuses vulnérabilités que l’attaquant peut exploiter, en particulier autour de la configuration du Code comme Infrastructure. Cependant, l’exploitation de ces défauts exige que l’attaquant prenne le temps de comprendre le bogue et exécute une attaque spécifique contre ces problèmes, plutôt que de simplement utiliser des identifiants en clair.

Les noms de variables et d’utilisateurs peuvent faire partie d’une attaque plus complexe. Par exemple, les noms d’utilisateurs et d’emails trouvés dans le code peuvent être utilisés dans des attaques de spray de mots de passe ou des tentatives de force brute, mais celles-ci sont beaucoup plus faciles à détecter que l’utilisation directe de secrets et très chronophagees pour l’attaquant.

6. mais que faire une fois que j’ai trouvé un secret ?

Premièrement, arrêtez et prenez une profonde respiration. Cela arrive à chacun de nous, ne vous en trouverez pas trop affligé si vous trouvez un secret divulgué. Il est bon de se comporter avec urgence, mais ne paniquez pas et retirez un secret trouvé sans savoir ce qui se passera. Cela peut provoquer une multitude d’autres problèmes.

Nous recommandons de suivre la procédure suivante :

1. Comprenez ce que le secret débloque.
2. Déterminez combien de données ou de systèmes associés sont critiques.
3. Vérifiez vos journaux pour détecter l’utilisation non autorisée du secret.
4. Déterminez si des données ou l’accès aux services ont été divulgués.
5. Décidez ce qui se brisera lorsque vous rotulez le secret.
6. Faites pivoter le secret et stockez les nouvelles credentiales de manière sécurisée.
7. Corrigez tout workflow ou déploiement de production brisé.
8. Examinez l’incident et créez un plan d’action pour éviter d’autres fuites de secrets.

Lisez plus sur le processus de remédiation dans l’article, « Que faire si vous exposez un secret : comment rester calme et réagir à un incident« .

7. Maéquipe écrit toujours l’historique de Git à chaque découverte de secret. Est-ce tout ce que nous devons faire ?

Désolé, non. Bien que nous adorions cette étape de nettoyage de Git dans le processus de remédiation, il est vraiment la dernière étape et est considérée par de nombreuses organisations comme optionnelle. Nous recommandons de rotation de toutes les clés secrètes jamais exposées en texte brut (voir le lien ci-dessus pour des conseils sur le processus de remédiation).

8. Je supprime simplement le dépôt du public. Ne suffit-ce pas ?

Honnetement, nous souhaiterions que cela fut le cas, mais malheureusement pour nous tous, dès qu’il est exposé sur GitHub publiquement, il devrait toujours être considéré comme compromis. GitGuardian examine chaque nouvelle commit et chaque événement isPublic qui se produit sur l’API publique GitHub.

C’est comment nous construisons notre rapport annuel State of Secrets Sprawl et la base de l’offre de surveillance publique GitGuardian. Alors que nos intentions sont d’alerter les auteurs de commit que他们已经做了一些危险的事情, nous ne sommes pas les seuls acteurs à surveiller cette API publique. Vous devriez toujours prendre pour acquis qu’il y a une copie de tout le code ou des fichiers que vous avez jamais pushé publiquement, faite par quelqu’un que vous ne connaissez pas, et stockée ailleurs que vous ne savez pas. Nous recommandons toujours de rotation de toutes les clés secrètes potentiellement exposées.

9. Pourquoi les faux positifs sont-ils un problème ?

Dans notre exercice Spot the Secrets, nous demandons aux utilisateurs de trouver toutes les clés secrètes placées dans 100 potentiels commits, Jira, Slack et cartes Log, imposant une pénalité de temps pour chaque faux positif. Chaque carte où le joueur pense faussement qu’une carte contient une clé secrète alors que ce n’est pas le cas subira une pénalité de 10 secondes par erreur.

Bien que dans le cadre limité de l’exercice, il puisse sembler recommandable d’être particulièrement prudent et de signaler les éléments ne contenant pas de secrets, dans la réalité, cela perd de précieuses minutes, tant pour vous, le rapporteur, que pour toute personne chargée de traiter une solution.

Tout outil ou processus qui signale trop de faux positifs entraîne une fatigue alertante. Les utilisateurs sont submergés d’alertes et commencent à les ignorer. Cela conduit à une perte de confiance en l’outillage et à une utilisation incohérente. Il peut également bloquer le processus de remédiation global et signifier que certains secrets réels signalés ne sont pas traitées à temps.

10. Qu’a-t-on à voir avec le nom de fichier pour identifier un secret ?

En bref : le contexte. Les secrets génériques peuvent être particulièrement difficiles à identifier par simple analyse de modèle. Si il y a une chaîne longue dans un fichier Markdown, nos constatations pointent vers une haute probabilité qu’il s’agisse d’un exemple de mot de passe, de sorte que vous n’aurez probablement pas à vous en charger. Si, d’autre part, la même chaîne apparaît après la chaîne password= dans un fichier nommé project.env, alors il y a une chance beaucoup plus élevée que vous avez effectivement un secret sur la main.

Le nom de fichier est l’un des éléments que nous considérons avec la Prévalidation et la Postvalidation dans lemoteur de détection de secrets GitGuardian et l’un des facteurs qui nous aide à éliminer les faux positifs internes à la plateforme FP remover.

11. Les gens font-ils vraiment des examens de code manuels pour trouver les secrets?

Oui. Un total de 27 % des responsables en décision de la direction de l’IT que nous avons调查és déclarent s’appuyer sur des examens de code manuels pour remédier à la prolifération des secrets, même si 75 % disent avoir été touchés par une fuite de secrets.

Spot the Secrets a été conçu pour montrer les problèmes liés à la confiance en l’humain pour identifier ces problèmes. Les machines sont beaucoup meilleures à identifier les modèles dans des milliers ou des millions de lignes de code.

Apprendre ensemble, c’est ce que DEF CON est tout à fait关于

Nous avons appris beaucoup d’autres leçons à DEF CON, y compris rester hydraté, avoir au moins quelques heures de sommeil par nuit et rester à l’abri lorsque la température est de plus de 110°F/43°C à l’extérieur.

Il y avait tellement de bons discours sur le programme; nous attendons avec impatience que les vidéos soient disponibles pour nous permettre de rattraper le contenu que nous avons manqué en aidant les gens à apprendre sur la prolifération des secrets. Au fil du voyage, nous avons appris beaucoup sur la façon dont les gens du domaine de la sécurité, les développeurs et les gens en général perçoivent ce problème et envisagent des solutions. Chez GitGuardian, nous espérons intégrer ces leçons pour rendre la solution de ce problème plus accessible et plus facile pour nous tous.

Si vous n’avez jamais envisagé de所有 à DEF CON, nous vous le recommandons fortement, si ce n’est que pour participer au AppSec Village et pour trouver votre tribu à la colonie d’été des hackers.