Secu
Il faut s’occuper de vos informations d’identification codées en dur !
Par La rédaction, publié le 06 octobre 2022
Les chiffres sont clairs : le vol d’informations d’identification reste la cause la plus fréquente de fuite de données. Alors comment se fait-il que des milliers de secrets se cachent encore dans le code source et, surtout, comment régler ce problème ?
Par Thomas Segura, Technical Content Writer, GitGuardian
Il est clair aujourd’hui que l’année 2021 restera dans les annales de la sécurité informatique comme l’année où les organisations ont vraiment pris conscience de leur dépendance inévitable à l’égard des logiciels open-source et, surtout, des risques posés par les supply chain logicielles non supervisées.
Des incidents de sécurité très médiatisés comme les fuites de données de SolarWinds, Kaseya et Codecov ont ébranlé la confiance des entreprises dans les pratiques de sécurité des fournisseurs de services tiers.
Aujourd’hui, les entreprises, les projets open source, les fondations à but non lucratif et même les gouvernements tentent tous de trouver un moyen d’améliorer la sécurité de la supply chian logicielle. Bien que ces efforts soient plus que bienvenus, il n’existe pour l’instant aucun moyen direct pour les organisations de complètement se protéger.
D’autre part, bien qu’il soit largement reconnu comme l’un des points d’entrée les plus courants pour les pirates, un type de vulnérabilité reste largement ignoré : les informations d’identification codées en dur dans le code source.
À LIRE AUSSI :
Dans cet article, nous voulons défendre un fait simple : se concentrer sur ce que vous pouvez contrôler maintenant peut améliorer considérablement la posture de sécurité de votre organisation.
Les secrets dans le code sont quelque chose que vous pouvez et devez commencer à surveiller dès maintenant. Voici pourquoi.
Les secrets codés en dur n’ont jamais été aussi faciles à trouver
Le 3 juillet 2022, le PDG du géant de la crypto-monnaie Binance a mis en garde contre une fuite massive :
Des fragments de code oubliés contenant des clés d’accès codées en dur sont parfois à l’origine de fuites massive de données.
Le bug ? Un fragment de code source contenant la clé d’accès à une base de données titanesque d’informations personnelles qui aurait été copié et collé sur le blog d’un développeur du réseau chinois CSDN (Source).
Fragment de code copié sur le blog du CSDN contenant un secret critique susceptible de provoquer une fuite massive.
Que des secrets aient été laissés dans le code par malveillance ou par négligence, ils sont toujours une aubaine pour les pirates. Toutes sortes d’attaques peuvent être lancées en cas de fuite d’informations d’identification, même les plus inoffensives, comme une clé d’API Twitter : du phishing à l’escalade de privilèges et à l’exfiltration de données.
Les secrets (noms d’utilisateur et mots de passe, jetons d’API, clés de chiffrement, etc.) sont les actifs numériques les plus recherchés par les cybercriminels et ils n’ont jamais été aussi faciles à trouver : l’année dernière, nous avons détecté que 6 millions de secrets ont été publiés (la plupart du temps par inadvertance) dans des commits sur GitHub public, soit deux fois plus qu’en 2020.
Selon le dernier rapport DBIR, “l’utilisation d’informations d’identification volées” est de loin le moyen le plus courant de pénétrer des applications web, avec plus de 80 % des brèches attribuées à ce vecteur d’attaque, tandis que “l’exploitation de vulnérabilités” est directement responsable de moins de 20 % des cas.
Bien sûr, le terme “informations d’identification volées” englobe ici toute une série de cas, dont probablement le phishing et les informations sur les utilisateurs achetés sur le dark web. Mais si nous considérons une organisation qui crée des services et des produits numériques, cette définition s’applique aux secrets dans le code. En fait, pour une organisation productrice de code, s’assurer que les secrets sont tenus à l’écart du code source devrait être aussi évident que de mettre en œuvre le SSO et le MFA.
Les secrets ne sont pas une vulnérabilité d’exécution (ils sont bien pires)
Si l’on regarde la liste CWE (Common Weakness Enumeration) des 25 failles logicielles les plus dangereuses en 2022, on constate que “Use of Hard-coded Credentials” (CWE-798) se trouve en 15e position, contre 16 l’année précédente. Mais le fait le plus intéressant ici n’est pas tant le classement : c’est plutôt que, contrairement à toutes les autres “risques” de la liste, l’utilisation de secrets codés en dur n’est pas une vulnérabilité d’exécution. En d’autres termes, elle ne nécessite pas l’exécution d’un logiciel pour être une vulnérabilité.
Lorsque nous entendons parler de vulnérabilités applicatives, nous avons l’habitude de penser à la falsification de requêtes cross sites (CSRF), à la falsification de requêtes côté serveur (SSRF), à l’entité externe XML (XXE), aux failles logiques, etc. Elles nécessitent toutes que le logiciel soit en cours d’exécution pour pouvoir être exploitées. Avec des informations d’identification codées en dur, c’est le code source lui-même qui peut être exploité. Par conséquent, votre surface d’attaque comprend vos dépôts de code et l’ensemble de votre usine logicielle. Il s’agit d’une caractéristique vraiment unique qui a de grandes implications.
À LIRE AUSSI :
Premièrement, les informations d’identification codées en dur vont là où le code source va, ce qui rend le suivi presque impossible. Le code source est généralement cloné, extrait et forké plusieurs fois par mois sur des machines situées à l’intérieur ou à l’extérieur du périmètre d’une organisation, sans parler des incidents de fuite de code.
Les fuites sont une réalité. L’année dernière, après que leurs bases de code ont été exposées publiquement, nous avons examiné les dépôts de Twitch et de Samsung avec le même outil que celui que nous utilisons pour protéger nos clients. Dans les deux cas, nous avons trouvé entre 6 500 et 7 000 secrets prêts à être utilisés : des mots de passe de messagerie internes, des clés API de services cloud, et tout un tas de jetons d’authentification pour des services tiers ou internes. Si cela est également arrivé à NVIDIA et Microsoft, pensez-vous que cela ne peut pas arriver à votre entreprise ?
Deuxièmement, n’oublions pas que le code dans un VCS (GitHub, GitLab, Bitbucket) conserve un historique permanent. Un système de gestion de versions tel que git garde la trace de toutes les modifications apportées à une base de code et est aussi utilisé pour propager ces changements. Si l’on ajoute à cela le fait que les informations d’identification codées en dur seront exploitables tant qu’elles ne seront pas révoquées, cela signifie que des secrets encore valides peuvent se cacher n’importe où dans l’historique du VCS. Cela ouvre une nouvelle dimension à la surface d’attaque, que la plupart des analyses de sécurité ne verront jamais car elles ne s’intéressent qu’à l’état actuel, prêt à être déployé, d’une base de code.
Par conséquent, contrairement à tout autre type de vulnérabilité, les informations d’identification codées en dur s’accumulent avec le temps. Tout comme la dette technique, la gestion de cette vulnérabilité est un jeu de Tetris : “Ce n’est pas grave si elle s’accumule un peu, tant que vous avez un plan pour la réduire plus tard”. Sauf que dans ce cas vous ne voyez pas les briques tant que vous n’avez pas mis en place de la détection. Et plus il y a de développeurs (dans le passé, le présent ou le futur), plus la probabilité qu’un secret ait été ou soit présent dans un commit est élevée. Plus la base de code est grande, plus le nombre de secrets potentiellement exploitables est élevé. Au-delà d’un certain point, cela devient tout simplement impossible à gérer.
Contrairement à tout autre type de vulnérabilité, les informations d’identification codées en dur s’accumulent avec le temps. Il en résulte une forme de dette technique très compliquée à gérer et corriger.
D’après notre étude, pour une équipe de développement typique (comptant 400 développeurs et 4 ingénieurs AppSec), nos chercheurs ont détecté en moyenne à 1 050 secrets uniques divulgués lors de l’analyse de ses dépôts et commits. Chaque secret étant détecté à 13 endroits différents en moyenne, la quantité de travail nécessaire pour y remédier dépasse de loin les capacités des équipes AppSec actuelles (1 ingénieur AppSec pour 100 développeurs en moyenne).
Ce sont les raisons pour lesquelles le bon moment pour commencer à prendre des mesures contre la prolifération des secrets sera toujours maintenant (si ce n’était pas hier !).
Comment éviter les informations d’identification codées en dur ?
Quelles mesures pouvez-vous prendre ? Mettez en place les contrôles adéquats pour empêcher les informations d’identification d’entrer dans la base de code (nous utilisons souvent l’analogie “arrêter l’hémorragie”). Détecter les secrets codés en dur en temps réel est le meilleur moyen de freiner la progression de la prolifération des secrets. Attrapez-les avant même qu’ils ne deviennent des commits.
Prenons un exemple concret : un développeur commit par erreur un secret dans son environnement de travail local. S’il est alerté à ce moment-là, le coût unitaire de la remédiation est inférieur à une minute. Le secret n’a été exposé que sur le poste de travail local et le développeur peut exécuter quelques commandes pour “modifier” son commit. À l’inverse, si le secret atteint le dépôt central, il doit être considéré comme compromis puisqu’il est devenu accessible à toute personne ayant un accès en lecture, y compris les développeurs non autorisés et les APT potentiels. À partir de ce moment, un cycle complet de remédiation doit être déclenché.
À LIRE AUSSI :
La révocation et la rotation des clés impliquent généralement plusieurs équipes. Un développeur devra probablement adresser une demande à une équipe Cloud Ops, qui devra à son tour interrompre quelques flux de travail dans le processus, tels que les pipelines CI/CD ou même les workers de production.
Le temps s’accumule rapidement et, d’après notre expérience, le coût moyen de la remédiation est souvent de l’ordre d’au moins deux heures de travail.
Les calculs sont simples : pour une équipe de 400 développeurs où nous avons découvert 1.050 secrets uniques, nous pouvons estimer qu’au moins 2 100 heures-homme seraient nécessaires pour atteindre le “zéro secret dans le code” – en supposant qu’aucun autre secret ne sera divulgué à l’avenir !
En résumé, votre retour sur investissement sera bien meilleur en commençant à arrêter l’hémorragie rapidement et en progressant petit à petit.
D’après notre expérience, la mise en place des bons points de contrôle libère des ressources considérables pour l’équipe AppSec sans créer de frictions inutiles, puisqu’elle n’a plus à traiter des centaines d’incidents chaque mois.
Ne vous endormez pas sur vos secrets…
Suivre les menaces de cybersécurité en temps réel n’est pas seulement difficile, c’est impossible.
Non seulement de nouveaux adversaires et de nouvelles TTP apparaissent chaque jour, mais ces dernières années, la difficulté a réalisé une attaque a été tellement abaissée qu’il n’est plus surprenant de voir des adolescents prendre le contrôle de certaines des plus grandes entreprises.
Nous pensons que la sécurité est un domaine complexe et qu’aucune décision ne devrait être prise sur la base d’opinions, d’intuitions ou simplement de la peur. Mais nous pensons que, trop souvent, les principes de base sont négligés alors qu’ils sont constamment pointés du doigt comme étant à l’origine de la plupart des attaques.
Pour les organisations produisant du code, et elles sont nombreuses dans tous les secteurs, les secrets doivent être bien protégés de manière à ne pas devenir le point d’entrée de futures attaques.
Il est urgent de s’occuper des informations d’identification codées en dur, car plus une organisation attend, plus la situation devient risquée et plus la dette de sécurité est coûteuse.
À LIRE AUSSI :
