Si un mot pouvait résumer l’année 2021 de l’infosécurité (enfin, trois en fait), ce serait celui-ci : « attaque de la chaîne d’approvisionnement ». Une attaque de la chaîne d’approvisionnement logicielle se produit lorsque des pirates manipulent le code de composants logiciels tiers pour compromettre les applications « en aval » qui les utilisent. En 2021, nous avons assisté à une augmentation spectaculaire de ces attaques : des incidents de sécurité très médiatisés tels que les violations 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. Qu’est-ce que cela a à voir avec les secrets, pourriez-vous demander? Bref, beaucoup. Prenons l’affaire Codecov (nous y reviendrons rapidement) : c’est un exemple classique pour illustrer comment les pirates exploitent les informations d’identification codées en dur pour obtenir un accès initial aux systèmes de leurs victimes et récolter plus de secrets tout au long de la chaîne. Les secrets dans le code restent l’une des vulnérabilités les plus négligées dans l’espace de sécurité des applications, bien qu’ils soient une cible prioritaire dans les playbooks des pirates. Dans cet article, nous parlerons des secrets et de la façon dont les garder hors du code source est la priorité numéro un d’aujourd’hui pour sécuriser le cycle de vie du développement logiciel.
Qu’est-ce qu’un secret ?
Les secrets sont des identifiants d’authentification numériques (clés API, certificats, jetons, etc.) qui sont utilisés dans des applications, des services ou des infrastructures. Tout comme un mot de passe (plus un appareil en cas de 2FA) est utilisé pour authentifier une personne, un secret authentifie les systèmes pour permettre l’interopérabilité. Mais il y a un hic : contrairement aux mots de passe, les secrets sont destinés à être distribués. Pour fournir en permanence de nouvelles fonctionnalités, les équipes d’ingénierie logicielle doivent interconnecter de plus en plus de blocs de construction. Les organisations voient le nombre d’identifiants utilisés dans plusieurs équipes (équipe de développement, SRE, DevOps, sécurité, etc.) exploser. Parfois, les développeurs conservent les clés dans un emplacement non sécurisé pour faciliter la modification du code, mais cela entraîne souvent l’oubli par erreur et la publication par inadvertance des informations. Dans le paysage de la sécurité des applications, les secrets codés en dur sont vraiment un type de vulnérabilité différent. Premièrement, étant donné que le code source est un actif très fuyant, destiné à être cloné, extrait et bifurqué sur plusieurs machines très fréquemment, les secrets sont également fuyants. Mais, plus inquiétant, n’oublions pas que le code a aussi une mémoire. Toute base de code est gérée avec une sorte de système de contrôle de version (VCS), conservant une chronologie historique de toutes les modifications qui y ont été apportées, parfois sur des décennies. Le problème est que des secrets encore valides peuvent se cacher n’importe où sur cette chronologie, ouvrant une nouvelle dimension à la surface d’attaque. Malheureusement, la plupart des analyses de sécurité ne sont effectuées que sur l’état actuel, prêt à être déployé, d’une base de code. En d’autres termes, lorsqu’il s’agit d’informations d’identification vivant dans un ancien commit ou même une branche jamais déployée, ces outils sont totalement aveugles.
Six millions de secrets transmis à GitHub
L’année dernière, en surveillant les commits poussés vers GitHub en temps réel, GitGuardian a détecté plus de 6 millions de secrets divulgués, doublant le nombre par rapport à 2020. En moyenne, 3 commits sur 1 000 contenaient un identifiant, ce qui est cinquante pour cent plus élevé que l’année dernière. Une grande partie de ces secrets donnait accès aux ressources de l’entreprise. Il n’est donc pas étonnant qu’un attaquant cherchant à s’implanter dans un système d’entreprise examine d’abord ses référentiels publics sur GitHub, puis ceux appartenant à ses employés. De nombreux développeurs utilisent GitHub pour des projets personnels et peuvent divulguer par erreur des informations d’identification d’entreprise (oui, cela arrive régulièrement !). Avec des informations d’identification d’entreprise valides, les attaquants agissent en tant qu’utilisateurs autorisés et la détection des abus devient difficile. Le temps nécessaire pour qu’un identifiant soit compromis après avoir été poussé vers GitHub n’est que de 4 secondes, ce qui signifie qu’il doit être immédiatement révoqué et tourné pour neutraliser le risque de violation. Par culpabilité, ou par manque de connaissances techniques, on comprend pourquoi les gens prennent souvent le mauvais chemin pour sortir de cette situation. Une autre mauvaise erreur pour les entreprises serait de tolérer la présence de secrets dans des référentiels non publics. Le rapport State of Secrets Sprawl de GitGuardian met en évidence le fait que les référentiels privés cachent beaucoup plus de secrets que leur équivalent public. L’hypothèse ici est que les référentiels privés donnent aux propriétaires un faux sentiment de sécurité, les rendant un peu moins préoccupés par les secrets potentiels qui se cachent dans la base de code. C’est ignorer le fait que ces secrets oubliés pourraient un jour avoir un impact dévastateur s’ils sont récoltés par des pirates. Pour être juste, les équipes de sécurité des applications sont bien conscientes du problème. Mais la quantité de travail à faire pour enquêter, révoquer et faire pivoter les secrets commis chaque semaine, ou creuser à travers des années de territoire inexploré, est tout simplement écrasante.
Violations de titre… et le reste
Cependant, il y a urgence. Les pirates recherchent activement des « idiots » sur GitHub, qui sont des modèles facilement reconnaissables pour identifier les secrets divulgués. Et GitHub n’est pas le seul endroit où ils peuvent être actifs, tout registre (comme Docker Hub) ou toute fuite de code source peut potentiellement devenir une mine d’or pour trouver des vecteurs d’exploitation. Pour preuve, il suffit de regarder les failles récemment révélées : favori de nombreux projets open-source, Codecov est un outil de couverture de code. L’année dernière, il a été compromis par des attaquants qui y ont eu accès en extrayant un identifiant de compte cloud statique de son image Docker officielle. Après avoir réussi à accéder au référentiel de code source officiel, ils ont pu altérer un script CI et récolter des centaines de secrets à partir de la base d’utilisateurs de Codecov. Plus récemment, l’intégralité de la base de code de Twitch a été divulguée, exposant plus de 6 000 référentiels Git et 3 millions de documents. Malgré de nombreuses preuves démontrant un certain niveau de maturité AppSec, près de 7 000 secrets pourraient être révélés ! Nous parlons de centaines de clés AWS, Google, Stripe et GitHub. Quelques-uns suffiraient à déployer une attaque à grande échelle sur les systèmes les plus critiques de l’entreprise. Cette fois, aucune donnée client n’a été divulguée, mais c’est surtout de la chance. Il y a quelques années, Uber n’avait pas cette chance. Un employé a accidentellement publié du code d’entreprise sur un référentiel GitHub public, qui était le sien. Des pirates ont découvert et détecté les clés d’un fournisseur de services cloud donnant accès à l’infrastructure d’Uber. Une brèche massive s’ensuivit. En fin de compte, vous ne pouvez pas vraiment savoir quand un secret sera exploité, mais ce dont vous devez être conscient, c’est que des acteurs malveillants surveillent vos développeurs et recherchent votre code. Gardez également à l’esprit que ces incidents ne sont que la partie émergée de l’iceberg et que probablement de nombreuses autres violations impliquant des secrets ne sont pas divulguées publiquement.
Conclusion
Les secrets sont un élément central de toute pile logicielle, et ils sont particulièrement puissants, ils nécessitent donc une protection très solide. Leur nature distribuée et les pratiques modernes de développement de logiciels rendent très difficile le contrôle de leur destination, qu’il s’agisse de code source, de journaux de production, d’images Docker ou d’applications de messagerie instantanée. La capacité de détection et de correction des secrets est indispensable, car même les secrets peuvent être exploités lors d’une attaque entraînant une violation majeure. De tels scénarios se produisent chaque semaine et à mesure que de plus en plus de services et d’infrastructures sont utilisés dans le monde de l’entreprise, le nombre de fuites augmente à un rythme très rapide. Plus l’action est entreprise tôt, plus il est facile de protéger le code source des menaces futures.
Remarque – Cet article est écrit par Thomas Segura, rédacteur de contenu technique chez GitGuardian. Thomas a travaillé à la fois comme analyste et consultant ingénieur logiciel pour diverses grandes entreprises françaises.